cargo-quickinstall: Problems with dynamically linked binaries (e.g. no OpenSSL 3 compatibilty)

Some of the newer OSes (notably Ubuntu 22.04 LTS Jammy Jellyfish) only ship with OpenSSL 3.0 and do not have an OpenSSL 1.1 package. This results in an error when trying to run the executable built by this project as Ubuntu 20.04 which the executables here are built with ships with OpenSSL 1.1:

/home/ubuntu/.cargo/bin/cargo-install-update: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

This is problematic because different OSes will have different versions of libraries available. I feel like linking more things statically would be helpful here. To allow to support many currently used operating systems, it probably would make sense to limit the number of libraries that you link against dynamically.

For starters, statically linking OpenSSL would help with a bunch of packages already. This isn’t necessarily that easy since you would need a static build of OpenSSL but I think it might be achievable by either building a custom Docker image with a static OpenSSL build (and other static libs in the future) or using some existing work such as:

All of these are musl-based as statically linking with glibc is usually advised against because of NSS issues and licensing.

I’d like to also mention Python’s manylinux images as the Python packaging community seems to have solved this problem of supporting mainstream distros with a single build: https://peps.python.org/pep-0600/#core-definition They approached this problem a bit differently and the specification allows you to dynamically link against glibc as well as any dynamic libraries that are available in ALL mainstream distros with that (or newer) glibc version. Anything else still would need to be statically linked. Considering that you can’t really give separate builds for people with different glibc versions like Python does, you would presumably have to choose a single minimum glibc version for which you want to build. Maybe it’s not that great of an idea for solving this issue but I wanted to at least mention how the Python packaging community approached it. The upside of this would be that you would still be able to build against glibc and just would have to limit yourself to only dynamically linking glibc and the few libraries that are available in ALL mainstream distros with that minimum glibc version.

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 18 (12 by maintainers)

Most upvoted comments

I think we can try to list all features of the binary crate, then find all features started with vender and enable them.

I resisted this idea for ages, to limit the scope of cargo-quickinstall (and to avoid having to re-build my archive of packages with whatever new scheme I pick). Maybe it is worth doing though, because it’s our top issue.

Interestingly, cargo install will let us specify features of transitive dependencies, like this:

$ cargo install cargo-update --features=openssl-sys/vendored

If you name a crate that isn’t in the dependency tree, you get an error back almost immediately.

$ cargo install bat --features=openssl-sys/vendored
    Updating crates.io index
  Installing bat v0.22.1
error: failed to compile `bat v0.22.1`, intermediate artifacts can be found at `/var/folders/0b/_8p88w416s15l8f02rn0m9hr0000gn/T/cargo-installeif3yN`

Caused by:
  package `bat v0.22.1` does not have a dependency named `openssl-sys`

If all of our bug reports are currently about openssl then we could just try compiling with --features=openssl-sys/vendored enabled and then fall back to installing without that flag when it fails.

In theory, if we end up with a bunch of packages that are similar to openssl then we could tee stderr to a file and look for the

```does not have a dependency named `aaaa````

error message, to remove that package from the list.

We can deal with that later though.

(Annoyingly, the openssl-sys?/vendored syntax from https://doc.rust-lang.org/cargo/reference/features.html#dependency-features still fails if openssl-sys is not a dep. Maybe we could propose fixing that upstream?)

alsuren on Dec 18, 2022