[CLN-list] make failed on .libs/exam

[Ralf Wildenhues]

* Richard B. Kreckel wrote on Wed, Oct 27, 2004 at 08:53:26AM CEST:
> On Tue, 26 Oct 2004 horbelt at 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