Re: CVS build error with new sort

[Thomas Treichl]

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