-
Notifications
You must be signed in to change notification settings - Fork 243
Closed
Description
Trying to compile a sample app for a custom ARM target, I get the following linker error:
= note: arm-none-eabi-ld: /home/benschattinger/.src/Ndless/ndless-sdk/toolchain/install/lib/gcc/arm-none-eabi/9.2.0/libgcc.a(_arm_addsubdf3.o): in function `__floatundidf':
/home/benschattinger/.src/Ndless/ndless-sdk/toolchain/build/arm-none-eabi/libgcc/../../../gcc-9.2.0/libgcc/config/arm/ieee754-df.S:541: multiple definition of `__aeabi_ul2d'; /home/benschattinger/Documents/Projects/Calculator/example-nspire/target/sysroot/lib/rustlib/armv5te-nspire-eabi/lib/libcompiler_builtins-d5dfaf2d732197c9.rlib(compiler_builtins-d5dfaf2d732197c9.compiler_builtins.79ijdt9a-cgu.25.rcgu.o):compiler_builtins.79ijdt9a-cgu.25:(.text.__aeabi_ul2d+0x0): first defined here
collect2: error: ld returned 1 exit status
This issue was introduced with rustc 1.44.0-nightly (42abbd887 2020-04-07) (rustup toolchain install nightly-2020-04-08-x86_64-unknown-linux-gnu
). Builds on previous versions succeed. Here's the diff between the two builds.
# This compiler works
❱ rustc +nightly-2020-04-07-x86_64-unknown-linux-gnu --version --verbose
rustc 1.44.0-nightly (6dee5f112 2020-04-06)
binary: rustc
commit-hash: 6dee5f1126dfd5c9314ee5ae9d9eb010e35ef257
commit-date: 2020-04-06
host: x86_64-unknown-linux-gnu
release: 1.44.0-nightly
LLVM version: 9.0
# This one doesn't
❱ rustc +nightly-2020-04-08-x86_64-unknown-linux-gnu --version --verbose
rustc 1.44.0-nightly (42abbd887 2020-04-07)
binary: rustc
commit-hash: 42abbd8878d3b67238f3611b0587c704ba94f39c
commit-date: 2020-04-07
host: x86_64-unknown-linux-gnu
release: 1.44.0-nightly
LLVM version: 9.0
ian-h-chamberlain and fzyzcjy
Activity
bjorn3 commentedon May 6, 2020
This may be caused by rust-lang/rust#70846.
tmiasko commentedon May 10, 2020
This could be addressed by using similar organization of builtins as one in
libgcc, as suggested before. The only challenging aspect of that work is that
partitioning is controlled through modules, which are also used to realize
other technical details in compiler builtins (mostly to generate additional
unique identifiers; that would have to be changed).
Another possibility is to treat it as a regression, reverting the changes to rustc.
The situation with builtins is somewhat unfortunate, since rustc doesn't have
control of over library calls emitted in LLVM lowering, nor is it there a clear
separation between targets that will use libgcc (where compiler-builtins could
be limited to rustc or LLVM extensions) and those that don't.
alexcrichton commentedon May 11, 2020
I originally found it odd that splitting into more object files would cause regressions, but I'm assuming what's happening here is that C code linked after Rust code pulls in intrinsics from libgcc where the object files in libgcc happen to duplicate intrinsics pulled in by Rust originally from compiler-builtins, causing a link error. This presumably didn't happen before because when an object was pulled in from Rust it defined multiple symbols and prevented those from being loaded from libgcc.
I think the best solution for this issue, if any, is to link libcompiler-builtins last in the linker. That way it's only used for leftovers in terms of whatever's remaining as undefined symbols. That way if libgcc defines a duplicate symbol with compiler-builtins it will be preferred. It should be the case that all duplicate symbols have the same ABI and same semantics, I believe.
TheVova commentedon Sep 7, 2020
is there any update on this? im getting the same error for multiple builtins while linking rust libs to C code,
works with nightlies before the mentioned one. rather sad to be stuck with rust 1.44 forever...
is there anything i can do to help?
lights0123 commentedon Sep 7, 2020
@TheVova Test like this if you're not using a custom target and then put it here, or this if you are.
lattice0 commentedon Sep 18, 2020
I'm having a similar problem: https://stackoverflow.com/questions/63950040/multiple-definition-of-aeabi-ul2f-on-android-ndk-libgcc-real-a but since my code is a mix of C++ and Rust I'm not sure what to do.
I don't know much about linking, LLVM, libgcc_real.a, but what I think I understood is that this problem is happening because my Rust code (which is inside
libsmoltcp_cpp_interface_rust.a
), defines__aeabi_ul2f
. Then, somehow, the linker complains about this being defined also inlibgcc_real.a
. I don't know why, since it uses-Wl,--exclude-libs,libgcc_real.a
in the linking process, solibgcc_real.a
shouldn't be called at all. Well, some.a
files that are being linked together withlibsmoltcp_cpp_interface_rust.a
indeed depend on__aeabi_ul2f
, so maybe this is whylibgcc_real.a
is being invoked.ryankurte commentedon Sep 24, 2020
reddit would seem to be down at the moment, any chance you could add your suggestions to this issue?
@alexcrichton thanks for the hint!
compiling arm code linked against libsodium, swapping from
#[link(name = "c", kind = "static")] extern {}
inmain.rs
to"-C", "link-arg=-lc",
as the very last argument in the linker args worked for me. My cursed linker args in full in case they're useful to anyone else:lights0123 commentedon Sep 24, 2020
Copy/pasting from the Reddit thread I linked:
Me
u/VadimVP
cross-images: hack to fix arm-unknown-linux-musleabihf build
ergo-protocol-client
dependency hexresearch/ergvein#968kleisauke commentedon Feb 11, 2022
I think this comment is also relevant here. This would avoid having to specify the slightly dangerous
--allow-multiple-definition
linker flag.bazel: Allow multiple definitions for armeabi android links
14 remaining items