CVS build error with new sort

[Thomas Treichl]

Thomas Treichl schrieb:
> 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

Hi,

I have good news and bad news: The good news are that I think that I have found 
out where the trouble occurs, the bad news are that I have no idea how to fix it:

I was going back to code revision 7480 (that point where Michael's and John's 
patch are already included) and continued working on the conflict Array-b.o <-> 
Sparse-b.o. Further, forget about my '#undef HAVE_LONG_LONG_INT' from the email 
before which has been good luck but nothing more. I have seen that in these two 
files only two lines have been added

   #include "oct-sort.cc"
   INSTANTIATE_ARRAY_SORT (bool);

If I keep the first line in both files but comment out the second 
'INSTANIATE'-line in either Array-b.cc or Sparse-b.cc then the conflict 
Array-b.o <-> Sparse-b.o disappears when I link liboctave.dylib.

I have also had a look at the files Sparse.h and Array.h. The problem seems to 
be that the macros INSTANTIATE_ARRAY_SORT(T) and INSTANTIATE_SPARSE_SORT(T) 
expand to exactly the same lines of codes and if the linker finds these same 
lines of codes in Array-b.o and Sparse-b.o it produces a lot of lines 'ld: 
multiply defined ...'

I also had a look at the preprocessed Array-b.ii and Sparse-b.ii files where I 
could find the 'template class octave_sort<bool>; template class 
vec_index<bool>; template class octave_sort<vec_index<bool> *>;;' lines. If once 
again either the lines in Array-b.ii or Sparse-b.ii are commented out then both 
files can be compiled and linked together (I have attached these two *.ii files 
in files.tgz).

Another test I did was that I made the INSTANTIATE_SPARSE_SORT(T) macro empty, 
ie. instead of

   #define INSTANTIATE_SPARSE_SORT(T) \
     template class octave_sort<T>; \
     template class vec_index<T>; \
     template class octave_sort<vec_index<T> *>;

I did

   #define INSTANTIATE_SPARSE_SORT(T) \
     /*empty*/

which solves some of the conflicts (but not all). To solve all of the conflicts 
I had to comment out more lines (cf. attached sparse-problem.diff). Now the most 
latest snapshot at least compiles (but I think commenting out these lines is not 
the solution, or is it?) without the '-Xlinker -m' option but produces an Octave 
binary which I won't trust being bugfree on other computers than mine even if 
'make check' produces

   Summary:
     PASS   3987
     FAIL      0

So I don't know if this is an Mac problem or maybe a gcc 4.0.1 problem which 
comes with my Developer tools on Mac? I also have come to a point where I don't 
know how to continue so I think I must stop here without having a solution but 
maybe it helps others to understand what happens...

   Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: files.tgz
Type: application/x-gzip
Size: 270547 bytes
Desc: not available
Url : https://www.cae.wisc.edu/pipermail/octave-maintainers/attachments/20080212/84a5ffdb/attachment-0001.bin 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: sparse-problem.diff
Url: https://www.cae.wisc.edu/pipermail/octave-maintainers/attachments/20080212/84a5ffdb/attachment-0001.ksh