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/>