This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] powerpc64le build fails with GCC7




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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]