libssl.so.3: cannot open shared object file

[ktmeaton]

Now that we're in the land of compiled languages (Rust) it's type to troubleshoot dynamic library linking on other systems.

error while loading shared libraries: libssl.so.3: cannot open shared object file: No such file or directory

[ktmeaton]

rebar: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), statically linked, no section header

From StackOverflow by Steve Klabnik: "Rust statically links everything but glibc (and libgcc, iirc) by default. If you want to get a 100% statically linked binary, you can use MUSL with 1.1. rust-lang/rust#24777 is the initial support, we hope to make it much easier to use in the future.

[ktmeaton]

Also from Kornel: openssl-sys and other openssl-dependent crates have vendored-openssl Cargo feature that you can enable and this usually helps with this particular dependency.

[ktmeaton]

The openssl errors can be fixed by using the vendored featured of the openssl crate. This will compile OpenSSL from source, and statically include the libraries into the binary

openssl = { version = "0.10.59", features = ["vendored"] }

[ktmeaton]

However! Now there are errors linking to GLIBC on older systems (ex. CentOS 7).

• CentOS 7 uses GLIBC 2.17 (link).
• GitHub Actions ubuntu-latest uses GLIBC 2.XX?
• My dev environment uses GLIBC 2.35 (ldd --version ldd)

objdump -T target/x86_64-unknown-linux-gnu/release/rebar | tail -n+5 | cut -f 2 | cut -d " " -f 2- | sort

• I could try and build for MUSL, which will remove the dependencies on GLIBC. But who knows how big the final binary will be, and if I'll be able to get it to compile at all..
• I might instead try the cross crate, which uses Docker Containers to help with cross-compilation.

[ktmeaton]

Resolved with 5dd2ec7 by using the cross crate and comping for MUSL!