Bootstrap build problem after V8 test-in-container patch".

Bootstrap build problem after V8 test-in-container patch".

[Steve Ellcey]

I am having a build problem after DJ's patch "V8 test-in-container patch".

I do a bootstrap build by building binutils, then I build a 'partial gcc'
by building "all-gcc all-target-libgcc" and
"install-gcc install-target-libgcc", then I build glibc using that gcc,
followed by a complete build of gcc.

This is no longer working for me, because the glibc build fails with:

aarch64-linux-gnu-gcc -mabi=lp64 -nostdlib -nostartfiles -o /home/sellcey/tot/obj/glibc64/support/links-dso-program .....

/home/sellcey/tot/install/lib/gcc/aarch64-linux-gnu/9.0.0/../../../../aarch64-linux-gnu/bin/ld: cannot find -lstdc++

I tried updating my 'initial' gcc build to include all-target-libstdc++-v3
and install-target-libstdc++-v3 and to include c++ in the languages that
are configured but when I do that the initial gcc build fails during the
configuration of libgomp (presumably libstdc++ needs libgomp).  The libgomp
configure fails with:

/home/sellcey/tot/install/aarch64-linux-gnu/bin/ld: cannot find crt1.o: No such 
file or directory
/home/sellcey/tot/install/aarch64-linux-gnu/bin/ld: cannot find crti.o: No such 
file or directory

I think this failure to be able to do a bootstrap build is going to be a
problem, has anyone else run into this?  Does anyone have a fix?

Steve Ellcey
sellcey@cavium.com

Re: Bootstrap build problem after V8 test-in-container patch".

[Joseph Myers]

On Thu, 23 Aug 2018, Steve Ellcey wrote:

> I am having a build problem after DJ's patch "V8 test-in-container patch".
> 
> I do a bootstrap build by building binutils, then I build a 'partial gcc'
> by building "all-gcc all-target-libgcc" and
> "install-gcc install-target-libgcc", then I build glibc using that gcc,
> followed by a complete build of gcc.

The expectation is that the first compiler in a bootstrap build is 
static-only and C-only.  Presumably yours supports C++ as well, enough for

ifeq (,$(CXX))

to fail and so end up trying to link with -lstdc++ -lgcc_s?

Ideally it *would* be possible to build the host side of a full 
multi-language GCC with static-only libgcc, then later build all the 
target libraries including rebuilding libgcc (rather than needing to build 
the host side twice to get it properly configured for shared libraries), 
so one might hope that $(CXX) existing would not by itself cause attempts 
to link with -lstdc++ at glibc build time (as opposed to at *testsuite* 
build time).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Bootstrap build problem after V8 test-in-container patch".

[DJ Delorie]

Steve Ellcey <sellcey@cavium.com> writes:
> /home/sellcey/tot/install/lib/gcc/aarch64-linux-gnu/9.0.0/../../../../aarch64-linux-gnu/bin/ld: cannot find -lstdc++

I had similar problems (with libgcc_s.so.1) during my testing; my code
assumes that if CXX is set to g++, then g++ works.  I'm working with
Carlos to come up with a better way of handling that one program.

Re: Bootstrap build problem after V8 test-in-container patch".

[Steve Ellcey]

On Thu, 2018-08-23 at 20:02 +0000, Joseph Myers wrote:
> External Email
> 
> On Thu, 23 Aug 2018, Steve Ellcey wrote:
> 
> > 
> > I am having a build problem after DJ's patch "V8 test-in-container
> > patch".
> > 
> > I do a bootstrap build by building binutils, then I build a
> > 'partial gcc'
> > by building "all-gcc all-target-libgcc" and
> > "install-gcc install-target-libgcc", then I build glibc using that
> > gcc,
> > followed by a complete build of gcc.
> The expectation is that the first compiler in a bootstrap build is
> static-only and C-only.  Presumably yours supports C++ as well,
> enough for
> 
> ifeq (,$(CXX))
> 
> to fail and so end up trying to link with -lstdc++ -lgcc_s?

I built C only and static only, it looks like what is happening is that
CXX is getting set to the system C++ compiler because /usr/bin is in my
PATH after the directory where I built the 'partial gcc'.  The actual
link of links-dso-program doesn't seem to be using CXX though, it seems
to call CC (aarch64-linux-gnu-gcc) which is in my directory and which
has no corresponding C++ libraries.

Steve Ellcey

Re: Bootstrap build problem after V8 test-in-container patch".

[Steve Ellcey]

On Thu, 2018-08-23 at 16:32 -0400, DJ Delorie wrote:
> 
> Steve Ellcey <sellcey@cavium.com> writes:
> > 
> > /home/sellcey/tot/install/lib/gcc/aarch64-linux-
> > gnu/9.0.0/../../../../aarch64-linux-gnu/bin/ld: cannot find
> > -lstdc++
> I had similar problems (with libgcc_s.so.1) during my testing; my code
> assumes that if CXX is set to g++, then g++ works.  I'm working with
> Carlos to come up with a better way of handling that one program.

DJ, have you and/or Carlos came up with a better way of handling this?
I am still seeing this problem with ToT builds.

Steve Ellcey
sellcey@cavium.com

Re: Bootstrap build problem after V8 test-in-container patch".

[DJ Delorie]

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."

Re: Bootstrap build problem after V8 test-in-container patch".

[Steve Ellcey]

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

Re: Bootstrap build problem after V8 test-in-container patch".

[DJ Delorie]

Or set CXX to "./do not run g++" ;-)

I suppose the intent is to set CC and CXX to $prefix/bin/$target-gcc
etc, whether they exist or not.

Re: Bootstrap build problem after V8 test-in-container patch".

[Zack Weinberg]

On Mon, Sep 24, 2018 at 3:46 PM DJ Delorie <dj@redhat.com> wrote:
> Or set CXX to "./do not run g++" ;-)
> I suppose the intent is to set CC and CXX to $prefix/bin/$target-gcc
> etc, whether they exist or not.

This sounds like a job for automake's "missing" script.

zw

Re: Bootstrap build problem after V8 test-in-container patch".

[DJ Delorie]

Zack Weinberg <zackw@panix.com> writes:

> This sounds like a job for automake's "missing" script.

Heh, the problem happens when it's user-specified but *not* missing,
just the wrong one.  If you're building an arm-linux glibc, and have
CC=arm-linux-gcc but CXX=g++ you get a mismatch because g++ *does*
exist.

If you *don't* set CXX, then yeah, configure can set it to "missing".
But recall my thoughts on configure guessing better ;-)

Re: Bootstrap build problem after V8 test-in-container patch".

[Zack Weinberg]

On Mon, Sep 24, 2018 at 4:23 PM DJ Delorie <dj@redhat.com> wrote:
> Zack Weinberg <zackw@panix.com> writes:
>
> > This sounds like a job for automake's "missing" script.
>
> Heh, the problem happens when it's user-specified but *not* missing,
> just the wrong one.

What I meant was, if you know you have arm-linux-gcc but not
arm-linux-g++, you could explicitly set CXX='${srcdir}/missing g++'
and I _think_ that would get you a nice clear error iff the build
actually tries to use the C++ compiler.

zw