0

I'm trying to use a second rust library ( via cbindgen ) with my cpp program on a musl target. I use cross to crosscompile. 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 succesfully compiling the rust library

I had a similar problem ( also glibc ) in the first library when i added to [lib] crate-type the value rlib( I have there only staticlib, i link those libraries statically ) to make integration tests to work ( solution from https://users.rust-lang.org/t/does-crate-type-has-effect-on-integration-test/76634 )

Now i don't have any tests, but a lot more libraries, in that open ssl 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"] }

I'm completly lost with this. Here is a readelf of the rust library ( it's 250Mb because it's debug build to include all info, be aware ): http://pkgs-inkbox.duckdns.org:25560/misc/readelf.txt

Here is the repository with the code: https://github.com/Szybet/Libretranslate-rs-to-cpp

Here is the cpp program i'm linking it against https://github.com/Szybet/inkbox/tree/toreader

I tryied other [lib] options, specifically crate types with no change, I'm out of ideas

Szybet
  • 5
  • 1
  • 2.4 was quite a while ago. You may have a very stale library in there somewhere. – user4581301 Aug 23 '23 at 22:12
  • @user4581301 The `GLIBC_2.4` symbol version merely means that the symbol was introduced or had its ABI changed in that version of glibc. It does not mean that glibc 2.4 is being used. – jilles Aug 23 '23 at 22:22
  • Looks like I need to do less embedded stuff and more big-boy OSes to get up to speed on their foibles. – user4581301 Aug 23 '23 at 22:37

2 Answers2

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.

273K
  • 29,503
  • 10
  • 41
  • 64
  • This is basically the answer. The reason i wasn't able to resolve it was that i was using qmake and there are many ways to add -lrt, the one that worked was LIBS += -lrt - sadly i still have another problem, i created another question related to it https://stackoverflow.com/questions/76967572/undefined-reference-to-sigsetjmp-in-rust-static-library-musl-build-with-openss – Szybet Aug 24 '23 at 08:40
1

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.
jilles
  • 10,509
  • 2
  • 26
  • 39