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.
