This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Compiler for testing a bootstrapped glibc?
- From: Brooks Moses <bmoses at google dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: libc-alpha <libc-alpha at sourceware dot org>
- Date: Wed, 5 Mar 2014 18:04:31 -0800
- Subject: Re: Compiler for testing a bootstrapped glibc?
- Authentication-results: sourceware.org; auth=none
- References: <CAOxa4KrctdEQWfXbfd7Xk-=cFcskzUSMASCFaa2Lgf3USPPmKg at mail dot gmail dot com> <530FA88D dot 9050009 at redhat dot com>
On Thu, Feb 27, 2014 at 1:05 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 02/27/2014 02:49 PM, Brooks Moses wrote:
>> There are a couple of solution directions that I've thought of:
>>
>> 1) Build a dynamic GCC using the just-built glibc, and install it on
>> top of the static-only GCC we used for building. This is arguably
>> simpler, but means rebuilding anything in glibc after testing will get
>> different results than before testing. It also increases the overall
>> build-and-test time.
[...]
>> How do other people handle this?
>
> My opinion is that everyone does #1.
Thanks for the confirmation -- and to Joseph for the cautions about
probably wanting to reconfigure and rebuild glibc with the new GCC to
avoid erroneous-configuration problems around things like whether C++
is detected. That's what I ended up implementing for now, and it's
working well enough.
Joseph, I've forgotten from test your patch sequence, but I think you
mentioned it: How far away are we from having all test files starting
with tst-* or a related pattern? It seems to me that if we made sure
that was always followed, we could put in separate rules for building
test programs that would (optionally) use a different compiler, and
thereby at least avoid the rebuild-glibc step. If that seems
feasible, I'd be happy to work on a patch.
- Brooks