Excess object in `staticlib` archive eventually causing link error

[XrXr]

I tried this code:

$ # on aarch64-unknown-linux-gnu
$ rustc --crate-type staticlib -C lto=thin -O /dev/null
$ ar x libnull.a
$ nm *multc3.o

I expected to see this happen:

The nm output shouldn't say U __builtin_copysignq, since that's an x86 intrinsic unavailable on aarch64-unknown-linux-gnu

Instead, this happened:

$ nm *multc3.o
                 U __addtf3
                 U __builtin_copysignq
                 U __floatsitf
                 U __letf2
0000000000000000 T __multc3
                 U __multf3
                 U __subtf3
                 U __unordtf2

Over in Ruby, because we consume the static archive by partial linking it into an .o file first, we've been getting reports of link errors due to this unused object in the archive:

partial linking yjit/target/release/libyjit.a into yjit/target/release/libyjit.o
linking miniruby
/usr/bin/ld: yjit/target/release/libyjit.o: in function `__multc3':
/cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.108/./lib/builtins/multc3.c:33:(.text.__multc3+0x30c): undefined reference to `__builtin_copysignq'
/usr/bin/ld: /cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.108/./lib/builtins/multc3.c:34:(.text.__multc3+0x394): undefined reference to `__builtin_copysignq'
/usr/bin/ld: /cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.108/./lib/builtins/multc3.c:42:(.text.__multc3+0x7f4): undefined reference to `__builtin_copysignq'
/usr/bin/ld: /cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.108/./lib/builtins/multc3.c:43:(.text.__multc3+0x864): undefined reference to `__builtin_copysignq'
/usr/bin/ld: /cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.108/./lib/builtins/multc3.c:47:(.text.__multc3+0x8c4): undefined reference to `__builtin_copysignq'
/usr/bin/ld: yjit/target/release/libyjit.o:/cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.108/./lib/builtins/multc3.c:38: more undefined references to `__builtin_copysignq' follow
collect2: error: ld returned 1 exit status

It looks like this particular intrinsic comes from a file that isn't included for ARM Windows targets:

https://github.com/rust-lang/compiler-builtins/blob/c04eb9e1afb72bdf943f5e5d77b3812f40526602/build.rs#L537-L539

so in fact it should be completely unused. In the README for compiler-builtins, the file is listed under "Unimplemented" and seemingly with no plan for usage:

These builtins involve floating-point types ("f80" and complex numbers) that are not supported by Rust.

I'm wondering if rust could stop including this object in the archive.

Meta

This is regression that started in 1.78.0. With 1.77.0 the nm output is:

$ nm *multc3.o
                 U __addtf3
                 U __floatsitf
                 U __letf2
0000000000000000 T __multc3
                 U __multf3
                 U __subtf3
                 U __unordtf2

and it works fine for ruby.

Issue exists in latest nightly.

rustc --version --verbose:

rustc 1.80.0-nightly (bdbbb6c6a 2024-05-26)
binary: rustc
commit-hash: bdbbb6c6a718d4d196131aa16bafb60e850311d9
commit-date: 2024-05-26
host: aarch64-unknown-linux-gnu
release: 1.80.0-nightly
LLVM version: 18.1.6

[XrXr]

@rustbot modify labels: +regression-from-stable-to-stable +A-linkage

[XrXr]

I was able to test rust-lang/compiler-builtins#623 on a local rust build using [patch.crates-io] and confirm that it solves the link error for ruby. So I'm now more confident to offer it as a potential solution. I'm not sure about the policy around bumping the compiler-builtins dependency, though.

Also, the change removes one object file from staticlib outputs, so it gives a small file size benefit even if people are not hitting the link error. 😛