Excess object in `staticlib` archive eventually causing link error #125619

XrXr · 2024-05-27T15:12:06Z

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

The text was updated successfully, but these errors were encountered:

XrXr · 2024-05-27T15:39:30Z

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

This C file doesn't seem to be compiled correctly, as it creates a reference to the x86 specific `__builtin_copysignq` on ARM. This intrinsic is unused and unavailable on Windows because it's for complex numbers Rust doesn't support, so it should be fine to remove. The inclusion of the file seems to be the cause of some downstream link errors: rust-lang/rust#125619

XrXr · 2024-05-28T21:45:42Z

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. 😛

To prevent fail-fast in situations like rust-lang/rust#125619, where an upstream source compiles but creates a link error way downstream.

I'm proposing this GCC upgrade since it addresses bug rust-lang#125619. The regression in question affects stable release consumers who tend to have no experience dealing with Rust build tools, so if at all possible, I would like to have it resolved in the next stable release. I have tried to fix the bug in `compiler-builtins`, which led to submitting a PR for `compiler-rt` in upstream LLVM, but it may take a long time before these upstreams address this regression. A summary of why upgrading GCC solves the regression follows. `__multc3()` is a builtin function `compiler-builtins` exposes for specifically aarch64, non-Windows targets [1]. The object file for it is included in `staticlib` archives through `libstd`. The implementation for `__multc3()` is from `multc3.c`, part of LLVM's `compiler-rt`. Upstream `compiler-rt` normally builds the C file using the Clang that's from the same LLVM version. On the other hand, `compiler-builtins` builds the C file using GCC, outside of the usual LLVM build system. The upstream implementation doesn't have feature detection which works for GCC version older than 10, and ends up producing an unlinkable object. Upstream LLVM might be slow to respond to this issue as they might deem `compiler-builtin` as doing something out of the ordinary from their perspective. They might reasonably assume everyone to build `compiler-rt` using LLVM's build system. I have done the following to test this change: - verified that a local build without this patch exhibits the regression. - verified that with this patch, the object for `__multc3()` has no reference to undefined functions in the symbol table. - verified that with this patch, `rustc` is usable to build Ruby with YJIT, and that the reported regression is resolved. [1]: https://github.com/rust-lang/compiler-builtins/blob/c04eb9e1afb72bdf943f5e5d77b3812f40526602/build.rs#L524-L539

I'm proposing this GCC upgrade since it addresses bug rust-lang#125619. The regression in question affects stable release consumers who tend to have no experience dealing with Rust build tools, so if at all possible, I would like to have it resolved in the next stable release. I have tried to fix the bug in `compiler-builtins`, which led to submitting a PR for `compiler-rt` in upstream LLVM, but it may take a long time before these upstreams address this regression. A summary of why upgrading GCC solves the regression follows. `__multc3()` is a builtin function `compiler-builtins` exposes for specifically aarch64, non-Windows targets [1]. The object file for it is included in `staticlib` archives through `libstd`. The implementation for `__multc3()` is from `multc3.c`, part of LLVM's `compiler-rt`. Upstream `compiler-rt` normally builds the C file using the Clang from the same LLVM version. On the other hand, `compiler-builtins` builds the C file using GCC, outside of the usual LLVM build system. The upstream implementation doesn't have feature detection which works for GCC version older than 10, and ends up producing an unlinkable object. Upstream LLVM might be slow to respond to this issue as they might deem `compiler-builtin` as doing something out of the ordinary from their perspective. They might reasonably assume everyone to build `compiler-rt` using LLVM's build system. I have done the following to test this change: - verified that a local build without this patch exhibits the regression. - verified that with this patch, the object for `__multc3()` has no reference to undefined functions in the symbol table. - verified that with this patch, `rustc` is usable to build Ruby with YJIT, and that the reported regression is resolved. [1]: https://github.com/rust-lang/compiler-builtins/blob/c04eb9e1afb72bdf943f5e5d77b3812f40526602/build.rs#L524-L539

