GNU bug report logs - #11064
CRITICAL: libtool makes static linking impossible

Previous Next

To reply to this bug, email your comments to 11064 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: bugdal <at> aerifal.cx
To: bug-libtool <at> gnu.org
Subject: CRITICAL: libtool makes static linking impossible
Date: Thu, 22 Mar 2012 00:49:30 -0400

Recent versions of libtool (since at least 2.2.6) hijack the -static
flag to the compiler and use it to link only project-local libraries
static (i.e. still generating a dynamic-linked binary). Supposedly the
-all-static option is provided to override this behavior, but it is
not usable in any real-world programs because adding -all-static to
CFLAGS or LDFLAGS prevents all configure tests that invoke the
compiler/linker without libtool from working due to the unrecognized
option.

As far as I can tell, there is no workaround and abolutely no way to
static-link libtool-based projects without patching libtool.

Message #8 received at 11064 <at> debbugs.gnu.org (full text, mbox):

From: Peter O'Gorman <peter <at> pogma.com>
To: bugdal <at> aerifal.cx
Cc: 11064 <at> debbugs.gnu.org
Subject: Re: bug#11064: CRITICAL: libtool makes static linking impossible
Date: Thu, 22 Mar 2012 10:45:06 -0500

Hello,

On 03/21/2012 11:49 PM, bugdal <at> aerifal.cx wrote:
> Recent versions of libtool (since at least 2.2.6) hijack the -static
> flag to the compiler and use it to link only project-local libraries
> static (i.e. still generating a dynamic-linked binary). Supposedly the
> -all-static option is provided to override this behavior, but it is
> not usable in any real-world programs because adding -all-static to
> CFLAGS or LDFLAGS prevents all configure tests that invoke the
> compiler/linker without libtool from working due to the unrecognized
> option.
>
> As far as I can tell, there is no workaround and abolutely no way to
> static-link libtool-based projects without patching libtool.


does:
./configure CC='gcc -static' CXX='g++ -static' ...

work around this for you?

I think the -static, -all-static etc libtool flags were meant for 
Makefiles, not really for user LDFLAGS.

Peter

Message #11 received at 11064 <at> debbugs.gnu.org (full text, mbox):

From: Peter O'Gorman <peter <at> pogma.com>
To: Rich Felker <dalias <at> aerifal.cx>, 11064 <at> debbugs.gnu.org
Subject: Re: bug#11064: CRITICAL: libtool makes static linking impossible
Date: Thu, 22 Mar 2012 16:18:52 -0500

Hi,

[added back the bug email to track this]

On 03/22/2012 11:06 AM, Rich Felker wrote:
> On Thu, Mar 22, 2012 at 10:45:06AM -0500, Peter O'Gorman wrote:
>>
>> does:
>> ../configure CC='gcc -static' CXX='g++ -static' ...
>>
>> work around this for you?
>>
>> I think the -static, -all-static etc libtool flags were meant for
>> Makefiles, not really for user LDFLAGS.
>
> No, it does not. My situation is trying to compile static-linked GNU
> binutils. I tried putting -static in CC (like you suggested), CFLAGS,
> and LDFLAGS. Each time, it appeared on the libtool command line and
> disappeared on the second command line where libtool invoked gcc.

Ok, yes, that's annoying. This workaround just worked for me:

./configure CFLAGS='-static' LDFLAGS='-Xcompiler -static'
make

