[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug in generation of static link lines for three specific libraries
From: |
Noah Misch |
Subject: |
Re: Bug in generation of static link lines for three specific libraries |
Date: |
Thu, 17 May 2007 21:45:13 -0700 |
User-agent: |
Mutt/1.5.9i |
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