Created attachment 849664 [details] gcc-build-logs.tar.xz Repro steps: 1. crossdev powerpc-gentoo-linux-musl (this succeeds) 2. powerpc-gentoo-linux-musl-emerge -v1 sys-devel/gcc (fails) Got the following: ``` /usr/powerpc-gentoo-linux-musl/tmp/portage/sys-devel/gcc-12.2.1_p20230121-r1/work/gcc-12-20230121/libgcc/dfp-bit.h:291:2: error: #error "unknown long double size, cannot define BFP_FMT" ``` ---- # powerpc-gentoo-linux-musl-emerge --info Portage 3.0.44 (python 3.11.1-final-0, embedded, gcc-12, unavailable, 6.1.8-gentoo-dist-hardened x86_64) ================================================================= System uname: Linux-6.1.8-gentoo-dist-hardened-x86_64-AMD_Ryzen_9_3950X_16-Core_Processor-with-glibc2.36 KiB Mem: 65758020 total, 7026768 free KiB Swap: 8290300 total, 4482044 free Timestamp of repository gentoo: Wed, 01 Feb 2023 23:17:06 +0000 sh dash 0.5.12 ld GNU ld (Gentoo 2.40 p1) 2.40 ccache version 4.7.4 [disabled] sys-devel/gcc-config: 2.10::gentoo sys-libs/musl: 1.2.3-r6::gentoo Repositories: gentoo location: /var/db/repos/gentoo sync-type: rsync sync-uri: rsync://rsync.gentoo.org/gentoo-portage priority: -1000 volatile: True sync-rsync-verify-metamanifest: yes sync-rsync-verify-max-age: 24 sync-rsync-extra-opts: sync-rsync-verify-jobs: 1 ACCEPT_KEYWORDS="ppc ~ppc" ACCEPT_LICENSE="@FREE" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -fomit-frame-pointer" CHOST="powerpc-gentoo-linux-musl" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php8.2/ext-active/ /etc/php/cgi-php8.2/ext-active/ /etc/php/cli-php8.2/ext-active/ /etc/php/fpm-php8.2/ext-active/ /etc/php/phpdbg-php8.2/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-O2 -pipe -fomit-frame-pointer" DISTDIR="/var/cache/distfiles" ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GDK_PIXBUF_MODULE_FILE GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR XDG_STATE_HOME" FCFLAGS="-Os -pipe" FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs buildpkg buildpkg-live config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news nodoc noinfo noman parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-Os -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_GB.utf8" LDFLAGS="" LEX="reflex" LINGUAS="en" PKGDIR="/usr/powerpc-gentoo-linux-musl/var/cache/binpkgs/" PORTAGE_CONFIGROOT="/usr/powerpc-gentoo-linux-musl/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/usr/powerpc-gentoo-linux-musl/tmp/" SHELL="/bin/bash" USE="kdrive minimal multicall ppc zlib" ELIBC="musl" INPUT_DEVICES="evdev" KERNEL="linux" USERLAND="GNU" VIDEO_CARDS="fbdev" YACC="byacc" Unset: ADDR2LINE, AR, ARFLAGS, AS, ASFLAGS, CC, CCLD, CONFIG_SHELL, CPP, CPPFLAGS, CTARGET, CXX, CXXFILT, ELFEDIT, EMERGE_DEFAULT_OPTS, EXTRA_ECONF, F77FLAGS, FC, GCOV, GPROF, INSTALL_MASK, LC_ALL, LD, LFLAGS, LIBTOOL, MAKE, MAKEFLAGS, MAKEOPTS, NM, OBJCOPY, OBJDUMP, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, RANLIB, READELF, RUSTFLAGS, SIZE, STRINGS, STRIP, YFLAGS
See also https://archives.gentoo.org/gentoo-dev/message/ae9ffb2055c768c70a40a4e672b85a2d.
Is this still happening?
Issue still occurs with sys-devel/gcc-13.2.1_p20231014
(In reply to Sam James from comment #1) > See also > https://archives.gentoo.org/gentoo-dev/message/ae9ffb2055c768c70a40a4e672b85a2d. I hit this bug on sys-devel/gcc-13.2.1_p20231216. After patching toolchain.eclass with the linked patch, I get the following error: ``` make[2]: *** No rule to make target '/usr/powerpc-gentoo-linux-musl/tmp/portage/sys-devel/gcc-13.2.1_p20231216/work/gcc-13-20231216/libgcc/../libdecnumber/no/decimal32.c', needed by 'decimal32.o'. Stop. ```
The code path with the error is within a `LONG_DOUBLE_HAS_TF_MODE` branch, which means that the build system thinks it can use 16B long doubles. It can't, at least not on the system I'm compiling for (ppc32 G4). Why does it think so? I see that the commands used to compile GCC include `-mlong-double-128`. That might be the culprit, and the switch shouldn't be there anyway. However, augmenting the linked patch with `confgcc+=( --without-long-double-128 )` changes nothing (and it should be the default on non-glibc systems anyway, at least according to https://gcc.gnu.org/install/configure.html).
I think I'm wrong about `-mlong-double-128` being an issue – it seems that the code in question is getting compiled with varying compile-time switches to produce object files for different scenarios. The root cause of the bug is probably elsewhere.
I managed to make the build work using two hacky patches, one for the toolchain eclass and the other one for the GCC build system. I'm attaching them both. I only did light testing of the result, though, so it is entirely possible that the built compiler is somewhat broken. Basically, passing `-mlong-double-128` when building libgcc is really the error, but not passing it causes some files to fail to build because of missing typedefs. The `-mlong-double-128` option is set in `libgcc/config/rs6000/t-linux`. The entire contents of that file are dubious, but commenting out the line with that flag is sufficient. In addition to that, it is necessary to set `libgcc_cv_powerpc_float128=no` and pass `--without-long-double-128` to configure, so that libgcc doesn't attempt to use the 128b double types. A possibly related bug which I found after the fact: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97543
Created attachment 882679 [details, diff] A fix to toolchain.eclass that disables use of 128b long double with 32b ppc musl Signed-off-by: Jonáš Vidra <vidra@ufal.mff.cuni.cz>
Created attachment 882680 [details, diff] A fix to GCC's rs6000/t-linux config that disables use of 128b long double on musl 32b ppc Signed-off-by: Jonáš Vidra <vidra@ufal.mff.cuni.cz>
(In reply to jonys from comment #9) > Created attachment 882680 [details, diff] [details, diff] > A fix to GCC's rs6000/t-linux config that disables use of 128b long double > on musl 32b ppc s/on musl 32b ppc/unconditionally/ Sorry about that, it's a hack. :-)
The same bug is present when cross-compiling =sys-devel/gcc-13.2.1_p20240113-r1 for powerpc64-gentoo-linux-musl. After modifying the `if` statement in the eclass patch to also apply on ppc64, the attached patches fix the problem there as well. I changed the test to include `powerpc64-*-musl` and copied the whole block to the `ppc64)` cond clause below. Of note is that there is already a fix for this (or very similar) problem in the `ppc64)` block, but it is set up to only apply on ppc64le and changing it to apply on BE as well didn't fix the problem for me.
Created attachment 898073 [details, diff] A fix to GCC configure scripts to not use 128b ldbl when on ppc{,64}-musl Here is a new patch which conditionally disables the use of 128b long double when on a powerpc or powerpc64 musl target. I built and tested GCC with these patches on native ppc32 hardware with musl. Not tested on ppc64 (but it should apply equally there) or any of the glibc ppc{,64}-gnu hosts (where the patch should be a no-op).
I am *not* seeing the same messages as the original report, but I have been told they are close enough and should be tracked here as well: /var/tmp/portage/sys-devel/gcc-15.0.9999/work/gcc-15.0.9999/libquadmath/math/../../libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF' 69 | typedef float TFtype __attribute__ ((mode (TF))); | ^~~~~~~ make[3]: *** [Makefile:984: math/sqrtq.lo] Error 1 make[3]: Leaving directory '/var/tmp/portage/sys-devel/gcc-15.0.9999/work/build/powerpc64-gentoo-linux-musl/libquadmath' This is because GCC cannot emulate quad-precision on ppc (it is trying to do soft-fp but the soft-fp emulation for quad requires VSX, which for some reason, despite -mcpu=power9, gcc doesn't seem to realise it has - probably because --with-cpu isn't set). On musl targets, it doesn't seem that libquadmath can ever be built (at least unless and until the _f128 ABI[1] is merged). I'm working on a patch in my branch[2] for that, but right now it's failing to build Fortran: In file included from /var/tmp/portage/sys-devel/gcc-15.0.9999/work/gcc-15.0.9999/libgfortran/intrinsics/time.c:26: /var/tmp/portage/sys-devel/gcc-15.0.9999/work/gcc-15.0.9999/libgfortran/libgfortran.h:62:11: fatal error: quadmath_weak.h: No such file or directory 62 | # include "quadmath_weak.h" | ^~~~~~~~~~~~~~~~~ compilation terminated. make[3]: *** [Makefile:4274: intrinsics/time.lo] Error 1 [1]: https://www.openwall.com/lists/musl/2018/10/25/1 [2]: https://github.com/awilfox/gentoo/commits/awilfox/bug892874/
(In reply to A. Wilcox (awilfox) from comment #13) > I am *not* seeing the same messages as the original report, but I have been > told they are close enough and should be tracked here as well: (The reason also being that I suspect the entire handling of this rn is a mess and we need to sort it out, and it's a common cause for both.)
*** Bug 929241 has been marked as a duplicate of this bug. ***
The patch does not work on ppc64: /var/tmp/portage/sys-devel/gcc-15.0.9999/work/gcc-15.0.9999/libgcc/config/rs6000/ibm-ldouble.c:64:21: error: unknown type name '__ibm128'; did you mean '__int128'? 64 | #define IBM128_TYPE __ibm128 | ^~~~~~~~ /var/tmp/portage/sys-devel/gcc-15.0.9999/work/gcc-15.0.9999/libgcc/config/rs6000/ibm-ldouble.c:78:1: note: in expansion of macro 'IBM128_TYPE' 78 | IBM128_TYPE __gcc_qadd (double, double, double, double); | ^~~~~~~~~~~ /var/tmp/portage/sys-devel/gcc-15.0.9999/work/gcc-15.0.9999/libgcc/config/rs6000/ibm-ldouble.c:64:21: error: unknown type name '__ibm128'; did you mean '__int128'? 64 | #define IBM128_TYPE __ibm128 | ^~~~~~~~ /var/tmp/portage/sys-devel/gcc-15.0.9999/work/gcc-15.0.9999/libgcc/config/rs6000/ibm-ldouble.c:79:1: note: in expansion of macro 'IBM128_TYPE' 79 | IBM128_TYPE __gcc_qsub (double, double, double, double); | ^~~~~~~~~~~ /var/tmp/portage/sys-devel/gcc-15.0.9999/work/gcc-15.0.9999/libgcc/config/rs6000/ibm-ldouble.c:64:21: error: unknown type name '__ibm128'; did you mean '__int128'? 64 | #define IBM128_TYPE __ibm128 | ^~~~~~~~ /var/tmp/portage/sys-devel/gcc-15.0.9999/work/gcc-15.0.9999/libgcc/config/rs6000/ibm-ldouble.c:80:1: note: in expansion of macro 'IBM128_TYPE' 80 | IBM128_TYPE __gcc_qmul (double, double, double, double); | ^~~~~~~~~~~ /var/tmp/portage/sys-devel/gcc-15.0.9999/work/gcc-15.0.9999/libgcc/config/rs6000/ibm-ldouble.c:64:21: error: unknown type name '__ibm128'; did you mean '__int128'? 64 | #define IBM128_TYPE __ibm128 | ^~~~~~~~ /var/tmp/portage/sys-devel/gcc-15.0.9999/work/gcc-15.0.9999/libgcc/config/rs6000/ibm-ldouble.c:81:1: note: in expansion of macro 'IBM128_TYPE' 81 | IBM128_TYPE __gcc_qdiv (double, double, double, double); | ^~~~~~~~~~~ /var/tmp/portage/sys-devel/gcc-15.0.9999/work/gcc-15.0.9999/libgcc/config/rs6000/ibm-ldouble.c:64:21: error: unknown type name '__ibm128'; did you mean '__int128'? 64 | #define IBM128_TYPE __ibm128 | ^~~~~~~~ /var/tmp/portage/sys-devel/gcc-15.0.9999/work/gcc-15.0.9999/libgcc/config/rs6000/ibm-ldouble.c:102:15: note: in expansion of macro 'IBM128_TYPE' 102 | static inline IBM128_TYPE | ^~~~~~~~~~~ /var/tmp/portage/sys-devel/gcc-15.0.9999/work/gcc-15.0.9999/libgcc/config/rs6000/ibm-ldouble.c: In function 'pack_ldouble': /var/tmp/portage/sys-devel/gcc-15.0.9999/work/gcc-15.0.9999/libgcc/config/rs6000/ibm-ldouble.c:64:21: error: unknown type name '__ibm128'; did you mean '__int128'? 64 | #define IBM128_TYPE __ibm128 | ^~~~~~~~ /var/tmp/portage/sys-devel/gcc-15.0.9999/work/gcc-15.0.9999/libgcc/config/rs6000/ibm-ldouble.c:111:5: note: in expansion of macro 'IBM128_TYPE' 111 | IBM128_TYPE ldval; | ^~~~~~~~~~~ /var/tmp/portage/sys-devel/gcc-15.0.9999/work/gcc-15.0.9999/libgcc/config/rs6000/ibm-ldouble.c: At top level: /var/tmp/portage/sys-devel/gcc-15.0.9999/work/gcc-15.0.9999/libgcc/config/rs6000/ibm-ldouble.c:64:21: error: unknown type name '__ibm128'; did you mean '__int128'? 64 | #define IBM128_TYPE __ibm128 | ^~~~~~~~ /var/tmp/portage/sys-devel/gcc-15.0.9999/work/gcc-15.0.9999/libgcc/config/rs6000/ibm-ldouble.c:121:15: note: in expansion of macro 'IBM128_TYPE' 121 | static inline IBM128_TYPE | ^~~~~~~~~~~ /var/tmp/portage/sys-devel/gcc-15.0.9999/work/gcc-15.0.9999/libgcc/config/rs6000/ibm-ldouble.c:64:21: error: unknown type name '__ibm128'; did you mean '__int128'? 64 | #define IBM128_TYPE __ibm128 | ^~~~~~~~ /var/tmp/portage/sys-devel/gcc-15.0.9999/work/gcc-15.0.9999/libgcc/config/rs6000/ibm-ldouble.c:160:1: note: in expansion of macro 'IBM128_TYPE' 160 | IBM128_TYPE | ^~~~~~~~~~~ /var/tmp/portage/sys-devel/gcc-15.0.9999/work/gcc-15.0.9999/libgcc/config/rs6000/ibm-ldouble.c:64:21: error: unknown type name '__ibm128'; did you mean '__int128'? 64 | #define IBM128_TYPE __ibm128 | ^~~~~~~~ /var/tmp/portage/sys-devel/gcc-15.0.9999/work/gcc-15.0.9999/libgcc/config/rs6000/ibm-ldouble.c:166:1: note: in expansion of macro 'IBM128_TYPE' 166 | IBM128_TYPE | ^~~~~~~~~~~ /var/tmp/portage/sys-devel/gcc-15.0.9999/work/gcc-15.0.9999/libgcc/config/rs6000/ibm-ldouble.c:64:21: error: unknown type name '__ibm128'; did you mean '__int128'? 64 | #define IBM128_TYPE __ibm128 | ^~~~~~~~ /var/tmp/portage/sys-devel/gcc-15.0.9999/work/gcc-15.0.9999/libgcc/config/rs6000/ibm-ldouble.c:176:1: note: in expansion of macro 'IBM128_TYPE' 176 | IBM128_TYPE | ^~~~~~~~~~~ /var/tmp/portage/sys-devel/gcc-15.0.9999/work/gcc-15.0.9999/libgcc/config/rs6000/ibm-ldouble.c:64:21: error: unknown type name '__ibm128'; did you mean '__int128'? 64 | #define IBM128_TYPE __ibm128 | ^~~~~~~~ /var/tmp/portage/sys-devel/gcc-15.0.9999/work/gcc-15.0.9999/libgcc/config/rs6000/ibm-ldouble.c:208:1: note: in expansion of macro 'IBM128_TYPE' 208 | IBM128_TYPE | ^~~~~~~~~~~ make[3]: *** [/var/tmp/portage/sys-devel/gcc-15.0.9999/work/gcc-15.0.9999/libgcc/shared-object.mk:14: ibm-ldouble.o] Error 1 make[3]: Leaving directory '/var/tmp/portage/sys-devel/gcc-15.0.9999/work/build/powerpc64-gentoo-linux-musl/libgcc'
(In reply to A. Wilcox (awilfox) from comment #16) > The patch does not work on ppc64 I just built gcc-13.3.1_p20240614 in a freshly-created ppc64 musl crossdev (stable 23.0 profile) using the patch above without any issues. Newer (currently ~ppc64) gcc-14.1.1_p20240622 fails to build with ``` libtool: compile: powerpc64-unknown-linux-musl-c++ --sysroot=/usr/powerpc64-unknown-linux-musl -I/usr/powerpc64-unknown-linux-musl/tmp/portage/sys-devel/gcc-14.1.1_p20240622/work/gcc-14-20240622/libstdc++-v3/../libgcc -I/usr/powerpc64-unknown-linux-musl/tmp/portage/sys-devel/gcc-14.1.1_p20240622/work/build/powerpc64-unknown-linux-musl/libstdc++-v3/include/powerpc64-unknown-linux-musl -I/usr/powerpc64-unknown-linux-musl/tmp/portage/sys-devel/gcc-14.1.1_p20240622/work/build/powerpc64-unknown-linux-musl/libstdc++-v3/include -I/usr/powerpc64-unknown-linux-musl/tmp/portage/sys-devel/gcc-14.1.1_p20240622/work/gcc-14-20240622/libstdc++-v3/libsupc++ -std=gnu++23 -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=print.lo -fimplicit-templates -g -mcpu=G5 -pipe -O2 -D_GNU_SOURCE -std=gnu++26 -c /usr/powerpc64-unknown-linux-musl/tmp/portage/sys-devel/gcc-14.1.1_p20240622/work/gcc-14-20240622/libstdc++-v3/src/c++23/print.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o print.o powerpc64-unknown-linux-musl-c++: error: unrecognized command-line option ‘-std=gnu++26’; did you mean ‘-std=gnu++20’? ``` I'll try building it unpatched as well to see whether that fixes it, but I think it's an unrelated error.
(In reply to jonys from comment #17) > Newer (currently ~ppc64) gcc-14.1.1_p20240622 fails to build with > ``` > powerpc64-unknown-linux-musl-c++: error: unrecognized command-line option > ‘-std=gnu++26’; did you mean ‘-std=gnu++20’? > ``` > > I'll try building it unpatched as well to see whether that fixes it, but I > think it's an unrelated error. Without the patch it fails with the same error as in the bug title and first post, it doesn't even get to libstdc++. I found someone on the forums who stumbled upon the same error as in the quote above while cross-compiling for AArch64: https://forums.gentoo.org/viewtopic-t-1169816-start-0.html
The issue you're hitting is unrelated and generic across targets.
(In reply to Sam James from comment #19) > The issue you're hitting is unrelated and generic across targets. Yes, the intended meaning of my message was that the patch is still necessary for gcc-14.1.1_p20240622 on ppc64, even though it doesn't build anyway.
Created attachment 898241 [details, diff] toolchain.eclass patch Can you try this patch atop ::gentoo? It seems to work here with gcc trunk. I've opened an MR at https://github.com/gentoo/gentoo/pull/37689 but I am still testing it with other GCC versions.
I'm not sure how I feel about this. GCC 12 and 13 build file with libquadmath, because it doesn't require the TF emulation yet, which means you can actually use some quad-prec stuff on musl if you build manually. This does build those versions of GCC just fine, but with that support now ripped out, so you can never access float128 at all. It's probably safer to do that, since the libc doesn't know about float128, but it's still kind of iffy to me. I'd love to know what others think.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=18cf313474587d078b1520f03511433ead141de4 commit 18cf313474587d078b1520f03511433ead141de4 Author: A. Wilcox <AWilcox@Wilcox-Tech.com> AuthorDate: 2024-07-21 16:06:59 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-07-31 00:01:47 +0000 toolchain.eclass: ppc64-musl: Disable libquadmath * --disable-libquadmath is needed to avoid GCC PR 116007. * --disable-libquadmath-support is needed for Fortran to build, as GCC upstream requires a weak header when float128 is available. * --with-long-double-128=no explicitly disables all Float128 support. [sam: Fix whitespace.] Bug: https://bugs.gentoo.org/892874 Signed-off-by: A. Wilcox <AWilcox@Wilcox-Tech.com> Closes: https://github.com/gentoo/gentoo/pull/37689 Signed-off-by: Sam James <sam@gentoo.org> eclass/toolchain.eclass | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
Bug is still happening for powerpc64-unknown-linux-musl: .... powerpc64-unknown-linux-musl-cc --sysroot=/usr/powerpc64-unknown-linux-musl -g -mcpu=970 -pipe -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -O2 -O2 -g -mcpu=970 -pipe -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -O2 -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -mlong-double-128 -mno-minimal-toc -DGTHREAD_USE_WEAK=0 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fno-stack-clash-protection -fPIC -mlong-double-128 -mno-minimal-toc -DGTHREAD_USE_WEAK=0 -I. -I. -I../.././gcc -I/usr/powerpc64-unknown-linux-musl/tmp/portage/sys-devel/gcc-13.3.1_p20240614/work/gcc-13-20240614/libgcc -I/usr/powerpc64-unknown-linux-musl/tmp/portage/sys-devel/gcc-13.3.1_p20240614/work/gcc-13-20240614/libgcc/. -I/usr/powerpc64-unknown-linux-musl/tmp/portage/sys-devel/gcc-13.3.1_p20240614/work/gcc-13-20240614/libgcc/../gcc -I/usr/powerpc64-unknown-linux-musl/tmp/portage/sys-devel/gcc-13.3.1_p20240614/work/gcc-13-20240614/libgcc/../include -I/usr/powerpc64-unknown-linux-musl/tmp/portage/sys-devel/gcc-13.3.1_p20240614/work/gcc-13-20240614/libgcc/../libdecnumber/dpd -I/usr/powerpc64-unknown-linux-musl/tmp/portage/sys-devel/gcc-13.3.1_p20240614/work/gcc-13-20240614/libgcc/../libdecnumber -DHAVE_CC_TLS -mno-gnu-attribute -Wno-psabi -mabi=ibmlongdouble -o _sd_to_tf.o -MT _sd_to_tf.o -MD -MP -MF _sd_to_tf.dep -DFINE_GRAINED_LIBRARIES -DL_sd_to_tf -DWIDTH=32 -c /usr/powerpc64-unknown-linux-musl/tmp/portage/sys-devel/gcc-13.3.1_p20240614/work/gcc-13-20240614/libgcc/dfp-bit.c In file included from /usr/powerpc64-unknown-linux-musl/tmp/portage/sys-devel/gcc-13.3.1_p20240614/work/gcc-13-20240614/libgcc/dfp-bit.c:40: /usr/powerpc64-unknown-linux-musl/tmp/portage/sys-devel/gcc-13.3.1_p20240614/work/gcc-13-20240614/libgcc/dfp-bit.h:291:2: error: #error "unknown long double size, cannot define BFP_FMT" 291 | #error "unknown long double size, cannot define BFP_FMT" | ^~~~~ make[2]: *** [Makefile:722: _sd_to_tf.o] Error 1
environment: - fresh portage tree (as of 01 Aug 2024 20:39 UTC) - sys-devel/gcc-13.3.1_p20240614 - sys-devel/crossdev-20240209 - CFLAGS set for PPC970FX as per "Safe CFLAGS" wiki article + LTO, but ebuild for gcc strips lto, so it should be safe. crosstoolchain made with crossdev -S -t powerpc64-unknown-linux-musl
Created attachment 898794 [details] emerge-powerpc64-unknown-linux-musl --info
Created attachment 898795 [details] /usr/powerpc64-unknown-linux-musl/tmp/portage/sys-devel/gcc-13.3.1_p20240614/work/gcc-build-logs.tar.xz
commit 0c0c2e1768b4487de2b7c8be05c5e8b1b6d8f9aa (HEAD -> master, origin/master, origin/HEAD) Author: Sam James <sam@gentoo.org> Date: Sun Aug 11 00:14:15 2024 +0100 sys-devel/gcc: add 14.2.1_p20240810 Signed-off-by: Sam James <sam@gentoo.org>
