[PATCH] powerpc64le build fails with GCC7

[Alexey Neyman]

On 08/21/2017 10:20 AM, Joseph Myers wrote:
> On Mon, 21 Aug 2017, Alexey Neyman wrote:
>
>> Hi all,
>>
>> With GCC7, the test for -mfloat128 fails with a message that this option
>> requires -mfloat128-type to be supplied as well. Cannot supply both options
>> unconditionally, though, as GCC6 would choke on unknown option.
> Could you explain further what the circumstances are under which this is
> or is not needed, given that people have evidently been building without
> this option, presumably with GCC configured differently?
This issue occurred during the bootstrap pass-1 of the 
'powerpc64le-unknown-linux-gnu' sample in the crosstool-NG. Crosstool-NG 
does three builds of GCC:
- "bootstrap pass-1" builds just the GCC itself with only C language - 
it is then used to build the CRT and install headers from the selected libc
- "bootstrap pass-2" builds GCC with only C language, with headers/CRT 
already in the sysroot (so it can build libgcc) - it is then used to 
build the libc
- "final pass" builds GCC with all the enabled languages and libraries.

GCC was configured as follows:

/home/avn/work/ctng/crosstool-ng/.build/powerpc64le-unknown-linux-gnu/build/src/gcc/configure 
--build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu 
--target=powerpc64le-unknown-linux-gnu 
--prefix=/home/avn/work/ctng/crosstool-ng/.build/powerpc64le-unknown-linux-gnu/buildtools 
--with-local-prefix=/home/avn/x-tools/powerpc64le-unknown-linux-gnu/powerpc64le-unknown-linux-gnu/sysroot 
--with-sysroot=/home/avn/x-tools/powerpc64le-unknown-linux-gnu/powerpc64le-unknown-linux-gnu/sysroot 
--with-newlib --enable-threads=no --disable-shared 
--with-pkgversion='crosstool-NG crosstool-ng-1.23.0-174-g9ee0e06f' 
--enable-__cxa_atexit --disable-libgomp --disable-libmudflap 
--disable-libmpx --disable-libssp --disable-libquadmath 
--disable-libquadmath-support 
--with-gmp=/home/avn/work/ctng/crosstool-ng/.build/powerpc64le-unknown-linux-gnu/buildtools 
--with-mpfr=/home/avn/work/ctng/crosstool-ng/.build/powerpc64le-unknown-linux-gnu/buildtools 
--with-mpc=/home/avn/work/ctng/crosstool-ng/.build/powerpc64le-unknown-linux-gnu/buildtools 
--with-isl=/home/avn/work/ctng/crosstool-ng/.build/powerpc64le-unknown-linux-gnu/buildtools 
--enable-lto --with-host-libstdcxx='-static-libgcc 
-Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --enable-target-optspace 
--disable-nls --disable-multilib --enable-languages=c

Now that you mentioned that it has been building successfully, I tried 
the same option with the "pass-2" bootstrap compiler and this option 
worked fine.

The difference between the pass-1 and pass-2 compilers is:
pass-1: --with-newlib --enable-threads=no --disable-shared
pass-2: --enable-shared

I then tried configuring pass-2 compiler in the same way as pass-1 and 
-mfloat128 still worked even without -mfloat128-type. So, GCC's 
configure selects different setting for TARGET_FLOAT128_TYPE depending 
on whether the headers are already installed in sysroot.

In other words, it works when configuring GCC against a sysroot with a 
previously built/installed GLIBC headers. But it doesn't work when 
bootstrapping from the ground up.

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.

Regards,
Alexey.


>
> You should not need to edit the toplevel configure.ac or config.make.in to
> set an architecture-specific makefile variable.  Rather, use
> LIBC_CONFIG_VAR in the sysdeps configure.ac to set such a variable without
> needing to change system-independent files.
>