link failures when building projects that use libtool

link failures when building projects that use libtool

[Charlie Kester]

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.

Re: link failures when building projects that use libtool

[Rich Felker]

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

Re: link failures when building projects that use libtool

[Charlie Kester]

On Wed 15 Feb 2017 at 18:29:11 PST Rich Felker wrote:
>
>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.

Adding --static to LDFLAGS solved the problem building the
executables that come with libzip.  I expect it will also work for the
other libtool-using projects I've had trouble with.

Thanks for the speedy reply (and, of course, for musl itself)!