Re: [PATCH] powerpc64le build fails with GCC7

[Joseph Myers <joseph at codesourcery dot com>]

On Mon, 21 Aug 2017, Alexey Neyman wrote:

> On 08/21/2017 02:21 PM, Joseph Myers wrote:
> > On Mon, 21 Aug 2017, Alexey Neyman wrote:
> > 
> > > At this point, I am not sure whether it is a GLIBC bug (i.e. it should
> > > bootstrap regardless of the TARGET_FLOAT128_TYPE setting in GCC) or a GCC
> > > bug
> > > (i.e. it should configure TARGET_FLOAT128_TYPE consistently regardless of
> > > the
> > > headers being present in sysroot). Please advise.
> > I think you should investigate further why the difference in
> > TARGET_FLOAT128_TYPE.
> Michael Meissner has just identified the cause for that difference; it is the
> failing test for "--with-long-double-128". So, the question becomes -
> shouldn't GCC default to 128-bit long doubles on powerpc64le-*-linux targets,
> given this is what GLIBC supports?

I think the GCC default based on old glibc is ridiculous for powerpc64le, 
which never supported such old glibc.  It's dubious generically for all 
targets where the change was in glibc 2.4; there's no obvious reason for 
being able to configure GCC for 64-bit long double on any of those targets 
other than by an explicit configure option.  (Things may be different when 
configured with a target triplet for C libraries other than glibc; my 
comments are specifically for *-linux-gnu* targets.)

But, given the link to that configure option, and given that we check for 
-mlong-double-128 in configure, checking for this other option seems 
reasonable.

> > But, it's always a good idea to configure such a
> > bootstrap compiler with --with-glibc-version=<whatever>, which should
> > avoid any need to find headers in the sysroot.  And on some platforms it's
> > necessary to do so if you want to do a bootstrap with only two rather than
> > three GCC builds (with the first bootstrap GCC being used to build a glibc
> > that's identical to what an alternating series of builds would converge
> > on) as otherwise GCC disagrees with glibc's expectations about
> > stack-smashing protection mechanisms.
> It would not have helped in this case. I'll add this as a further enhancement
> in crosstool-NG, thanks for the tip. Regarding two GCC builds, though - does
> --with-glibc-version=... also obviate the need for crt*.o files when building
> bootstrap GCC (i.e., libgcc)? Currently, crt*.o are built using "bootstrap
> pass-1" compiler and then passed to "bootstrap pass-2" so that it can build
> libgcc.so.

The first build of GCC builds only static libgcc, with inhibit-libc.  
That first build suffices to build glibc.  With that glibc you can then 
build the final GCC, with shared libgcc and non-C-language support.  The 
(stripped) glibc binary should be identical to one resulting from a longer 
sequence of alternating GCC and glibc builds (it was on the platforms I 
tested this on, when implementing --with-glibc-version and the other glibc 
and libgcc build changes required for this).

See build-many-glibcs.py for details of a working modern bootstrap process 
that builds GCC only twice.  Note that this process requires GCC 4.9 or 
later (but so does building current glibc at all).  Also note that you 
need to rebuild glibc with the final compiler if you want to run the full 
testsuite, because parts of that depend on being configured with a 
compiler with C++ support and shared libgcc.

-- 
Joseph S. Myers
joseph@codesourcery.com