[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170216022910.GL1520@brightrain.aerifal.cx>
Date: Wed, 15 Feb 2017 21:29:11 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: link failures when building projects that use libtool
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
