Re: 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

files.tgz
Description: GNU Zip compressed data

diff -r 85be2610d6e3 liboctave/Array-so.cc
--- a/liboctave/Array-so.cc     Tue Feb 12 03:09:44 2008 -0500
+++ b/liboctave/Array-so.cc     Tue Feb 12 10:56:19 2008 +0100
@@ -29,7 +29,7 @@ along with Octave; see the file COPYING.
 #include "Array.h"
 #include "Array.cc"
 
-INSTANTIATE_ARRAY_AND_ASSIGN (std::streamoff, OCTAVE_API);
+// INSTANTIATE_ARRAY_AND_ASSIGN (std::streamoff, OCTAVE_API);
 
 #include "Array2.h"
 
diff -r 85be2610d6e3 liboctave/Sparse.h
--- a/liboctave/Sparse.h        Tue Feb 12 03:09:44 2008 -0500
+++ b/liboctave/Sparse.h        Tue Feb 12 10:56:19 2008 +0100
@@ -547,9 +547,7 @@ assign1 (Sparse<LT>& lhs, const Sparse<R
   INSTANTIATE_SPARSE_ASSIGN (T, T, API)
 
 #define INSTANTIATE_SPARSE_SORT(T) \
-  template class octave_sort<T>; \
-  template class vec_index<T>; \
-  template class octave_sort<vec_index<T> *>;
+  /* empty */
 
 #endif
 
diff -r 85be2610d6e3 liboctave/sparse-sort.cc
--- a/liboctave/sparse-sort.cc  Tue Feb 12 03:09:44 2008 -0500
+++ b/liboctave/sparse-sort.cc  Tue Feb 12 10:56:19 2008 +0100
@@ -62,10 +62,10 @@ octave_idx_vector_comp (octave_idx_vecto
 }
 
 // Instantiate the sparse index sorting class
-template class octave_sort<octave_idx_vector_sort *>;
+//template class octave_sort<octave_idx_vector_sort *>;
 
 // Instantiate the sorting class of octave_idx_type, need in MUL macro
-template class octave_sort<octave_idx_type>;
+//template class octave_sort<octave_idx_type>;
 
 /*
 ;;; Local Variables: ***