f128 does not link on (aarch64-unknown)-linux-musl targets

[famfo]

I tried to compile the std test on aarch64-unknown-linux-musl. The linking fails with:

Compiling std v0.0.0 (/home/famfo/git/rust/library/std)                                                                                                                                     21:47:31 [53/1369]
error: linking with `clang` failed: exit status: 1
  |                                                                                                                                                                                                              
  = note:  "clang" "/tmp/rustc7qbC7F/symbols.o" "<4 object files omitted>" "-Wl,--as-needed" "-Wl,-Bstatic" "<sysroot>/lib/rustlib/aarch64-unknown-linux-musl/lib/{libtest-*,libgetopts-*,libunicode_width-*,libr
ustc_std_workspace_std-*}.rlib" "-Wl,-Bdynamic" "<sysroot>-std/aarch64-unknown-linux-musl/release/deps/libstd-5fdab16ba41825af.so" "-Wl,-Bstatic" "<sysroot>/lib/rustlib/aarch64-unknown-linux-musl/lib/libcompil
er_builtins-*.rlib" "-Wl,-Bdynamic" "-lgcc_s" "-lc" "-L" "/tmp/rustc7qbC7F/raw-dylibs" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "/usr/lib" "-L" "<sysroot>/lib/rustlib/aarch64-unknown-linux-musl/lib" "-o"
 "<sysroot>-std/aarch64-unknown-linux-musl/release/deps/floats-bfff3ecd2277cff4" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-Wl,-O1" "-nodefaultlibs" "-Wl,-z,origin" "-Wl,-rpath,$ORIGIN/../lib"
  = note: some arguments are omitted. use `--verbose` to show all linker arguments                                                                                                                               
  = note: /usr/lib/gcc/aarch64-alpine-linux-musl/14.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: /home/famfo/git/rust/build/aarch64-unknown-linux-musl/stage1-std/aarch64-unknown-linux-musl/release/deps/fl
oats-bfff3ecd2277cff4.floats.e625f35bc4eb5419-cgu.3.rcgu.o: in function `floats::f128::test_asinh':                                                                                                              
          /home/famfo/git/rust/library/std/src/num/f128.rs:359:(.text._ZN6floats4f12810test_asinh17h66aec9b92f1171ebE+0x28): undefined reference to `hypotf128'                                                  
          /usr/lib/gcc/aarch64-alpine-linux-musl/14.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: /home/famfo/git/rust/library/std/src/num/f128.rs:722:(.text._ZN6floats4f12810test_asinh17h66aec9b92f1171ebE
+0x50): undefined reference to `log1pf128'                                                                                                                                                                       
          /usr/lib/gcc/aarch64-alpine-linux-musl/14.3.0/../../../../aarch64-alpine-linux-musl/bin/ld: /home/famfo/git/rust/library/std/src/num/f128.rs:359:(.text._ZN6floats4f12810test_asinh17h66aec9b92f1171ebE
+0x80): undefined reference to `hypotf128'
[...]

Musl does not have any f128 builtins and I think that it is safe to disable target_has_reliable_f128_math for *-musl targets for now.

Meta

rustc built from 5d22242 (./x.py test) with a few patches from @Gelbpunkt

• std: thread: Return error if setting thread stack size fails #144210
• bootstrap: Move musl-root fallback out of sanity check #144316
• enabling outline-atomics for aarch64-unknown-linux-musl
• disabling crt-static in the bootstrap.toml

[Gelbpunkt]

Some of these comments are a bit... confusing. The symbols referenced here are provided by glibc, but not by musl (and AFAICT they will never be provided by musl because they are a GNU extension? See https://www.openwall.com/lists/musl/2025/02/28/2).

Yet rustc_codegen_llvm says:

compiler-builtins provides all symbols required for core f128 support, so this should work for everything else.

compiler-builtins doesn't provide these symbols. Should it though?

cc @tgross35

[tgross35]

Some of these comments are a bit... confusing. The symbols referenced here are provided by glibc, but not by musl (and AFAICT they will never be provided by musl because they are a GNU extension? See https://www.openwall.com/lists/musl/2025/02/28/2).

FWIW that email isn’t accurate: it used to only be in the IEEE-754 extension and glibc but those functions are part of C23, think I said that later in the thread. LLVM support is a bit lacking though. (And this doesn’t change anything here).

Yet rustc_codegen_llvm says:

compiler-builtins provides all symbols required for core f128 support, so this should work for everything else.

That comment is only referring to the basic arithmetic ops, not libm. That’s the _math config a bit lower.

compiler-builtins doesn't provide these symbols. Should it though?

Eventually it will, I’m just still working on the implementations.

Anyway, the fix needed here is likely just to restrict to only gnu targets here

rust/compiler/rustc_codegen_llvm/src/llvm_util.rs

Line 437 in 246733a

(_, "linux") if target_pointer_width == 64 => true,

. Not too urgent since it’s only used for tests, but this does apply to all musl targets. I’m really surprised this hasn’t come up in the past ~year of gating f128 math tests on aarch64+Linux but not restricting to GNU, even before that rustc cfg existed.

[Gelbpunkt]

I’m really surprised this hasn’t come up in the past ~year of gating f128 math tests on aarch64+Linux but not restricting to GNU

It wasn't possible to run the testsuite on musl until very very recently with my patches. I'm happy that we're catching these now :)

Eventually it will, I’m just still working on the implementations.

Nice, that is good to hear. I'd be happy to help in any way possible.

Anyway, the fix needed here is likely just to restrict to only gnu targets here

Hmm, I've tried that before and that opens up new issues. Disabling f128 for the musl targets results in tests/ui/process/nofile-limit.rs failing to link on aarch64-unknown-linux-musl because of some missing symbols like __netf2 which are feature gated in compiler-builtins on reliable f128 support. Though I'm not really sure why they are emitted in the first place.

EDIT: These symbols are referenced by libc.a and that test is the only one that forces static linkage it seems. Must be related 🤔 I guess we could statically link to libgcc for that test if it provides the symbols

[Gelbpunkt]

Hmmm, linking to libgcc for these won't work, the symbol is hidden:

     6: 0000000000000000   248 FUNC    GLOBAL HIDDEN     1 __netf2

[tgross35]

I’ll take a closer look when I’m back at a computer, but musl targets should have f128 enabled via the target_has_reliable_f128 config. That will mean we build the libgcc symbols like __netf2. Basically any platform where we don’t get a LLVM crash should be in this boat.

The config it shouldn’t have is target_has_reliable_f128_math, which is a superset config that should gate anything that needs the *f128 symbols in libm. This one is split off because it’s the one where we run into linker errors and the LLVM long double problem.

[Gelbpunkt]

Ah, I think I disabled the wrong feature then. That totally makes sense, I'll double-check and rerun the tests.

[Gelbpunkt]

Yup, that makes this test link fine. Great, I'll run the whole suite and PR the necessary changes. Thanks for your help!