This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Temporarily avoid PPC64 LE bootstrap by making GLIBC_2.17 and GLIBC_2.18 equivalent.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Adam Conrad <adconrad at 0c3 dot net>
- Cc: Michael Matz <matz at suse dot de>, Andreas Jaeger <aj at suse dot com>, Andreas Schwab <schwab at suse dot de>, Steven Munroe <sjmunroe at us dot ibm dot com>, Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>, Brent Baude <baude at us dot ibm dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>, Jeff Law <law at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Matt Newsome <mnewsome at redhat dot com>
- Date: Wed, 05 Feb 2014 21:16:48 -0500
- Subject: Re: Temporarily avoid PPC64 LE bootstrap by making GLIBC_2.17 and GLIBC_2.18 equivalent.
- Authentication-results: sourceware.org; auth=none
- References: <52EB617D dot 1000609 at redhat dot com> <52F2973F dot 1060409 at redhat dot com> <20140205201154 dot GX15976 at 0c3 dot net>
On 02/05/2014 03:11 PM, Adam Conrad wrote:
> On Wed, Feb 05, 2014 at 02:55:43PM -0500, Carlos O'Donell wrote:
>>
>> Working with Adhemerval we discovered that we need a binutils
>> patch to do the equivalent action but for the static linker.
>
> Wouldn't this only apply if we wanted to statically link against
> our old pre-symbol-change libc, which seems like exactly what we
> don't want anyway?
>
> Maybe I'm missing the subtlety here, but if I install a libc with
> the new 2.17 symbols, and an ld.so that allows the rewrite trick
> on symbol resolution so dynamically linked executables continue
> to function, why would I care about ld's behaviour going forward?
Almost. At some point you'll need to ask the static linker to include
an old library you haven't recompiled against the new 2.17 symbols
and ld will fail saying:
/path/libfoo.so: undefined reference to `puts@GLIBC_2.18'
There are two solutions to this problem:
* Rebuild the library against the new glibc.
or
* Hack the static linker to treat a dependency on @GLIBC_2.18
as if it was a dependency on @GLIBC_2.17.
It turns out that if you want to use SELinux with glibc, and
that's something you *absolutely* need, then you need the static
linker trick. That's because you're building the new glibc with
a libselinux.so that hasn't and can't be rebuilt yet.
I'll provide the static linker hack in a minute and mention
the ugly caveats.
Cheers,
Carlos.