From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11046 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: link failures when building projects that use libtool Date: Wed, 15 Feb 2017 21:29:11 -0500 Message-ID: <20170216022910.GL1520@brightrain.aerifal.cx> References: <20170216020612.GB20945@comcast.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1487212169 31796 195.159.176.226 (16 Feb 2017 02:29:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 16 Feb 2017 02:29:29 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-11061-gllmg-musl=m.gmane.org@lists.openwall.com Thu Feb 16 03:29:23 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1ceBow-0007jt-QK for gllmg-musl@m.gmane.org; Thu, 16 Feb 2017 03:29:22 +0100 Original-Received: (qmail 23760 invoked by uid 550); 16 Feb 2017 02:29:26 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 23731 invoked from network); 16 Feb 2017 02:29:25 -0000 Content-Disposition: inline In-Reply-To: <20170216020612.GB20945@comcast.net> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11046 Archived-At: On Wed, Feb 15, 2017 at 06:06:12PM -0800, Charlie Kester wrote: > I have a recurring problem trying to build projects that use libtool. > The link step fails with a message like the one below, for libzip: > > ------------------ > /bin/bash ../libtool --tag=CC --mode=link musl-gcc -O2 -D_GNU_SOURCE > -I/usr/local/musl/include -static -s -static -L/usr/local/musl/lib -o > zipcmp zipcmp.o ../lib/libzip.la -lz > > libtool: link: musl-gcc -O2 -D_GNU_SOURCE -I/usr/local/musl/include -s > -o zipcmp zipcmp.o -L/usr/local/musl/lib ../lib/.libs/libzip.a -lz > > /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/6/crtbegin.o: relocation > R_X86_64_32 against hidden symbol `__TMC_END__' can not be used when > making a shared object > > /usr/bin/ld: final link failed: Nonrepresentable section on output > ------------------- > > (I added blank lines to separate the lines of output, to satisfy > linelength conventions for email.) > > Note that the -static flag was used in both the compile & the link > steps. Yet the linker error seems to indicate that it is still trying > to build a shared library. Worse, it's pulling in modules from glibc. > > I've seen similar error messages with other projects that don't use > libtool, but in those cases it was fixed by adding the -static flag to > the link command in the Makefile. As you can see, however, libtool > seems to be discarding that flag. > > $ /usr/bin/ld --version > GNU ld (GNU Binutils for Debian) 2.27.90.20170205 > > The ltmain.sh included with the libzip sourcecode contains the > following version info: > # libtool (GNU libtool) 2.4.2 > > I'd appreciate any ideas about how to fix this. I see in the wiki's list of > bugs found with musl that something very like this was reported to > the libtool developers as far back as 2012, but I don't see that it > was ever resolved. I suspect the issue is that your toolchain is configured to produce pie by default. /usr/lib/gcc/x86_64-linux-gnu/6/crtbegin.o is not a "module from glibc" but something provided by gcc, and the problem is that you need crtbeginS.o, not crtbegin.o, for PIE, but musl-gcc doesn't know gcc is producing pie by default. You could fix this by adding an explicit -pie or -no-pie or patching musl-gcc.specs to always use crtbeginS.o and crtendS.o. Of course the other issue is that you're trying to produce static-linked programs (where this wouldn't be an issue to begin with, since your system gcc doesn't do pie with static linking, since glibc can't handle it) but libtool is suppressing static linking. You can fix this by passing both -static (which libtool needs to see) and --static (which libtool doesn't know about, so it safely makes it through to gcc without getting stripped by libtool). This is a standard trick for fixing broken programs that use libtool. Rich