Binary Compatibility and dynamically linked libraries

[lkiesow]

We should probably investigate why this doesn't work. This could cause a few headaches:

Lars Kiesow

[…] since [Tobira] is a static binary + a few systemd unit files

geichelberger

It’s not entirely static. Some libs have dynamic dependencies. Compile it on CentOS8 and it’s not working on CentOS9.

[LukasKalbertodt]

The problem with CentOS seems to be libssl. All dynamically linked libraries:

$ ldd tobira1.1
	linux-vdso.so.1 (0x00007ffdcfdde000)
	libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f640a354000)
	libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f640a07e000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f640a062000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f640a047000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f640a024000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6409ed5000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6409ecd000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6409cdb000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f640b17b000)

I guess in the Linux world it's a religious question whether dynamic or static linking is preferred, but for ease of deployment, I would like to reduce the number of dynamically linked libraries as much as possible.

We could even get rid of libc (and friends) by using musl. It's super easy to compile a Rust project against/with musl, so that's not a problem. However, musl has a few things to keep in mind. If my memory serves me right, something about performance and DNS lookups.

[geichelberger]

musl has performance issues:
https://www.linkedin.com/pulse/testing-alternative-c-memory-allocators-pt-2-musl-mystery-gomes

Dynamically linked libraries have benefits, e.g., you get security updates for free.

[ziegenberg]

Disadvantages of statically linked libraries:

• If the library needs to be updated, your application needs to be rebuilt and distributed.
• For every used library you are now responsible for keeping an eye on relevant security updates. And with every update, you need to create a release in a timely manner.

[ziegenberg]

Question is: why do you need libssl when I see rustls all over the place in the Cargo.toml?

[ziegenberg]

Looks like meilisearch-sdk uses isahc which says:

Rustls support: We hope to support rustls as a TLS backend someday, it is not currently supported directly. If for some reason rustls is a hard requirement for you, you'll need to use a different HTTP client for now.

[LukasKalbertodt]

Oh hey, thanks for investigating. I had no time looking at this before. And yeah, looks like libssl is only required due to isahc due to meilisearch-sdk. However, isahc seems to almost work with rustls already: sagebind/isahc#199 They said they would release this support with 2.0, which is planned to release "soon".

Unfortunately, that doesn't really help as meilisearch_sdk would have to update their isahc version then first. The situation isn't great anyway: we already have an HTTP library in the binary, no need to also pull in isahc with curl. I am also not super happy with meilisearch-sdk anyway.
So ehm... a few different paths forward, but none is really great. The easiest is probably preparing a patch for meilisearch_sdk adding support for a different HTTP client instead of isahc.

---

Oh and for reference:

[libz-sys 1.1.8] cargo:rustc-link-lib=z
[openssl-sys 0.9.75] cargo:rustc-link-lib=ssl
[openssl-sys 0.9.75] cargo:rustc-link-lib=crypto

Seems like all other dynamically linked libaries are not "caused" by any dependencies, but are standard links for x86_64-unknown-linux-gnu.

[ziegenberg]

Or just build different binaries for different platforms. That's probably the easiest and also fastest way forward.
For releases we could use the GitHub actions matrix build feature.

[LukasKalbertodt]

With #546 I found an easy way to statically link libssl, libcrypto and libz. With that, only "std libs" are dynamically linked. These we can only get rid off by using musl and that's tracked by #116. So I'll close this issue.