multiple definition of __aeabi_ul2d

[lights0123]

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

[bjorn3]

This may be caused by rust-lang/rust#70846.

[tmiasko]

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]

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]

is there any update on this? im getting the same error for multiple builtins while linking rust libs to C code,

 /home/vlad/arm-gcc/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld: /home/vlad/arm-gcc/bin/../lib/gcc/arm-none-eabi/9.3.1/thumb/v7e-m+fp/hard/libgcc.a(_arm_addsubdf3.o): in function `__extendsfdf2':
 (.text+0x2c8): multiple definition of `__aeabi_f2d'; _install/lib/c55/libember.a(compiler_builtins-deca8aa381edbbfe.compiler_builtins.677rlml8-cgu.180.rcgu.o):/rustc/73dc675b9437c2a51a975a9f58cc66f05463c351/library/core/src/ops/bit.rs:137: first defined here
 /home/vlad/arm-gcc/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld: /home/vlad/arm-gcc/bin/../lib/gcc/arm-none-eabi/9.3.1/thumb/v7e-m+fp/hard/libgcc.a(_arm_addsubsf3.o): in function `__floatundisf':
 (.text+0x190): multiple definition of `__aeabi_ul2f'; _install/lib/c55/libconfigpb_rs.a(compiler_builtins-deca8aa381edbbfe.compiler_builtins.677rlml8-cgu.105.rcgu.o):/cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.35/src/macros.rs:225: first defined here
 collect2: error: ld returned 1 exit status

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]

@TheVova Test like this if you're not using a custom target and then put it here, or this if you are.

[lattice0]

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 in libgcc_real.a. I don't know why, since it uses -Wl,--exclude-libs,libgcc_real.a in the linking process, so libgcc_real.a shouldn't be called at all. Well, some .a files that are being linked together with libsmoltcp_cpp_interface_rust.a indeed depend on __aeabi_ul2f, so maybe this is why libgcc_real.a is being invoked.

[ryankurte]

@TheVova Test like this if you're not using a custom target and then put it here, or this if you are.

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 {} in main.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:

[target.thumbv7em-none-eabihf]

rustflags = [
   "-C", "linker=arm-none-eabi-gcc",
   "-C", "link-arg=-Wl,-Tlink.x",
   "-C", "link-arg=-nostartfiles",
   "-C", "link-arg=-L/usr/lib/arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/",
#   "-C", "link-arg=--specs=nosys.specs",
#   "-C", "link-arg=--specs=nano.specs",
   "-C", "link-arg=-lc",
#   "-C", "link-arg=-lnosys",
]

[lights0123]

Copy/pasting from the Reddit thread I linked:

Me

Thanks so much—RUSTFLAGS="-Clink-arg=-Wl,--allow-multiple-definition" works! Is there any problem with leaving that there all the time (I'd integrate it into the target.json)? Which definition would it pick to include?

u/VadimVP

Which definition would it pick to include?

Whichever was encountered first during linking.
Definitions in libgcc and compiler-builtins are supposed to be interchangeable, so in this particular case it should be ok.

Is there any problem with leaving that there all the time (I'd integrate it into the target.json)?

--allow-multiple-definition is not enabled by default because it usually catches legitimate errors.

I'd recommend to check whether the problem reproduces on the latest nightly. compiler-builtins recently had a change that was supposed to fix linking errors like this.

[kleisauke]

Hopefully this should be fixed by #452 which will be included in rust-lang/rust#93696. Please try it in the next nightly once that is merged.
Originally posted by @Amanieu in #412 (comment)

I think this comment is also relevant here. This would avoid having to specify the slightly dangerous --allow-multiple-definition linker flag.