Crossdev - Unable to create a musl mips cross-toolchain error: unsupported long double type

Question

Crossdev - Unable to create a musl mips cross-toolchain error: unsupported long double type

Closed this issue 9 months ago · 6 comments

I've been testing using these headers on one of Gentoo build servers and found an issue where crossdev (Gentoo's cross compile toolchain tool) can no longer build musl toolchains.

This was an old bug in Gentoo which was solved a long time ago ( https://bugs.gentoo.org/498114 ) but for some reason when fortify headers is enabled it fails but disabling it makes it work again. I'm stumped as to what could be the cause but more than happy to test any suggestions while I keep looking into possible causes as I really don't know why these headers are causing the issue.

Error:

checking whether compiler's long double definition matches float.h... no
./configure: error: unsupported long double type
 ERROR: cross-mipsel-unknown-linux-musl/musl-1.2.4::local failed (configure phase):

Steps to reproduce:

Install Gentoo Hardened stage3
Add https://git.alpinelinux.org/aports/plain/main/gcc/0016-add-fortify-headers-paths.patch to /etc/portage/patches/sys-devel/gcc
emerge -va sys-devel/gcc
emerge -va sys-devel/crossdev
crossdev -s4 mipsel-unknown-linux-musl

Full build log:

Calculating dependencies  
 * IMPORTANT: 16 news items need reading for repository 'gentoo'.
 * Use eselect news read to view new items.

... done!
Dependency resolution took 1.36 s.


>>> Verifying ebuild manifests

>>> Emerging (1 of 1) cross-mipsel-unknown-linux-musl/musl-1.2.4::local
 * musl-1.2.4.tar.gz BLAKE2B SHA512 size ;-) ...                         [ ok ]
 * getconf.c BLAKE2B SHA512 size ;-) ...                                 [ ok ]
 * musl-getent-93a08815f8598db442d8b766b463d0150ed8e2ab.c BLAKE2B SHA512 size ;-) ...            [ ok ]
 * iconv.c BLAKE2B SHA512 size ;-) ...                                   [ ok ]
>>> Unpacking source...
>>> Unpacking musl-1.2.4.tar.gz to /var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work
>>> Unpacking getconf.c to /var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work
unpack getconf.c: file format not recognized. Ignoring.
>>> Unpacking musl-getent-93a08815f8598db442d8b766b463d0150ed8e2ab.c to /var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work
unpack musl-getent-93a08815f8598db442d8b766b463d0150ed8e2ab.c: file format not recognized. Ignoring.
>>> Unpacking iconv.c to /var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work
unpack iconv.c: file format not recognized. Ignoring.
>>> Source unpacked in /var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work
>>> Preparing source in /var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work/musl-1.2.4 ...
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work/musl-1.2.4 ...
gcc
checking for C compiler... gcc
checking whether C compiler works... yes
checking whether compiler accepts -Werror=unknown-warning-option... no
checking whether compiler accepts -Werror=unused-command-line-argument... no
checking whether compiler accepts -Werror=ignored-optimization-argument... no
checking whether linker accepts -Werror=unknown-warning-option... no
checking whether linker accepts -Werror=unused-command-line-argument... no
checking for C compiler family... gcc
checking target system type... mipsel-unknown-linux-musl
checking whether compiler accepts -std=c99... yes
checking whether compiler accepts -nostdinc... yes
checking whether compiler accepts -ffreestanding... yes
checking whether compiler accepts -fexcess-precision=standard... yes
checking whether compiler accepts -frounding-math... yes
checking whether compiler accepts -fno-strict-aliasing... yes
checking whether compiler needs attribute((may_alias)) suppression... no
checking whether compiler accepts -Wa,--noexecstack... yes
checking whether compiler accepts -fno-stack-protector... yes
checking whether compiler accepts -fno-tree-loop-distribute-patterns... yes
checking whether we should preprocess assembly to add debugging information... no
checking for optimization settings... using provided CFLAGS
checking whether compiler accepts -pipe... yes
checking whether compiler accepts -fomit-frame-pointer... yes
checking whether compiler accepts -fno-unwind-tables... yes
checking whether compiler accepts -fno-asynchronous-unwind-tables... yes
checking whether compiler accepts -ffunction-sections... yes
checking whether compiler accepts -fdata-sections... yes
checking whether compiler accepts -Wno-pointer-to-int-cast... yes
checking whether compiler accepts -Werror=implicit-function-declaration... yes
checking whether compiler accepts -Werror=implicit-int... yes
checking whether compiler accepts -Werror=pointer-sign... yes
checking whether compiler accepts -Werror=pointer-arith... yes
checking whether compiler accepts -Werror=int-conversion... yes
checking whether compiler accepts -Werror=incompatible-pointer-types... yes
checking whether compiler accepts -Werror=discarded-qualifiers... yes
checking whether compiler accepts -Werror=discarded-array-qualifiers... yes
checking whether compiler accepts -Waddress... yes
checking whether compiler accepts -Warray-bounds... yes
checking whether compiler accepts -Wchar-subscripts... yes
checking whether compiler accepts -Wduplicate-decl-specifier... yes
checking whether compiler accepts -Winit-self... yes
checking whether compiler accepts -Wreturn-type... yes
checking whether compiler accepts -Wsequence-point... yes
checking whether compiler accepts -Wstrict-aliasing... yes
checking whether compiler accepts -Wunused-function... yes
checking whether compiler accepts -Wunused-label... yes
checking whether compiler accepts -Wunused-variable... yes
checking preprocessor condition __PIC__... true
checking whether linker accepts -Wl,--sort-section,alignment... yes
checking whether linker accepts -Wl,--sort-common... yes
checking whether linker accepts -Wl,--gc-sections... yes
checking whether linker accepts -Wl,--hash-style=both... yes
checking whether linker accepts -Wl,--no-undefined... yes
checking whether linker accepts -Wl,--exclude-libs=ALL... yes
checking whether linker accepts -Wl,--dynamic-list=./dynamic.list... yes
checking whether linker accepts -lgcc... yes
checking whether linker accepts -lgcc_eh... yes
using compiler runtime libraries: -lgcc -lgcc_eh
checking preprocessor condition __mips_isa_rev >= 6... false
checking preprocessor condition _MIPSEL || __MIPSEL || __MIPSEL__... false
checking preprocessor condition __mips_soft_float... false
checking whether compiler's long double definition matches float.h... no
./configure: error: unsupported long double type
 * ERROR: cross-mipsel-unknown-linux-musl/musl-1.2.4::local failed (configure phase):
 *   (no error message)
 * 
 * Call stack:
 *     ebuild.sh, line 136:  Called src_configure
 *   environment, line 1735:  Called die
 * The specific snippet of code:
 *       ./configure --target=${CTARGET} --prefix="${EPREFIX}${sysroot}/usr" --syslibdir="${EPREFIX}${sysroot}/lib" --disable-gcc-wrapper || die
 * 
 * If you need support, post the output of `emerge --info '=cross-mipsel-unknown-linux-musl/musl-1.2.4::local'`,
 * the complete build log and the output of `emerge -pqv '=cross-mipsel-unknown-linux-musl/musl-1.2.4::local'`.
 * The complete build log is located at '/var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/temp/environment'.
 * Working directory: '/var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work/musl-1.2.4'
 * S: '/var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work/musl-1.2.4'