I'm proposing this GCC upgrade since it addresses bug rust-lang#125619. The regression in question affects stable release consumers who tend to have no experience dealing with Rust build tools, so if at all possible, I would like to have it resolved in the next stable release. I have tried to fix the bug in `compiler-builtins`, which led to submitting a PR for `compiler-rt` in upstream LLVM, but it may take a long time before these upstreams to address this regression. A summary of why upgrading GCC solves the regression follows. `__multc3()` is a builtin function `compiler-builtins` exposes for specifically aarch64, non-Windows targets [1]. The object file for it is included in `staticlib` archives through `libstd`. The implementation for `__multc3()` is from `multc3.c`, part of LLVM's `compiler-rt`. Upstream `compiler-rt` normally builds the C file using the Clang from the same LLVM version. On the other hand, `compiler-builtins` builds the C file using GCC, outside of the usual LLVM build system. The upstream implementation doesn't have feature detection which works for GCC version older than 10, and ends up producing an unlinkable object. Upstream LLVM might be slow to respond to this issue as they might deem `compiler-builtin` as doing something out of the ordinary from their perspective. They might reasonably assume everyone to build `compiler-rt` using LLVM's build system. I have done the following to test this change: - verified that a local build without this patch exhibits the regression. - verified that with this patch, the object for `__multc3()` has no reference to undefined functions in the symbol table. - verified that with this patch, `rustc` is usable to build Ruby with YJIT, and that the reported regression is resolved. [1]: https://github.com/rust-lang/compiler-builtins/blob/c04eb9e1afb72bdf943f5e5d77b3812f40526602/build.rs#L524-L539

I'm proposing this GCC upgrade since it addresses bug rust-lang#125619. The regression in question affects stable release consumers who tend to have no exposure to Rust build tools, so if at all possible, I would like to have it resolved in the next stable release. I have tried to fix the bug in `compiler-builtins`, which led to submitting a PR for `compiler-rt` in upstream LLVM, but it may take a long time before these upstreams to address this regression. A summary of why upgrading GCC solves the regression follows. `__multc3()` is a builtin function `compiler-builtins` exposes for specifically aarch64, non-Windows targets [1]. The object file for it is included in `staticlib` archives through `libstd`. The implementation for `__multc3()` is from `multc3.c`, part of LLVM's `compiler-rt`. Upstream `compiler-rt` normally builds the C file using the Clang from the same LLVM version. On the other hand, `compiler-builtins` builds the C file using GCC, outside of the usual LLVM build system. The upstream implementation doesn't have feature detection which works for GCC version older than 10, and ends up producing an unlinkable object. Upstream LLVM might be slow to respond to this issue as they might deem `compiler-builtin` as doing something out of the ordinary from their perspective. They might reasonably assume everyone to build `compiler-rt` using LLVM's build system. I have done the following to test this change: - verified that a local build without this patch exhibits the regression. - verified that with this patch, the object for `__multc3()` has no reference to undefined functions in the symbol table. - verified that with this patch, `rustc` is usable to build Ruby with YJIT, and that the reported regression is resolved. [1]: https://github.com/rust-lang/compiler-builtins/blob/c04eb9e1afb72bdf943f5e5d77b3812f40526602/build.rs#L524-L539

I'm proposing this GCC upgrade since it addresses bug rust-lang#125619. The regression in question affects stable release consumers who tend to have no exposure to Rust build tools, so if at all possible, I would like to have it resolved in the next stable release. I have tried to fix the bug in `compiler-builtins`, which led to submitting a PR for `compiler-rt` in upstream LLVM, but it may take a long time before these upstreams address this regression. A summary of why upgrading GCC solves the regression follows. `__multc3()` is a builtin function `compiler-builtins` exposes for specifically aarch64, non-Windows targets [1]. The object file for it is included in `staticlib` archives through `libstd`. The implementation for `__multc3()` is from `multc3.c`, part of LLVM's `compiler-rt`. Upstream `compiler-rt` normally builds the C file using the Clang from the same LLVM version. On the other hand, `compiler-builtins` builds the C file using GCC, outside of the usual LLVM build system. The upstream implementation doesn't have feature detection which works for GCC version older than 10, and ends up producing an unlinkable object. Upstream LLVM might be slow to respond to this issue as they might deem `compiler-builtin` as doing something out of the ordinary from their perspective. They might reasonably assume everyone to build `compiler-rt` using LLVM's build system. I have done the following to test this change: - verified that a local build without this patch exhibits the regression. - verified that with this patch, the object for `__multc3()` has no reference to undefined functions in the symbol table. - verified that with this patch, `rustc` is usable to build Ruby with YJIT, and that the reported regression is resolved. [1]: https://github.com/rust-lang/compiler-builtins/blob/c04eb9e1afb72bdf943f5e5d77b3812f40526602/build.rs#L524-L539

