This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Bootstrap build problem after V8 test-in-container patch".
- From: Steve Ellcey <sellcey at cavium dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Mon, 24 Sep 2018 19:38:59 +0000
- Subject: Re: Bootstrap build problem after V8 test-in-container patch".
- References: <xno9cmlsn2.fsf@greed.delorie.com>
- Reply-to: <sellcey at cavium dot com>
On Mon, 2018-09-24 at 13:20 -0400, DJ Delorie wrote:
>
> Sorry, been a busy couple of weeks. Carlos and I did talk about this,
> and the guidance he gave me was "If build-many-glibcs can build it, and
> you can't, you need to do what build-many-glibcs does."
>
> But otherwise, IMHO the build of the test program should be deferred
> until we actually need it, but someone with more insight into how the
> build rules works would need to help with that because I haven't figured
> out how to get that work quite right yet :-P
>
> Additionally, configure could be pickier about setting/clearing the CXX
> variable, or failing if it's set to something unusable, but that's just
> error protection rather than "make sure it works."
So it looks like the reason it works for build-many-glibcs but not me
is that build-many-glibcs is setting CXX to a non-existent g++
compiler, i.e. /blah/blah/g++. I set CXX to just g++ and then
configure uses the PATH variable ro search the directory where I just
built the new gcc (but no g++), doesn't find it, then finds the system
g++ in /usr/bin and uses that which triggers the bug.
So I guess I can just set CXX (and CC) to explicit paths and if that
CXX does not exist, things seem to work OK.
Steve Ellcey
sellcey@cavium.com