dear wizards, I failed to build cln on a 64 bit dual Pentium Xeon system with SuSE linux: uname -a Linux gulvain 2.6.5-7.108-smp #1 SMP Wed Aug 25 13:34:40 UTC 2004 x86_64 x86_64 x86_64 GNU/Linux g++ --version g++ (GCC) 3.3.3 (SuSE Linux) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ./configure --prefix=/scratch/werner/ # I don't have root access to this machine unfortunately # output seemed all right make # seemed all right until: ... rm -fr .libs/libcln.la .libs/libcln.* .libs/libcln.* *** Warning: linker path does not have real file for library -lgmp. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libgmp but no candidates were found. (...for file magic test) *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. gcc -shared ... -o .libs/libcln.so.3.0.2 ... cd tests; make all ... g++ -g -O2 exam.o exam_I.o exam_RA.o exam_SF.o exam_FF.o exam_DF.o exam_LF.o exam_I_gcd.o exam_I_sqrtp.o -o .libs/exam ../src/.libs/libcln.so -lgmp -lm -Wl,--rpath -Wl,/scratch/werner//lib ../src/.libs/libcln.so: undefined reference to `_GLOBAL__I_cl_module__cl_SV_ringelt__firstglobalfun' ../src/.libs/libcln.so: undefined reference to `mulu64_high' ../src/.libs/libcln.so: undefined reference to `_GLOBAL__I_cl_module__cl_GV_number__firstglobalfun' ../src/.libs/libcln.so: undefined reference to `_GLOBAL__I_cl_module__cl_GV_I__firstglobalfun' ../src/.libs/libcln.so: undefined reference to `_GLOBAL__I_cl_module__cl_SV_number__firstglobalfun' ../src/.libs/libcln.so: undefined reference to `divu_64_rest' ../src/.libs/libcln.so: undefined reference to `_GLOBAL__I_cl_module__cl_symbol__firstglobalfun' collect2: ld returned 1 exit status is there hope? what's gmp? is .libs/exam important? thanx werner
Werner Horbelt wrote:
../src/.libs/libcln.so: undefined reference to `_GLOBAL__I_cl_module__cl_SV_ringelt__firstglobalfun'
I thought this was fixed in cln-1.1.8. Which version of cln are you attempting to build?
../src/.libs/libcln.so: undefined reference to `mulu64_high' ../src/.libs/libcln.so: undefined reference to `divu_64_rest'
We have to look into this... In the meantime, you can try building cln in 32-bit (IA-32) mode, though use of CC="gcc -m32" CXX="g++ -m32". Bruno
On Fri, 22 Oct 2004, Bruno Haible wrote:
Werner Horbelt wrote:
../src/.libs/libcln.so: undefined reference to `_GLOBAL__I_cl_module__cl_SV_ringelt__firstglobalfun'
I thought this was fixed in cln-1.1.8. Which version of cln are you attempting to build?
Well, it seems to be CLN 1.1.8 because of the shared library name libcln.so.3.0.2, see below. The thing that got fixed in CLN 1.1.8 was a runtime crash in the module ordering code on x86_64 when built as a shared library. Symbol failures had nothing to do with it, as far as I know. : *** Warning: linker path does not have real file for library -lgmp. : *** I have the capability to make that library automatically link in when : *** you link to this library. But I can only do this if you have a : *** shared version of the library, which you do not appear to have : *** because I did check the linker path looking for a file starting : *** with libgmp but no candidates were found. (...for file magic test) : *** The inter-library dependencies that have been dropped here will be : *** automatically added whenever a program is linked with this library : *** or is declared to -dlopen it. : gcc -shared ... -o .libs/libcln.so.3.0.2 BTW, what is that entire message trying to tell me? If LD_LIBRARY_PATH was missing one should not be able to configure with gmp in the first place. Werner, can you try specifying --without-gmp on CLN's configure command line? Since you asked, it refers to <http://www.swox.com/gmp/>.
../src/.libs/libcln.so: undefined reference to `mulu64_high' ../src/.libs/libcln.so: undefined reference to `divu_64_rest'
We have to look into this...
Strange. Unfortunately, I am without access to such a machine. What I fail to see is how that can possibly be different from amd_64, where I compiled and tortured CLN during the last two weeks? Werner, please tell us what your CPPFLAGS and CXXFLAGS were. Regards -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
On Saturday 23 October 2004 17:39, you wrote:
Well, it seems to be CLN 1.1.8 because of the shared library name libcln.so.3.0.2, see below. right
BTW, what is that entire message trying to tell me? If LD_LIBRARY_PATH was missing echo $LD_LIBRARY_PATH /usr/X11R6/lib:/usr/X11R6/lib64/modules
one should not be able to configure with gmp in the first place. Werner, can you try specifying --without-gmp on CLN's configure command line? then the -lgmp warning disappears, but the linker errors are the same
Since you asked, it refers to <http://www.swox.com/gmp/>. thanks, I think I won't need arbitrary precision numbers
Strange. Unfortunately, I am without access to such a machine. What I fail to see is how that can possibly be different from amd_64, where I compiled and tortured CLN during the last two weeks? Werner, please tell us what your CPPFLAGS and CXXFLAGS were. I didn't change them, in src/Makefile I found: CXXFLAGS = -g -O2 INCLUDES = -I../include -I$(top_srcdir)/include override CPPFLAGS += $(INCLUDES)
are chances better with an older version? cheers werner
On Sat, 23 Oct 2004, werner wrote:
Since you asked, it refers to <http://www.swox.com/gmp/>. thanks, I think I won't need arbitrary precision numbers
Good. Then there is no problem. Just don't use CLN either. Regards -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
On Sunday 24 October 2004 00:04, Richard B. Kreckel wrote:
thanks, I think I won't need arbitrary precision numbers Good. Then there is no problem. Just don't use CLN either. but I need GiNaC and that needs CLN
On Sunday 24 October 2004 09:38, Richard B. Kreckel wrote:
And libgmp is sitting in /usr/lib64/, right? yes
Very strange. Could you please send us the files generated during configuration? That would be config.h and intparam.h in the include/cln/ directory. I ran configure again with your suggestions and copied config.h and intparam.h from include/cln:
cmd="./configure --prefix=/scratch/werner/" $cmd # -> std.*.gz $cmd --without-gmp # -> nogmp.*.gz CC="gcc -m32" CXX="g++ -m32" $cmd # -> m32.*.gz I gzipped them to keep the mailer from inlining them. ciao werner
On Mon, 25 Oct 2004 horbelt@physik.uni-freiburg.de wrote:
Very strange. Could you please send us the files generated during configuration? That would be config.h and intparam.h in the include/cln/ directory. I ran configure again with your suggestions and copied config.h and intparam.h from include/cln:
cmd="./configure --prefix=/scratch/werner/" $cmd # -> std.*.gz $cmd --without-gmp # -> nogmp.*.gz CC="gcc -m32" CXX="g++ -m32" $cmd # -> m32.*.gz
I gzipped them to keep the mailer from inlining them.
Thank you for sending over these generated files. Unfortunately, I cannot spot anything suspicious inside them. The three files are exactly the same as the ones that are generated on a Debian system on an AMD Opteron processor when I configure CLN-1.1.8 with those options. The compiler is GCC 3.3 there, as well. And I have used CLN extensively on that Opteron machine without any of the problems you are seeing. Sorry -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
* Richard B. Kreckel wrote on Mon, Oct 25, 2004 at 09:09:59PM CEST:
On Mon, 25 Oct 2004 horbelt@physik.uni-freiburg.de wrote:
Thank you for sending over these generated files. Unfortunately, I cannot spot anything suspicious inside them. The three files are exactly the same as the ones that are generated on a Debian system on an AMD Opteron processor when I configure CLN-1.1.8 with those options. The compiler is GCC 3.3 there, as well. And I have used CLN extensively on that Opteron machine without any of the problems you are seeing.
Just to add a bit of information to this problem (not that I know if it helps): CVS HEAD of cln compiles and passes `make check' here, albeit with gmp installed. That is with no additional compiler/linker flags, i.e. 64 bit code, on a Xeon/x86_64. Compiler is gcc-3.3.3 on Fedora. I have not tested 32bit on this system. Regards, Ralf
On Tuesday 26 October 2004 08:50, Ralf Wildenhues wrote:
Just to add a bit of information to this problem (not that I know if it helps): yes, it helps keeping me trying :-)
CVS HEAD of cln compiles and passes `make check' here, albeit with gmp installed. That is with no additional compiler/linker flags, i.e. 64 bit code, on a Xeon/x86_64. Compiler is gcc-3.3.3 on Fedora. I have not tested 32bit on this system. so let's stay with the default setting.
1. I found that libtool (generated from ltmain.sh) has a loop "for i in $lib_search_path $sys_lib_search_path $shlib_search_path; do ..." None of these search paths contains /usr/lib64 which holds my libgmp.so, so this explains the warnings. 2. the line causing the linker errors is g++ -g -O2 $objects -o .libs/exam ../src/.libs/libcln.so -lgmp -lm -Wl,--rpath -Wl,/scratch/werner//lib with objects="exam*.o" can anybody tell me which of tests/exam*.o, src/.libs/libcln.so or libgmp.so is supposed to contain these symbols like _GLOBAL__I_cl_module__cl_GV_number__firstglobalfun? Ralf, could you look on your system? I know nm shows symbols in object files and libs. or which subpart of these names do I have to search for? thanks for your help werner
On Tue, 26 Oct 2004 horbelt@uni-freiburg.de wrote:
2. the line causing the linker errors is g++ -g -O2 $objects -o .libs/exam ../src/.libs/libcln.so -lgmp -lm -Wl,--rpath -Wl,/scratch/werner//lib with objects="exam*.o"
can anybody tell me which of tests/exam*.o, src/.libs/libcln.so or libgmp.so is supposed to contain these symbols like _GLOBAL__I_cl_module__cl_GV_number__firstglobalfun?
These symbols are unresolved in libcln.so proper rather than in exam*.o.
Ralf, could you look on your system? I know nm shows symbols in object files and libs. or which subpart of these names do I have to search for?
Since it seems to work elsewhere, maybe you should start having a look at your toolchain, now. The major Linux distributors have a track record of patching GCC enough to cause problems which are absent in vanilla sources. Could you compile some recent binutils into a local prefix, then bootstrap GCC 3.4.2 and try these? Regards -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
* Richard B. Kreckel wrote on Wed, Oct 27, 2004 at 08:53:26AM CEST:
On Tue, 26 Oct 2004 horbelt@uni-freiburg.de wrote:
2. the line causing the linker errors is g++ -g -O2 $objects -o .libs/exam ../src/.libs/libcln.so -lgmp -lm -Wl,--rpath -Wl,/scratch/werner//lib with objects="exam*.o"
can anybody tell me which of tests/exam*.o, src/.libs/libcln.so or libgmp.so is supposed to contain these symbols like _GLOBAL__I_cl_module__cl_GV_number__firstglobalfun?
These symbols are unresolved in libcln.so proper rather than in exam*.o.
Defined in cl_GV_number.o, part of libcln.so.
Ralf, could you look on your system? I know nm shows symbols in object files and libs. or which subpart of these names do I have to search for?
Since it seems to work elsewhere, maybe you should start having a look at your toolchain, now.
Maybe not. There was still a difference: He's using 1.1.8 and I am using HEAD. I tried 1.1.8 now, which gives me that same warning *** Warning: linker path does not have real file for library -lgmp. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libgmp but no candidates were found. (...for file magic test) *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. but still makes `make check' pass. So I guess the libtool update made that disappear. Don't know if it fixed other, distribution-related specialties.
BTW, what is that entire message trying to tell me? If LD_LIBRARY_PATH was missing one should not be able to configure with gmp in the first place.
That libgmp was not found. Not all systems are able to link in a shared library that does not exist at link time. And none can do so with a static library (of course). Was that answer too easy or did I miss your point?
The major Linux distributors have a track record of patching GCC enough to cause problems which are absent in vanilla sources. Could you compile some recent binutils into a local prefix, then bootstrap GCC 3.4.2 and try these?
Let's try the easy things first: Was `ldconfig' run after libgmp installation (that should've been done automatically)? Try strings /etc/ld.so.cache | grep gmp to see if it finds the correct library. Furthermore, I suggest he try an updated cln (could you make one available?) and then proceed, since the ChangeLog indicates more x86_64 relevant changes after the 1.1.8 release. BTW, a build with `CFLAGS=-m32 CXXFLAGS=-m32 LDFLAGS=-m32' fails in several places. Regards, Ralf
On Wednesday 27 October 2004 08:36, Ralf Wildenhues wrote:
Defined in cl_GV_number.o, part of libcln.so. excellent. I found src/cl_GV_number.o and .lo I said nm src/cl_GV_number.o result: 000000000000000c b cl_module__cl_GV_number__counter 000000000000000a b cl_module__cl_GV_number__ctordummy 00000000000001cc t cl_module__cl_GV_number__ctorend 0000000000000008 b cl_module__cl_GV_number__dtordummy 0000000000000000 T cl_module__cl_GV_number__firstglobalfun U __cxa_atexit U __dso_handle U _GLOBAL__I_cl_module__cl_GV_number__firstglobalfun ... same with src/cl_GV_number.lo. According to man nm, U means "The symbol is undefined.", I don't know what that means. I repeated the commands that generated this .o (because make appended ">/def/null 2>&1": cd src g++ -g -O2 -I../include -I../include -I./vector -I./integer -I./base/digitseq -I./base/digit -Ibase -I./base -c ./vector/cl_GV_number.cc -o tst.o
no output at stdout or stderr and tst.o is identical to cl_GV_number.o. Looking at cl_GV_number.cc I don't understand where either of the _firstglobalfun symbol should come from.
Maybe not. There was still a difference: He's using 1.1.8 and I am using HEAD. I tried 1.1.8 now, which gives me that same warning
*** Warning: linker path does not have real file... very good, at least this is solved
but still makes `make check' pass. So I guess the libtool update made that disappear. Don't know if it fixed other, distribution-related specialties.
That libgmp was not found. Not all systems are able to link in a shared library that does not exist at link time. And none can do so with a static library (of course). Was that answer too easy or did I miss your point? not at all I continue with ltmain.sh patched to include /usr/lib64 for now and the warning disappeared.
Let's try the easy things first: Was `ldconfig' run after libgmp installation (that should've been done automatically)? Try strings /etc/ld.so.cache | grep gmp libgmpxx.so.3 /usr/lib64/libgmpxx.so.3 libgmpxx.so /usr/lib64/libgmpxx.so libgmp.so.3 /usr/lib64/libgmp.so.3 libgmp.so /usr/lib64/libgmp.so
to see if it finds the correct library. Furthermore, I suggest he try an updated cln (could you make one available?) would be much appreciated and then proceed, since the ChangeLog indicates more x86_64 relevant changes after the 1.1.8 release.
thanks werner
On Wed, 27 Oct 2004, Ralf Wildenhues wrote: [...]
Since it seems to work elsewhere, maybe you should start having a look at your toolchain, now.
Maybe not. There was still a difference: He's using 1.1.8 and I am using HEAD. I tried 1.1.8 now, which gives me that same warning
Okay, I've now bootstrapped GCC 3.3.3 on the amd64 machine with Debian/sid and successfully compiled and tested CLN-1.1.8 using that compiler with the same compiler options the original problem report mentioned. Maybe Werner should start having a look at the toolchain now?
*** Warning: linker path does not have real file for library -lgmp. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libgmp but no candidates were found. (...for file magic test) *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it.
but still makes `make check' pass. So I guess the libtool update made that disappear.
That's right. I was not aware of that lib64/ change in libtool. [...]
The major Linux distributors have a track record of patching GCC enough to cause problems which are absent in vanilla sources. Could you compile some recent binutils into a local prefix, then bootstrap GCC 3.4.2 and try these?
Let's try the easy things first: Was `ldconfig' run after libgmp installation (that should've been done automatically)? Try strings /etc/ld.so.cache | grep gmp to see if it finds the correct library. Furthermore, I suggest he try an updated cln (could you make one available?) and then proceed, since the ChangeLog indicates more x86_64 relevant changes after the 1.1.8 release.
There are two unrelated problems, here. Yes, that problem with libgmp has been solved already by the libtool upgrade. The unresolved symbol problem needs debugging.
BTW, a build with `CFLAGS=-m32 CXXFLAGS=-m32 LDFLAGS=-m32' fails in several places.
I can't reproduce them on my pure amd64 system. :-/ Wait, let me guess: The compiler defines __i386__ and the script config.guess in addition #defines __x86_64__ and then compilation stops (probably quite early) due to redefinitions? Ouch. What's the canonical way to deal with such problems? Cheers -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
* Richard B. Kreckel wrote on Wed, Oct 27, 2004 at 11:20:42PM CEST:
On Wed, 27 Oct 2004, Ralf Wildenhues wrote: [...]
Okay, I've now bootstrapped GCC 3.3.3 on the amd64 machine with Debian/sid and successfully compiled and tested CLN-1.1.8 using that compiler with the same compiler options the original problem report mentioned. Maybe Werner should start having a look at the toolchain now?
Yep. I would not be too surprised if libtool needed to be taught the way SUSE does multilibbing. :-/ But let's not come to early conclusions. Fact is I don't know yet what happens on his machine.
[...]
The major Linux distributors have a track record of patching GCC enough to cause problems which are absent in vanilla sources. Could you compile some recent binutils into a local prefix, then bootstrap GCC 3.4.2 and try these?
*snip*
There are two unrelated problems, here. Yes, that problem with libgmp has been solved already by the libtool upgrade. The unresolved symbol problem needs debugging.
ACK.
BTW, a build with `CFLAGS=-m32 CXXFLAGS=-m32 LDFLAGS=-m32' fails in several places.
I can't reproduce them on my pure amd64 system. :-/
Wait, let me guess: The compiler defines __i386__ and the script config.guess in addition #defines __x86_64__ and then compilation stops (probably quite early) due to redefinitions? Ouch. What's the canonical way to deal with such problems?
I coult get rid of those by using the setarch tool and the trivial patch below: $ setarch i386 ../cln/configure -C 'CFLAGS=-m32 -g -O2' \ 'CXXFLAGS=-m32 -g -O2' LDFLAGS=-m32 $ setarch i386 make $ setarch i386 make check I don't know how to deal with them more proper than that (if that's unproper in any way). This got me a libcln that passes `make check', albeit now without gmp (merely because I don't have the 32bit libgmp installed). Regards, Ralf 2004-10-28 Ralf Wildenhues <Ralf.Wildenhues@gmx.de> * src/Makefile.in: Let config.status set LDFLAGS. Index: src/Makefile.in =================================================================== RCS file: /home/cvs/cln/src/Makefile.in,v retrieving revision 1.13 diff -u -r1.13 Makefile.in --- src/Makefile.in 26 Oct 2004 22:26:28 -0000 1.13 +++ src/Makefile.in 28 Oct 2004 15:45:44 -0000 @@ -27,6 +27,7 @@ CXXCPP = @CXXCPP@ INCLUDES = -I../include -I$(top_srcdir)/include override CPPFLAGS += $(INCLUDES) +LDFLAGS = @LDFLAGS@ LIBS = @LIBS@ LIBTOOL = @LIBTOOL@ LIBTOOL_COMPILE = $(LIBTOOL) --mode=compile
On Sat, 23 Oct 2004, werner wrote:
On Saturday 23 October 2004 17:39, you wrote:
Well, it seems to be CLN 1.1.8 because of the shared library name libcln.so.3.0.2, see below. right
BTW, what is that entire message trying to tell me? If LD_LIBRARY_PATH was missing echo $LD_LIBRARY_PATH /usr/X11R6/lib:/usr/X11R6/lib64/modules
And libgmp is sitting in /usr/lib64/, right?
one should not be able to configure with gmp in the first place. Werner, can you try specifying --without-gmp on CLN's configure command line? then the -lgmp warning disappears, but the linker errors are the same
Very strange. Could you please send us the files generated during configuration? That would be config.h and intparam.h in the include/cln/ directory.
Strange. Unfortunately, I am without access to such a machine. What I fail to see is how that can possibly be different from amd_64, where I compiled and tortured CLN during the last two weeks? Werner, please tell us what your CPPFLAGS and CXXFLAGS were. I didn't change them, in src/Makefile I found: CXXFLAGS = -g -O2 INCLUDES = -I../include -I$(top_srcdir)/include override CPPFLAGS += $(INCLUDES)
Okay, thanks. I just wanted to make sure it isn't -O0 or -O3.
are chances better with an older version?
No; I wouldn't know why that should be the case. Regards -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
participants (7)
-
Bruno Haible
-
horbelt@physik.uni-freiburg.de
-
horbelt@uni-freiburg.de
-
Ralf Wildenhues
-
Richard B. Kreckel
-
werner
-
Werner Horbelt