[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CVS build error with new sort
From: |
Thomas Treichl |
Subject: |
Re: CVS build error with new sort |
Date: |
Tue, 12 Feb 2008 12:33:00 +0100 |
User-agent: |
Thunderbird 2.0.0.9 (Macintosh/20071031) |
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: ***
- CVS build error with new sort, John Swensen, 2008/02/03
- CVS build error with new sort, John W. Eaton, 2008/02/04
- Re: CVS build error with new sort, John Swensen, 2008/02/04
- Re: CVS build error with new sort, Thomas Treichl, 2008/02/04
- Re: CVS build error with new sort, Thomas Treichl, 2008/02/07
- Re: CVS build error with new sort, John Swensen, 2008/02/07
- Re: CVS build error with new sort,
Thomas Treichl <=
- Re: CVS build error with new sort, John W. Eaton, 2008/02/12
- Re: CVS build error with new sort, John Swensen, 2008/02/12
- Re: CVS build error with new sort, John W. Eaton, 2008/02/12
- Re: CVS build error with new sort, Thomas Treichl, 2008/02/12
- Re: CVS build error with new sort, John W. Eaton, 2008/02/12
- Re: CVS build error with new sort, John Swensen, 2008/02/12
- Re: CVS build error with new sort, John W. Eaton, 2008/02/12
- Re: CVS build error with new sort, Thomas Treichl, 2008/02/13
- Re: CVS build error with new sort, Ben Abbott, 2008/02/17
Re: CVS build error with new sort, David Bateman, 2008/02/04