But my gcc does not error for the unrecognized option during configure, 
it's possible that newer gccs will. That binutils runs configure in 
subdirs during the build makes it even more annoying to work around. If 
your gcc errors out with the -Xcompiler flag, you'll have to make a 
wrapper script for the compiler (one that takes a flag that libtool 
doesn't remove from the link line). Ick.

>
> I also tried -Wl,-Bstatic and that failed because gcc was unaware of
> the static option and passed -lgcc_s to the linker instead of
> -lgcc_eh.

You could have tried -static-libgcc, but ...

>
> The fundamental problem is that libtool has commandeered a command
> line option that's meant for user LDFLAGS (to request a static binary)
> and redefined it to mean "I only want project-internal libraries to be
> linked statically, but I still want my binary dynamic-linked to system
> libraries." And in the process, it's made it completely impossible to
> build static binaries.

I agree this is a problem, will go looking for the history of the 
-static libtool flag and see what we can do.

Peter

Message #14 received at 11064 <at> debbugs.gnu.org (full text, mbox):

From: Rich Felker <dalias <at> aerifal.cx>
To: Peter O'Gorman <peter <at> pogma.com>
Cc: 11064 <at> debbugs.gnu.org
Subject: Re: bug#11064: CRITICAL: libtool makes static linking impossible
Date: Sat, 24 Mar 2012 17:00:24 -0400

On Thu, Mar 22, 2012 at 04:18:52PM -0500, Peter O'Gorman wrote:
> >The fundamental problem is that libtool has commandeered a command
> >line option that's meant for user LDFLAGS (to request a static binary)
> >and redefined it to mean "I only want project-internal libraries to be
> >linked statically, but I still want my binary dynamic-linked to system
> >libraries." And in the process, it's made it completely impossible to
> >build static binaries.
> 
> I agree this is a problem, will go looking for the history of the
> -static libtool flag and see what we can do.

It looks to me like somebody found an obscure legacy proprietary unix
(or perhaps even just a particular broken installation of one) where
real static linking fails, and all they really cared about was
static-linking the in-project libraries, not the system ones, so they
changed -static to accommodate this one broken system and broke static
linking on all sane, working systems in the process.

If this is the case, I believe the correct fix is to restore -static
to its correct meaning and add a separate option for linking only
project-internal libraries static. And of course -all-static should be
left in place too so as not to break anything if somebody is somehow
successfully using it (even though it seems doubtful that it can be
used successfully...).

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Roumen Petrov <bugtrack <at> roumenpetrov.info>
To: Libtool Bugs List <bug-libtool <at> gnu.org>
Cc: Rich Felker <dalias <at> aerifal.cx>, Peter O'Gorman <peter <at> pogma.com>,
	11064 <at> debbugs.gnu.org
Subject: Re: bug#11064: CRITICAL: libtool makes static linking impossible
Date: Mon, 02 Apr 2012 23:54:42 +0300

Peter O'Gorman wrote:
> [SNIP]
> Ok, yes, that's annoying. This workaround just worked for me:
>
> ./configure CFLAGS='-static' LDFLAGS='-Xcompiler -static'
> make
The case is not useful. It may work for some projects but is not generic.

I will show by example OpenSSH  build . Note that OpenSSH does not use 
libtool

So lets try to build OpenSSH with :
1) .../configure CFLAGS='-static' LDFLAGS='-static'

Result is:
...
xxxx.c:(.text+0xNNNN): warning: Using '<NAME>' in statically linked 
applications requires at runtime the shared libraries from the glibc 
version used for linking
dso_dlfcn.c:(.text+0x5d4): warning: Using 'dlopen' in statically linked 
applications requires at runtime the shared libraries from the glibc 
version used for linking
...
... error ....cannot found -lgcc_s ....
....
, i.e. build fail


So next step:

2) .../configure CFLAGS='-static' LDFLAGS='-static  -shared-libgcc'
Result executable are build fine but regression tests crash with:
ssh-keygen: ../sysdeps/unix/sysv/linux/getpagesize.c:32: __getpagesize: 
Assertion `_rtld_global_ro._dl_pagesize != 0' failed.

3) .../configure CFLAGS='-static' LDFLAGS='-static  -static-libgcc'
same as 2)


[SNIP]
> But my gcc does not error for the unrecognized option during 
> configure, it's possible that newer gccs will. That binutils runs 
> configure in subdirs during the build makes it even more annoying to 
> work around. If your gcc errors out with the -Xcompiler flag, you'll 
> have to make a wrapper script for the compiler (one that takes a flag 
> that libtool doesn't remove from the link line). Ick.
[SNIP]

May be bug in my version of glibc prevent a ssh executable to run.

I'm not sure that this report is a bug neither feature request .

The current libtool behavior is fine with me.


Roumen

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.