Re: Bug in generation of static link lines for three specific libraries

[Noah Misch]

On Thu, May 17, 2007 at 11:56:54PM -0400, Eric S. Raymond wrote:
> Noah Misch <address@hidden>:
> > This `.la' file tells Libtool that there is no static library, even
> > though there is one.  Either the Libtool that generated this library
> > was buggy, or something edited the file after Libtool wrote it.
> 
> Identical misbehavior was reported in 2004 on a Red Hat system.  I
> think it's unlikely that something clobbered these files in exactly the
> same way twice.

Yes; there is a good chance Libtool is to blame.  The same gtk `.la' files look
fine on my systems of various vintages, so we need to find out what led your
system's files astray.  I will see if I can compile GTK+ with the same version
of Libtool, reproducing the faulty `.la' construction.

As another data point, GNU ld used to silently allow linking shared libraries
into static applications.  This changed in Oct 2004[1].  Even before that, the
result was unreliable:

CC=gcc
echo 'int foo = 5;' >foo.c
./libtool --mode=compile $CC -c foo.c -o foo.lo
./libtool --mode=link $CC -shared -rpath /none foo.lo -o libfoo.la
echo 'extern int foo; int main() {return foo;}' >bar.c
./libtool --mode=compile $CC -c bar.c -o bar.lo
./libtool --mode=link $CC -all-static -o main bar.lo libfoo.la
$ ./main
-bash: ./main: /usr/lib/libc.so.1: bad ELF interpreter: No such file or 
directory

> /usr/lib/libSDL.a(SDL_sysloadso.o): In function `SDL_LoadObject':
> (.text+0xf7): warning: Using 'dlopen' in statically linked applications 
> requires at runtime the shared libraries from the glibc version used for 
> linking

This part is just a warning.  It is not easy to avoid, but you can ignore it if
you can meet the condition listed.

> /usr/bin/ld: cannot find -lpython2.5
> collect2: ld returned 1 exit status

Is this error legitimate?  Do you have a `/usr/lib/libpython2.5.a'?  If not, do
you have a `/usr/lib/libpython2.5.so'?

[1] http://www.cygwin.com/ml/binutils/2004-10/msg00143.html