CVS build error with new sort
Thomas Treichl
Thomas.Treichl at gmx.net
Thu Feb 7 11:24:48 CST 2008
Thomas Treichl schrieb:
> I got through the compilation process with the latest CVS sources by
> adding "-Xlinker -m" to my LDFLAGS -- without these flags it still
> fails, so it seems to me that the compiler is out of 'sort'-names?!
>
> I may borrow the necessary description from the 'ld' manpage:
>
> <somewhere in the manpage>
> When creating an output file with the static link editor when
> -twolevel_namespace is in effect (now the default) all undefined refer-
> ences must be satisfied at static link time.
> <somewhere else in the manpage>
> -m (32-bit only)
> Don't treat multiply defined symbols from the linked objects as
> a hard error; instead, simply print a warning. The first linked
> object defining such a symbol is used for linking; its value is
> used for the symbol in the symbol table. The code and data for
> all such symbols are copied into the output. The duplicate sym-
> bols other than the first symbol may still end up being used in
> the resulting output file through local references. This can
> still produce a resulting output file that is in error. This
> flag's use is strongly discouraged!
>
> After that 'make check' tells me
>
> PASS 3989
> FAIL 0
>
> so I hope tests are already included for the new 'sort'-modifications?
>
> I don't know if this is the right way for fixing this problem and if
> there are other flags available instead. I found other projects at the
> Internet that tell us about similar 'multiply defined whatever' problems
> on Mac and I need to have a look how they solved that problem and then
> will be back to this thread in a few days hopefully with a better solution.
>
> Thomas
>
> PS. John if you are faster than me finding better flags on your Mac then
> please let me know.
Hi,
I'm back with my problem and I did some analysis of the error output. I can see
that there exactly are 4 conflicts producing 1000 lines of 'ld: multiple
definitions of symbol'. The conflicts are with the files
sparse-sort.cc <-> Array-i.cc
Array-i.cc <-> Array-so.cc
Array-C.cc <-> Sparse-C.cc
Array-b.cc <-> Sparse-b.cc
I was able to reduce the problem to 3 conflicts by hard doing a
#undef HAVE_LONG_LONG_INT
in Array-i.cc. So there is no conflict left anymore in Array-i.cc <->
Array-so.cc and number of error outputs reduced to about 500 lines. Does this
make any sense to you?
The other three conflicts are still there but I can only try some things that I
actually don't really understand. They all have to do with 'sort', once again
posting some of them
ld: multiple definitions of symbol __ZN11octave_sortIbED1Ev.eh
pic/Array-b.o definition of absolute __ZN11octave_sortIbED1Ev.eh (value 0x0)
pic/Sparse-b.o definition of absolute __ZN11octave_sortIbED1Ev.eh (value 0x0)
ld: multiple definitions of symbol __ZN11octave_sortIbED2Ev
pic/Array-b.o definition of __ZN11octave_sortIbED2Ev in section (__TEXT,__text)
pic/Sparse-b.o definition of __ZN11octave_sortIbED2Ev in section (__TEXT,__text)
or
ld: multiple definitions of symbol
__ZN11octave_sortIP9vec_indexISt7complexIdEEE8merge_atEi
pic/Array-C.o definition of
__ZN11octave_sortIP9vec_indexISt7complexIdEEE8merge_atEi in section (__TEXT,__text)
pic/Sparse-C.o definition of
__ZN11octave_sortIP9vec_indexISt7complexIdEEE8merge_atEi in section (__TEXT,__text)
ld: multiple definitions of symbol
__ZN11octave_sortIP9vec_indexISt7complexIdEEE8merge_hiEPS4_iS6_i
pic/Array-C.o definition of
__ZN11octave_sortIP9vec_indexISt7complexIdEEE8merge_hiEPS4_iS6_i in section
(__TEXT,__text)
pic/Sparse-C.o definition of
__ZN11octave_sortIP9vec_indexISt7complexIdEEE8merge_hiEPS4_iS6_i in section
(__TEXT,__text)
What I not do understand is that there is no conflict with Array-d.cc <->
Sparse-d.cc that's why I compared Array-d.cc with Array-C.cc, Sparse-d.cc with
Sparse-C.cc and so on. This all is very cryptic for me and I would be happy for
every tip you can give me what I could try next because somehow I get out of
ideas...
Thomas
More information about the Octave-maintainers
mailing list