This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] powerpc64le build fails with GCC7
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
> > 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
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