I'm proposing this GCC upgrade since it addresses bug rust-lang#125619. The regression in question affects stable release consumers who tend to have no exposure to Rust build tools, so if at all possible, I would like to have it resolved in the next stable release. I have tried to fix the bug in `compiler-builtins`, which led to submitting a PR for `compiler-rt` in upstream LLVM, but it may take a long time before these upstreams address this regression. A summary of why upgrading GCC solves the regression follows. `__multc3()` is a builtin function `compiler-builtins` exposes for specifically aarch64, non-Windows targets [1]. The object file for it is included in `staticlib` archives through `libstd`. The implementation for `__multc3()` is from `multc3.c`, part of LLVM's `compiler-rt`. Upstream `compiler-rt` normally builds the C file using the Clang from the same LLVM version. On the other hand, `compiler-builtins` builds the C file using GCC, outside of the usual LLVM build system. The upstream implementation doesn't have feature detection which works for GCC version older than 10, and ends up producing an unlinkable object. Upstream LLVM might be slow to respond to this issue as they might deem `compiler-builtin` as doing something out of the ordinary from their perspective. They might reasonably assume everyone builds `compiler-rt` through LLVM's build system. I have done the following to test this change: - verified that a local build without this patch exhibits the regression. - verified that with this patch, the object for `__multc3()` has no reference to undefined functions in the symbol table. - verified that with this patch, `rustc` is usable to build Ruby with YJIT, and that the reported regression is resolved. [1]: https://github.com/rust-lang/compiler-builtins/blob/c04eb9e1afb72bdf943f5e5d77b3812f40526602/build.rs#L524-L539

ci: use GCC 13 as cross compiler in `dist-aarch64-linux` I'm proposing this GCC upgrade since it addresses bug rust-lang#125619. The regression in question affects stable release consumers who tend to have no exposure to Rust build tools, so if at all possible, I would like to have it resolved in the next stable release. I have tried to fix the bug in `compiler-builtins`, which led to submitting a PR for `compiler-rt` in upstream LLVM, but it may take a long time before these upstreams address this regression. A summary of why upgrading GCC solves the regression follows. `__multc3()` is a builtin function `compiler-builtins` exposes for specifically aarch64, non-Windows targets [1]. The object file for it is included in `staticlib` archives through `libstd`. The implementation for `__multc3()` is from `multc3.c`, part of LLVM's `compiler-rt`. Upstream `compiler-rt` normally builds the C file using the Clang from the same LLVM version. On the other hand, `compiler-builtins` builds the C file using GCC, outside of the usual LLVM build system. The upstream implementation doesn't have feature detection which works for GCC version older than 10, and ends up producing an unlinkable object. Upstream LLVM might be slow to respond to this issue as they might deem `compiler-builtin` as doing something out of the ordinary from their perspective. They might reasonably assume everyone builds `compiler-rt` through LLVM's build system. I have done the following to test this change: - verified that a local build without this patch exhibits the regression. - verified that with this patch, the object for `__multc3()` has no reference to undefined functions in the symbol table. - verified that with this patch, `rustc` is usable to build Ruby with YJIT, and that the reported regression is resolved. Since `loongarch64-linux-gnu` already uses GCC 13.2.0, I hope we can upgrade without issues. try-job: dist-aarch64-linux [1]: https://github.com/rust-lang/compiler-builtins/blob/c04eb9e1afb72bdf943f5e5d77b3812f40526602/build.rs#L524-L539

ci: use GCC 13 as cross compiler in `dist-aarch64-linux` I'm proposing this GCC upgrade since it addresses bug rust-lang/rust#125619. The regression in question affects stable release consumers who tend to have no exposure to Rust build tools, so if at all possible, I would like to have it resolved in the next stable release. I have tried to fix the bug in `compiler-builtins`, which led to submitting a PR for `compiler-rt` in upstream LLVM, but it may take a long time before these upstreams address this regression. A summary of why upgrading GCC solves the regression follows. `__multc3()` is a builtin function `compiler-builtins` exposes for specifically aarch64, non-Windows targets [1]. The object file for it is included in `staticlib` archives through `libstd`. The implementation for `__multc3()` is from `multc3.c`, part of LLVM's `compiler-rt`. Upstream `compiler-rt` normally builds the C file using the Clang from the same LLVM version. On the other hand, `compiler-builtins` builds the C file using GCC, outside of the usual LLVM build system. The upstream implementation doesn't have feature detection which works for GCC version older than 10, and ends up producing an unlinkable object. Upstream LLVM might be slow to respond to this issue as they might deem `compiler-builtin` as doing something out of the ordinary from their perspective. They might reasonably assume everyone builds `compiler-rt` through LLVM's build system. I have done the following to test this change: - verified that a local build without this patch exhibits the regression. - verified that with this patch, the object for `__multc3()` has no reference to undefined functions in the symbol table. - verified that with this patch, `rustc` is usable to build Ruby with YJIT, and that the reported regression is resolved. Since `loongarch64-linux-gnu` already uses GCC 13.2.0, I hope we can upgrade without issues. try-job: dist-aarch64-linux [1]: https://github.com/rust-lang/compiler-builtins/blob/c04eb9e1afb72bdf943f5e5d77b3812f40526602/build.rs#L524-L539

