multiple definition of `__udivti3' in libgcc and Rust system library

1.1k Views Asked by At

I am trying to link some executable (which compiled with gcc) with the library that is compiled with cargo build.

cargo generates both .a and .so libraries from the code written in Rust language.

The linkage error is:

/sharedhome/maxaxe01/mbed-cloud-client-example-internal/mbed-cloud-client/parsec-se-driver/target/debug/libparsec_tpm_direct_se_driver.a(compiler_builtins-2541f1e09df1c67d.compiler_builtins.dh9snxly-cgu.0.rcgu.o): In function `__udivti3':
/cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.25/src/int/udiv.rs:247: multiple definition of `__udivti3'
/usr/lib/gcc/x86_64-linux-gnu/7/libgcc.a(_udivdi3.o):(.text+0x0): first defined here
collect2: error: ld returned 1 exit status

As I understand, the problem that some low level processor math function defined twice, in my libgcc and RUST system library compiler_builtins-0.1.25/src/int/udiv.rs May be somebody has some idea how to solve this?

If I link executable with library as shared object, it is successfully linked, but I need to compile with static lib! (cargo build generates both, .so and .a)

This thread ("multiple definition of `memcmp" error when linking Rust staticlib with embedded C program) does not help me.

2

There are 2 best solutions below

0
Elia Geretto On

If the two versions of the function __udivti3 are equivalent, you could try linking your program with -Wl,--allow-multiple-definition. This is obviously an ugly hack and I would be interested in getting a proper solution, but it worked for me. I was getting a similar conflict on __muloti4 between the compiler-builtins crate (part of the standard library) and a static version of LLVM libc++.

Obviously, I am assuming that using a cdylib is not an option for you and your Rust library needs to be static.

0
Efe Balo On

The problem here arises because you use --whole-archive option of linker for all linked libraries (which you should not). Please disable whole archive by --no-whole-archive after you are finished with linking your libraries.

For ex (in cmake).

target_link_libraries ( Mycomponent
                        PUBLIC -Wl,--whole-archive 
                        lib1.a lib2.a
                        -Wl,--no-whole-archive )

Detailed information about --whole-archive