This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Temporarily avoid PPC64 LE bootstrap by making GLIBC_2.17 and GLIBC_2.18 equivalent.


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]