I'm proposing this GCC upgrade since it addresses bug rust-lang#125619. The regression in question affects stable release consumers who tend to have no exposure to Rust build tools, so if at all possible, I would like to have it resolved in the next stable release. I have tried to fix the bug in `compiler-builtins`, which led to submitting a PR for `compiler-rt` in upstream LLVM, but it may take a long time before these upstreams address this regression. A summary of why upgrading GCC solves the regression follows. `__multc3()` is a builtin function `compiler-builtins` exposes for specifically aarch64, non-Windows targets [1]. The object file for it is included in `staticlib` archives through `libstd`. The implementation for `__multc3()` is from `multc3.c`, part of LLVM's `compiler-rt`. Upstream `compiler-rt` normally builds the C file using the Clang from the same LLVM version. On the other hand, `compiler-builtins` builds the C file using GCC, outside of the usual LLVM build system. The upstream implementation doesn't have feature detection which works for GCC version older than 10, and ends up producing an unlinkable object. Upstream LLVM might be slow to respond to this issue as they might deem `compiler-builtin` as doing something out of the ordinary from their perspective. They might reasonably assume everyone builds `compiler-rt` through LLVM's build system. I have done the following to test this change: - verified that a local build without this patch exhibits the regression. - verified that with this patch, the object for `__multc3()` has no reference to undefined functions in the symbol table. - verified that with this patch, `rustc` is usable to build Ruby with YJIT, and that the reported regression is resolved. [1]: https://github.com/rust-lang/compiler-builtins/blob/c04eb9e1afb72bdf943f5e5d77b3812f40526602/build.rs#L524-L539

ci: use GCC 13 as cross compiler in `dist-aarch64-linux` I'm proposing this GCC upgrade since it addresses bug rust-lang/rust#125619. The regression in question affects stable release consumers who tend to have no exposure to Rust build tools, so if at all possible, I would like to have it resolved in the next stable release. I have tried to fix the bug in `compiler-builtins`, which led to submitting a PR for `compiler-rt` in upstream LLVM, but it may take a long time before these upstreams address this regression. A summary of why upgrading GCC solves the regression follows. `__multc3()` is a builtin function `compiler-builtins` exposes for specifically aarch64, non-Windows targets [1]. The object file for it is included in `staticlib` archives through `libstd`. The implementation for `__multc3()` is from `multc3.c`, part of LLVM's `compiler-rt`. Upstream `compiler-rt` normally builds the C file using the Clang from the same LLVM version. On the other hand, `compiler-builtins` builds the C file using GCC, outside of the usual LLVM build system. The upstream implementation doesn't have feature detection which works for GCC version older than 10, and ends up producing an unlinkable object. Upstream LLVM might be slow to respond to this issue as they might deem `compiler-builtin` as doing something out of the ordinary from their perspective. They might reasonably assume everyone builds `compiler-rt` through LLVM's build system. I have done the following to test this change: - verified that a local build without this patch exhibits the regression. - verified that with this patch, the object for `__multc3()` has no reference to undefined functions in the symbol table. - verified that with this patch, `rustc` is usable to build Ruby with YJIT, and that the reported regression is resolved. Since `loongarch64-linux-gnu` already uses GCC 13.2.0, I hope we can upgrade without issues. try-job: dist-aarch64-linux [1]: https://github.com/rust-lang/compiler-builtins/blob/c04eb9e1afb72bdf943f5e5d77b3812f40526602/build.rs#L524-L539

