Would starting from Advance Toolchain 15 with the most recent glibc make things easier for Thomas to test?
Thanks, Bill On 10/29/21 4:06 PM, Michael Meissner via Gcc wrote: > On Fri, Oct 29, 2021 at 09:07:38PM +0200, Thomas Koenig wrote: >> Hi Michael, >> >> I tried this out on the one POWER machine where I can get something >> installed :-) It runs Ubuntu 20.04, but does not appear to have the >> right glibc version; it has >> >> $ lsb_release -a >> No LSB modules are available. >> Distributor ID: Ubuntu >> Description: Ubuntu 20.04.1 LTS >> Release: 20.04 >> Codename: focal >> $ ldd --version >> ldd (Ubuntu GLIBC 2.31-0ubuntu9.1) 2.31 >> >> Configure was >> >> ./trunk/configure --prefix=$HOME --enable-languages=c,c++,fortran >> --with-advance-toolchain=at15.0 >> --with-native-system-header-dir=/opt/at15.0/include >> --with-long-double-format=ieee >> >> and the error message >> >> msgfmt -o fr.mo ../../../../trunk/libstdc++-v3/po/fr.po >> msgfmt: /lib/powerpc64le-linux-gnu/libm.so.6: version `GLIBC_2.32' not found >> (required by >> /home/ig25/trunk-bin/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6) >> msgfmt: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.33' not found >> (required by >> /home/ig25/trunk-bin/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6) >> msgfmt: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.34' not found >> (required by >> /home/ig25/trunk-bin/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6) >> msgfmt: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.32' not found >> (required by >> /home/ig25/trunk-bin/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6) >> msgfmt: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.34' not found >> (required by /home/ig25/trunk-bin/./gcc/libgcc_s.so.1) >> >> and so on. >> >> Since gcc135 is also too old, that exhausts my possibilities at testing. >> >> Any hints on how best to proceed? >> >> Best regards > As I've delved into it, it looks glibc 2.34 is really only needed for > switching > long double over to IEEE 128-bit, since it has all of the F128 functions that > would be needed. That is because Fortran uses the 'q' names which are in > libquadmath (that should be built). > > I built the original version with: > > --prefix=/home/meissner/fsf-install-ppc64le/fortran-orig \ > --enable-languages=c,c++,fortran \ > --disable-plugin \ > --enable-checking \ > --enable-stage1-checking \ > --enable-gnu-indirect-function \ > --disable-libgomp \ > --enable-decimal-float \ > --enable-secureplt \ > --enable-threads=posix \ > --enable-__cxa_atexit \ > --with-long-double-128 \ > --with-long-double-format=ibm \ > --with-cpu=power9 \ > --with-as=/opt/at12.0/bin/as \ > --with-ld=/opt/at12.0/bin/ld \ > --with-gnu-as=/opt/at12.0/bin/as \ > --with-gnu-ld=/opt/at12.0/bin/ld \ > --with-gmp=/home/meissner/tools-compiler/ppc64le \ > --with-mpfr=/home/meissner/tools-compiler/ppc64le \ > --with-mpc=/home/meissner/tools-compiler/ppc64le \ > --without-ppl \ > --without-cloog \ > --without-isl > > I needed to build my own version of mpfs, mpc, and gmp. I built them without > shared libraries, because I get messages like you get. > > I have a new version of the patch that makes new target hooks to allow the > backend to specify KIND numbers for types. I choose kind=16 to always be IEEE > 128-bit, and kind=15 to be long double if long double is IBM (since I > discovered yesterday, Fortran needs to be able to deal with long double). I'm > in the middle of the build an on internal IBM system, and I will start the > build on gcc135 shortly. >
