Bug 13891 - Binutils is impossible to static link due to broken libtool behavior
Summary: Binutils is impossible to static link due to broken libtool behavior
Status: NEW
Alias: None
Product: binutils
Classification: Unclassified
Component: binutils (show other bugs)
Version: unspecified
: P2 critical
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL: http://sourceware.org/ml/binutils/201...
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-22 04:47 UTC by Rich Felker
Modified: 2016-05-16 18:23 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.