Multiple definitions of __sync_fetch_and_add_4 et al.
#420
Comments
|
The solution is the same as #412: each intrinsic needs to be defined in its own |
|
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. |
|
Hi @Amanieu, I'm encountering the same issue on the nightly (today's version) for armv5te-unknown-linux-musleabi. /opt/arm-buildroot-linux-musleabi_sdk-buildroot/bin/../lib/gcc/arm-buildroot-linux-musleabi/11.2.0/../../../../arm-buildroot-linux-musleabi/bin/ld: /opt/arm-buildroot-linux-musleabi_sdk-buildroot/bin/../lib/gcc/arm-buildroot-linux-musleabi/11.2.0/libgcc.a(linux-atomic.o): in function Is there anything I can do? |
There are duplicated symbols between rustc and gcc. Specifying --allow-multiple-definition to the linker as workaround until rustc is fixed. rust-lang issue: rust-lang/compiler-builtins#420 Fixes: http://autobuild.buildroot.net/results/53f/53f5598b8e520caaa135fb4923c09da382dab329 Signed-off-by: Moritz Bitsch <[email protected]> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <[email protected]>
|
@Amanieu Hitting this issue on x86_64-apple-ios and moving to Rust 1.60.0 (which I believe includes the proposed fix) does not seem to fix it. What is the general advice here? Should we weaken the compiler_builtins symbols in favor of the libclang_rt ones? Are these symbols considered compatible enough that Rust code depending on the compiler builtin ones can safely use the clang ones instead? |
We should already put all compiler_builtins symbols in separate object files and the linker should only pull in object files from archives if at least one symbol in them is referenced. Together this should mean that only either the object file providing this from compiler_builtins or libclang_rt should be pulled in and not both. I'm not sure where it goes wrong though that would cause this issue. If I locally try to list which object files in libcompiler_builtins.rlib provide which symbols it looks like
Yes, in fact they should be identical between clang and gcc even. |
The issue in this case is the link is using |
I see. compiler_builtins indeed needs to be linked without
Support for weak symbols is rather spotty across platforms I believe and the exact behavior differs between platforms. |
|
Ideally that would be possible but practically in the build system it would be difficult to add that for every single one of the transitive libraries, which is why we take the
Ah yea fair enough. Do you see any other downsides to doing weak symbols as well as the current solution? That would satisfy this use case for macho at least (although maybe it only apply to the one format is enough to not do it to not cause confusion) |
Not sure. |
|
facing this issue too, when building fd-find (https://github.com/sharkdp/fd/) version 8.4.0 for |
The file is Linux on ARM is a pretty limited scope, and there are other widespread usages like glibc used to provide weak versions of pthread symbols in libc.so for decades (that changed recently for unrelated reasons when libpthread was merged into libc). |
|
I'm using Rust 1.65.0, and this issue still seems to be present (target = armv5te-unknown-linux-gnueabi): |
|
With the following change in my config, the build finished without errors (based on woodsts/buildroot@f439f7c) :
[target.armv5te-unknown-linux-gnueabi]
linker = "arm-linux-gnueabi-gcc"
# Workaround for: https://github.com/rust-lang/compiler-builtins/issues/420
rustflags = ["-C", "link-arg=-Wl,--allow-multiple-definition"] |
Similar to #412, on
armv7-unknown-linux-gnueabihfwe get symbols__sync_fetch_and_add_4and__sync_fetch_and_add_8(and probably others) clashing when a C/C++ tries to link with our library. We've tried onarm-unknown-linux-gnueabihf,aarch64-unknown-linux-gnuandx86_64-unknown-linux-gnuand it doesn't seem to generate these symbols.On Zulip, Alex Crichton suggested to flag the symbol as weak. This issue is off my level of competence, so I'll probably leave it to someone who knows better than me.
Some links that I've found while investigating this (for cross-reference):
The text was updated successfully, but these errors were encountered: