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: Adam Conrad <adconrad at 0c3 dot net>
- To: Carlos O'Donell <carlos at redhat dot com>
- 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, 5 Feb 2014 13:11:54 -0700
- 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>
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?
... Adam