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

[Richard B. Kreckel]

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