Bug 13891

Summary:	Binutils is impossible to static link due to broken libtool behavior
Product:	binutils	Reporter:	Rich Felker <bugdal>
Component:	binutils	Assignee:	Not yet assigned to anyone <unassigned>
Status:	NEW ---
Severity:	critical	CC:	vapier
Priority:	P2
Version:	unspecified
Target Milestone:	---
URL:	http://sourceware.org/ml/binutils/2011-08/msg00163.html
Host:		Target:
Build:		Last reconfirmed:

Description Rich Felker 2012-03-22 04:47:33 UTC

I need static linked binutils, but libtool is intercepting and disabling any -static I add to CFLAGS or LDFLAGS. According to the libtool documentation, -all-static is required in place of -static to get the same behavior, but -all-static is not usable in CFLAGS or LDFLAGS because the binutils build process also invokes the compiler/linker without libtool on many occasions, and the unknown option -all-static will result in an error that stops the build.

As far as I can tell, the only solution is to fix the broken libtool behavior. I'm filing a bug report with libtool as well, but as this seems to be the intended behavior (despite the impossibility of it working), I'm not optimistic about getting a fix.

My fix is changing -all-static) on line 4562 of ltmain.sh to -all-static|-static)

Comment 1 Andreas Schwab 2012-03-22 08:27:47 UTC

Just don't use --enable-shared.

Comment 2 Andreas Schwab 2012-03-22 08:52:57 UTC

Please ignore the last comment, I misread.

Comment 3 Mike Frysinger 2012-03-24 03:54:44 UTC

issue was mentioned on the mailing list sometime ago, and a trivial workaround posted.  all in all, this sounds like it should be brought up on the libtool mailing list rather than here considering the issue isn't specific to binutils at all.  grab any package using libtool and you'd have the same problem.

Comment 4 Rich Felker 2012-03-24 21:06:21 UTC

Mike, a link to the workaround would be really helpful to anyone dealing with this bug or trying to evaluate whether it's worth fixing/working around in binutils.

Personally I don't believe "it's a bug in libtool" is a valid excuse not to fix a major deficiency in a package that uses libtool as part of its build process. I could see that argument if libtool were an installed component of the user's system (analogously to applications should not be expected to work around glibc bugs) but since libtool is shipped with binutils as part of the build system, a buggy libtool in binutils at least largely binutils' responsibility. In fact if it were easy to do, I'd be quite happy with a --disable-libtool option that would just avoid using libtool at all for linking.

With that said, I filed a libtool bug (#11064) and it's being taken seriously, so maybe it will be fixed upstream. In that case, having the bug report against binutils open will be a good reminder to upgrade to latest upstream libtool if/when it's fixed upstream.

Comment 5 Mike Frysinger 2012-03-25 05:02:31 UTC

i already posted a link.  read the URL field.

this is how open source works -- fix the problem where the problem is instead of hacking around it in other places.  especially considering the deficiency here is hardly that big of a deal.  static linking of toolchain programs is uncommon to say the least.

--disable-libtool makes no sense.  we build libraries all over the place and replicating libtool logic in the sourceware projects is a terrible idea.