Previously, building `multc3.c` on A64 with GCC 7 or up but 9 and lower will attempt to reference `__builtin_copysignq`, an [x86-specific intrinsic][1]: ``` $ gcc -c multc3.c In file included from fp_lib.h:24, from multc3.c:14: multc3.c: In function '__multc3': int_math.h:71:32: warning: implicit declaration of function '__builtin_copysignq'; did you mean '__builtin_copysign'? [-Wimplicit-function-declaration] #define crt_copysignf128(x, y) __builtin_copysignq((x), (y)) ^~~~~~~~~~~~~~~~~~~ ``` This is because `__has_builtin` is from GCC 10, and defined to 0 at the top of int_math.h for affected GCC versions, so the fallback definition is used. But `__builtin_copysignq` is unavailable on A64. Use version detection to find `__builtin_copysignf128` instead. It's available since GCC 7 and [available][2] on both x86 and A64, given this macro is only used when `CRT_HAS_IEEE_TF`. --- I realize this is fixing a problem for an out-of-tree build configuration, but help would be greatly appreciated. Rust [builds](https://github.com/rust-lang/compiler-builtins) `multc3.c` with GCC 8 and this mis-selection is causing [build issues](rust-lang/rust#125619) way downstream. ref: d2ce3e9 [1]: https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html [2]: https://gcc.gnu.org/gcc-7/changes.html

To prevent fail-fast in situations like rust-lang/rust#125619, where an upstream source compiles but creates a link error way downstream.

Rust 1.78 and above are subjected to a [bug] leading Arm64 foreign archives to contain x86 builtins. It looks like we are now triggering this very bug, which prevents building on Arm64 hardware. The simplest way to move forward is to downgrade our recommended version of Rust to 1.77, and wait for a release containing the [fix] to be merged. [bug]: rust-lang/rust#125619 [fix]: rust-lang/rust#131221 Co-authored-by: Ole Krüger <[email protected]>

Previously, building `multc3.c` on A64 with GCC 7 or up but 9 and lower will attempt to reference `__builtin_copysignq`, an [x86-specific intrinsic][1]: ``` $ gcc -c multc3.c In file included from fp_lib.h:24, from multc3.c:14: multc3.c: In function '__multc3': int_math.h:71:32: warning: implicit declaration of function '__builtin_copysignq'; did you mean '__builtin_copysign'? [-Wimplicit-function-declaration] #define crt_copysignf128(x, y) __builtin_copysignq((x), (y)) ^~~~~~~~~~~~~~~~~~~ ``` This is because `__has_builtin` is from GCC 10, and defined to 0 at the top of int_math.h for affected GCC versions, so the fallback definition is used. But `__builtin_copysignq` is unavailable on A64. Use version detection to find `__builtin_copysignf128` instead. It's available since GCC 7 and [available][2] on both x86 and A64, given this macro is only used when `CRT_HAS_IEEE_TF`. --- I realize this is fixing a problem for an out-of-tree build configuration, but help would be greatly appreciated. Rust [builds](https://github.com/rust-lang/compiler-builtins) `multc3.c` with GCC 8 and this mis-selection is causing [build issues](rust-lang/rust#125619) way downstream. ref: d2ce3e9 [1]: https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html [2]: https://gcc.gnu.org/gcc-7/changes.html (cherry picked from commit 8aa9d62)

jieyouxu · 2024-11-08T09:42:43Z

Triage: @XrXr is this issue still a problem?

XrXr · 2024-11-08T14:46:08Z

Yes. Specifically it still happens on aarch64-unknown-linux-musl. LLVM fix is going through the backport process: llvm/llvm-project#115006

Previously, building `multc3.c` on A64 with GCC 7 or up but 9 and lower will attempt to reference `__builtin_copysignq`, an [x86-specific intrinsic][1]: ``` $ gcc -c multc3.c In file included from fp_lib.h:24, from multc3.c:14: multc3.c: In function '__multc3': int_math.h:71:32: warning: implicit declaration of function '__builtin_copysignq'; did you mean '__builtin_copysign'? [-Wimplicit-function-declaration] #define crt_copysignf128(x, y) __builtin_copysignq((x), (y)) ^~~~~~~~~~~~~~~~~~~ ``` This is because `__has_builtin` is from GCC 10, and defined to 0 at the top of int_math.h for affected GCC versions, so the fallback definition is used. But `__builtin_copysignq` is unavailable on A64. Use version detection to find `__builtin_copysignf128` instead. It's available since GCC 7 and [available][2] on both x86 and A64, given this macro is only used when `CRT_HAS_IEEE_TF`. --- I realize this is fixing a problem for an out-of-tree build configuration, but help would be greatly appreciated. Rust [builds](https://github.com/rust-lang/compiler-builtins) `multc3.c` with GCC 8 and this mis-selection is causing [build issues](rust-lang/rust#125619) way downstream. ref: d2ce3e9 [1]: https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html [2]: https://gcc.gnu.org/gcc-7/changes.html (cherry picked from commit 8aa9d62)

