How to fix undefined reference to glibc 2.4 symbol when linking Rust static library for musl target?

Question

I'm trying to use a Rust library (via cbindgen) with my C++ program on a musl target. I used cross to cross compile. The exact error is:

/mnt/HDD/Project/inkbox-build/inkbox/compiled-binaries/arm-kobo-linux-gnueabihf/bin/../lib/gcc/arm-kobo-linux-gnueabihf/11.2.0/../../../../arm-kobo-linux-gnueabihf/bin/ld.bfd: /mnt/HDD/Project/inkbox-build/inkbox/inkbox-toreader/libs/Libretranslate-rs-to-cpp/lib//libLibretranslate_rs_to_cpp.a(Libretranslate_rs_to_cpp-da46da90a85dac4d.Libretranslate_rs_to_cpp.a677ed00b91c84d4-cgu.0.rcgu.o): in function `rust_eh_personality':
/rustc/03a119b0b0e310d22d94399b24ed030056050f13/library/std/src/sys/personality/gcc.rs:99: multiple definition of `rust_eh_personality'; /mnt/HDD/Project/inkbox-build/inkbox/inkbox-toreader/libs/libreader-rs/lib//libreader_rs.a(reader_rs-08f466727572406f.reader_rs.16ecb517c7176846-cgu.0.rcgu.o):/rustc/03a119b0b0e310d22d94399b24ed030056050f13/library/std/src/sys/personality/gcc.rs:99: first defined here
/mnt/HDD/Project/inkbox-build/inkbox/compiled-binaries/arm-kobo-linux-gnueabihf/bin/../lib/gcc/arm-kobo-linux-gnueabihf/11.2.0/../../../../arm-kobo-linux-gnueabihf/bin/ld.bfd: /mnt/HDD/Project/inkbox-build/inkbox/inkbox-toreader/libs/Libretranslate-rs-to-cpp/lib//libLibretranslate_rs_to_cpp.a(Libretranslate_rs_to_cpp-da46da90a85dac4d.Libretranslate_rs_to_cpp.a677ed00b91c84d4-cgu.0.rcgu.o): undefined reference to symbol 'clock_gettime@@GLIBC_2.4'
/mnt/HDD/Project/inkbox-build/inkbox/compiled-binaries/arm-kobo-linux-gnueabihf/bin/../lib/gcc/arm-kobo-linux-gnueabihf/11.2.0/../../../../arm-kobo-linux-gnueabihf/bin/ld.bfd: /home/build/inkbox/compiled-binaries/arm-kobo-linux-gnueabihf/arm-kobo-linux-gnueabihf/sysroot//lib/librt.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status

It happens when I try to create the C++ program after successfully compiling the Rust library.

I had a similar problem (also glibc) in the first library when I added because I had [lib] crate-type = ["rlib"] (I have there only "staticlib" now, I link those libraries statically) to make integration tests to work (solution from here).

However, this time I don't have any tests but a lot more libraries: openssl vendored and some hacky tokio futures:

futures = "0.3"
futures-executor = { version = "0.3", features = ["thread-pool"] }
libretranslate = { path = "lib-rs/libretranslate-rs" }
openssl = { version = '0.10', features = ["vendored"] }

Some extra info:

• Here is a readelf of the Rust library (it's 250Mb because it's debug build to include all info).
• Here is the repository with the code.
• Here is the C++ program I'm linking it against.

I'm completely lost with this. I tried other [lib] options and crate types with no change.

Answer 1

Linux manual pages

Link with -lrt (only for glibc versions before 2.17).

Your glibc version is 2.4, hence this instruction is good for your code.

Answer 2

There are two errors:

• The duplicate rust_eh_personality seems hard to fix properly with static linking (see e.g. https://github.com/mozilla/uniffi-rs/issues/1670 ), but adding panic = "abort" to the debug profile should work around it. In some sense, this is a symptom of linking parts of the Rust standard library twice into the final executable, which ought to work but is a bit wasteful.
• The error about clock_gettime@@GLIBC_2.4 seems to be because at least some part of the code is actually using glibc instead of musl. Having both glibc and musl in the same process seems a bad idea at the least.