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: Andreas Schwab <schwab at linux-m68k dot org>
- To: Adam Conrad <adconrad at 0c3 dot net>
- Cc: Carlos O'Donell <carlos at redhat dot com>, Michael Matz <matz at suse dot de>, Andreas Jaeger <aj at suse dot com>, 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 22:29:14 +0100
- 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>
Adam Conrad <adconrad@0c3.net> writes:
> 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.
Injecting a cross-compiled libgcc_s.so and libstdc++.so should be enough
to get things started.
> 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?
It's the other way round. A static library does not have version
references, but all existing shared libraries have references to glibc
symbols with the GLIBC_2.18 version, which won't exist any more. Since
you need libstdc++ and libgcc_s (which are part of gcc) just for
building gcc you have a chicken-and-egg problem.
> 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?
The dynamic linker only controls the runtime behaviour.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."