Update LLVM to 19.1.4 Fixes rust-lang/rust#125619 r? `@DianQK`

zaq7434 · 2024-11-30T06:17:59Z

How to avoid this problem with rust 1.79 ?Must I upgrade the rust version or llvm?
aarch64-unknown-linux-gnu

Yes. Specifically it still happens on aarch64-unknown-linux-musl. LLVM fix is going through the backport process: llvm/llvm-project#115006

bjorn3 · 2024-11-30T06:51:44Z

Looks like the fix will be in Rust 1.84.

XrXr added the C-bug Category: This is a bug. label May 27, 2024

rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label May 27, 2024

rustbot added A-linkage Area: linking into static, shared libraries and binaries regression-from-stable-to-stable Performance or correctness regression from one stable version to another. I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels May 27, 2024

XrXr mentioned this issue May 27, 2024

Remove __multc3 rust-lang/compiler-builtins#623

Closed

andrewn617 mentioned this issue May 28, 2024

Is the dependency to the Rust devcontainer feature needed? rails/devcontainer#32

Closed

XrXr added a commit to XrXr/compiler-builtins that referenced this issue May 30, 2024

Build with -Werror=implicit-function-declaration

97c266e

To prevent fail-fast in situations like rust-lang/rust#125619, where an upstream source compiles but creates a link error way downstream.

This was referenced May 30, 2024

Build with -Werror=implicit-function-declaration rust-lang/compiler-builtins#627

Merged

[compiler-rt] Stop using x86 builtin on AArch64 with GCC llvm/llvm-project#93890

Merged

jieyouxu added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Jun 4, 2024

XrXr mentioned this issue Jun 4, 2024

ci: use GCC 13 as cross compiler in dist-aarch64-linux #125999

Merged

XrXr added a commit to XrXr/compiler-builtins that referenced this issue Oct 2, 2024

Build with -Werror=implicit-function-declaration

3912be0

To prevent fail-fast in situations like rust-lang/rust#125619, where an upstream source compiles but creates a link error way downstream.

tgross35 pushed a commit to XrXr/compiler-builtins that referenced this issue Oct 3, 2024

Build with -Werror=implicit-function-declaration

64282a7

To prevent fail-fast in situations like rust-lang/rust#125619, where an upstream source compiles but creates a link error way downstream.

XrXr mentioned this issue Oct 10, 2024

YJIT: Improve build instructions for non-hackers ruby/ruby#11878

Merged

apiraino removed the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Nov 12, 2024

Earlopain mentioned this issue Nov 20, 2024

Update LLVM to 19.1.4 rust-lang/llvm-project#179

Merged

DianQK added the llvm-fixed-upstream Issue expected to be fixed by the next major LLVM upgrade, or backported fixes label Nov 20, 2024

Earlopain mentioned this issue Nov 20, 2024

Update LLVM to 19.1.4 #133254

Merged

bors closed this as completed in 318f96a Nov 21, 2024

github-actions bot pushed a commit to rust-lang/miri that referenced this issue Nov 22, 2024

Auto merge of #133254 - Earlopain:llvm-19.1.4, r=DianQK

c9fe894

Update LLVM to 19.1.4 Fixes rust-lang/rust#125619 r? `@DianQK`

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Excess object in `staticlib` archive eventually causing link error #125619

Excess object in `staticlib` archive eventually causing link error #125619

XrXr commented May 27, 2024

XrXr commented May 27, 2024

XrXr commented May 28, 2024 •

edited

Loading

jieyouxu commented Nov 8, 2024

XrXr commented Nov 8, 2024

zaq7434 commented Nov 30, 2024

bjorn3 commented Nov 30, 2024

Excess object in staticlib archive eventually causing link error #125619

Excess object in staticlib archive eventually causing link error #125619

Comments

XrXr commented May 27, 2024

Meta

XrXr commented May 27, 2024

XrXr commented May 28, 2024 • edited Loading

jieyouxu commented Nov 8, 2024

XrXr commented Nov 8, 2024

zaq7434 commented Nov 30, 2024

bjorn3 commented Nov 30, 2024

Excess object in `staticlib` archive eventually causing link error #125619

Excess object in `staticlib` archive eventually causing link error #125619

XrXr commented May 28, 2024 •

edited

Loading