Re: [musl] Static linking is broken after creation of DT_TEXTREL segment

[Rich Felker <dalias@libc.org>]

On Mon, Feb 03, 2020 at 05:32:51AM +0100, Markus Wichmann wrote:
> On Sun, Feb 02, 2020 at 10:10:36PM -0500, Rich Felker wrote:
> > I'll probably end up having mcm pass --with-pic to GCC's top-level
> > configure, but I see this will be picked up by some other libs like
> > libcc1, which oddly aren't failing for the same reason. Any idea why?
> 
> I'd guess they don't use assembly, or at least their assembly does not
> try to access global symbols. I haven't looked at the source though. And
> I won't until the afternoon at least.
> 
> > Is this the right fix for mcm? What could/should be done to unbreak
> > gmp with default-pie toolchains? Is it a bug in the version of libtool
> > they're using or a bug in gmp?
> >
> > Rich
> 
> The problem is with the assumptions of GMP. And I really don't know how
> to fix those. GMP's build system generates a dynamic and a static
> library, and assumes that the static library does not need to be PIC.
> With the advent of static-pie, this assumption is subverted. But how to

Even before static-pie it was wrong. If you're making a dynamic-linked
PIE executable but want to static link libgmp, it will be wrong.

> deal with this generally? Many libraries assume the static one does not
> need PIC.

Everything else honors the compiler's default. If $(CC) was built for
default-pie, or if you set CC="gcc -fPIE -pie" or something similar,
you'd get a static library that's PIE-compatible. Only gmp is broken
because its asm is wrongly poking at some libtool vars rather than
__PIC__ from the compiler.

> In case of GMP, I would argue they can add a test to determine if the
> toolchain generates static-pie, and turn on PIC by default if so. No
> clue if upstream will like that, though.

All they need to do is look at __PIC__ in place of whatever wrong test
they're doing now. The question is just how easy this is to patch.

Rich