>>> Failed to emerge cross-mipsel-unknown-linux-musl/musl-1.2.4, Log file:

>>>  '/var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/temp/build.log'
 * Messages for package cross-mipsel-unknown-linux-musl/musl-1.2.4:
 * ERROR: cross-mipsel-unknown-linux-musl/musl-1.2.4::local failed (configure phase):
 *   (no error message)
 * 
 * Call stack:
 *     ebuild.sh, line 136:  Called src_configure
 *   environment, line 1735:  Called die
 * The specific snippet of code:
 *       ./configure --target=${CTARGET} --prefix="${EPREFIX}${sysroot}/usr" --syslibdir="${EPREFIX}${sysroot}/lib" --disable-gcc-wrapper || die
 * 
 * If you need support, post the output of `emerge --info '=cross-mipsel-unknown-linux-musl/musl-1.2.4::local'`,
 * the complete build log and the output of `emerge -pqv '=cross-mipsel-unknown-linux-musl/musl-1.2.4::local'`.
 * The complete build log is located at '/var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/temp/environment'.
 * Working directory: '/var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work/musl-1.2.4'
 * S: '/var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work/musl-1.2.4'

Answer 1 · 2023-08-29T20:33:58.000Z

As said on irc:

22:28 <jvoisin> q66: https://github.com/jvoisin/fortify-headers/issues/21 I'm open to suggestions, because I have no idea what's going on there
22:30 <@q66> the failing command is not included
22:31 <@q66> and i'm not gonna set up gentoo just because that guy hasn't included any details
22:32 <jvoisin> likely emerging some stuff
22:33 <@q66> tell him to include info about what exactly in the configure script failed
22:33 <jvoisin> but yeah, fair point
22:34 <@q66> chances are if we have the failing command and its output it will become obvious

as well as:

22:38 <nsz> jvoisin: "checking for C compiler... gcc" is probably not what you want for 'cross-mipsel-linux-musl' toolchain
22:39 <nsz> "checking preprocessor condition _MIPSEL || __MIPSEL || __MIPSEL__... false" is also wrong

Answer 2 · 2023-08-29T22:09:47.000Z

What part do you want exactly? I'll be back home at the weekend so I can grab you that file then.

Answer 3 · 2023-08-29T22:20:30.000Z

It looks like you're not really cross-compiling, so odds are it's a toolchain issue.

Answer 4 · 2023-08-29T23:07:12.000Z

It looks like you're not really cross-compiling, so odds are it's a toolchain issue.

I'm building the cross toolchain.

Answer 5 · 2023-12-15T23:16:02.000Z

<sam_> i think you should feel free to close that one without some sort of proper steps to reproduce

Throwing @thesamesam under the bus

Answer 6 · 2023-12-15T23:19:07.000Z

I think this probably needs wiring on the Gentoo side to build fortify-headers as a proper cross package within the sysroot and I don't think there's much to do here on this side.