cargo-quickinstall does not work on RHEL8 (glibc error)

[mdekstrand]

Binaries available with cargo-quickinstall do not work on RHEL8 (or derivatives, I presume). They are linked with a minimum glibc version of 2.29, and RHEL8 ships glibc-2.28.

It seems there are two possible solutions:

• Update CI environment to link with older glibc
• Detect glibc incompatibility and switch to musl binaries

Either one would be acceptable for my own use case.

[NobodyXu]

@Milo123459 I think we could also use cargo-zigbuild to fix this?

[alsuren]

@mdekstrand can you tell me a bit more about your use-case?

1. Is it desktop, server or CI? Please tell me as much as you are allowed to about what you're using cargo-quickinstall for.
2. As a work-around, does cargo-quickinstall --target=x86_64-unknown-linux-musl $PACKAGE work for you?
3. I have a feeling that cargo-binstall already has some fallback behaviour. Does this magically do the right thing for you? (I'm a bit out of touch, sorry).
4. Can you think of a simple + portable command that we could run to detect glibc incompatibilities oh the host? This could either be before downloading anything (assuming that we never downgrade out glibc version) or after extracting the binaries (so we can opportunistically check to see whether we have a zigbuild-built package, and fall back to building from scratch otherwise).

For context, cargo-quickinstall was originally written as a way to speed up my CI builds, specifically for github actions. I also made it work on macos because it was easy, and it made my life marginally nicer from time to time. Over time, more architectures were added (I was very excited to learn that I can use it on my aarch64 raspberry pi these days).

Glibc compatibility is something that I would rather not have to think about. I know how much of a pain it can be and I don't want to load it into my head. I also dread having to think about openssl compatibility. I'm definitely in favour of any work-arounds that can improve user experience on non-(ubuntu-20.04/alpine) linux boxes, but they will probably always be second class citizens unless we get another maintainer that's willing to act as champion for their cause.

[NobodyXu]

I have a feeling that cargo-binstall already has some fallback behaviour. Does this magically do the right thing for you? (I'm a bit out of touch, sorry).

Unfortunately, cargo-binstall would only fallback to musl if the upstream/quickinstall does not provide a gnu binary.

cargo-binstall currently doesn't have any check for the glibc version or whether any other dynamic library it depends on is present or not.

It would require us to parse the pre-built binaries and find the dynamic libs and also do the same, which could be recursive.

I don't like running the binary since the user might just want to download but does not want us to run it.

Plus, it's possible that it does not support -V/--version/-h/--help flag.

It might be done in future be that would definitely takes quite some work to accomplish this.

[NobodyXu]

Can you think of a simple + portable command that we could run to detect glibc incompatibilities oh the host?

From this article:

$ ldd --version
ldd (Ubuntu GLIBC 2.31-0ubuntu9.2) 2.31
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

Assuming ldd is present on the system.

[NobodyXu]

Glibc compatibility is something that I would rather not have to think about

IMO using cargo-zigbuild to rebuilt recent versions of crates with old gnu could work.

Or we can stop providing gnu and only provides musl, but that will require us to also use mimalloc for better allocation performance.

The upside is that building musl targets on ubuntu prevents any external C/C++ libs from being dynamically linked since there is just no such lib for musl on ubuntu, which uses gnu.

It will forces these *-sys crates to build a vendored version.

[mdekstrand]

My use case is being able to run general Rust-built software, usually dev or shell tools, on my university's RHEL8 systems. I can cargo install on most of them, but it takes quite a bit more time; also, I expect it would be surprising to other users on RHEL/CentOS/Rocky if pre-built Rust binaries can't run on the latest release of their distribution.

I don't have high-performance needs for most of these tools, so running with musl's slower allocator is just fine for my use case; I also don't rely on integration with features like nsswitch. Others may have other needs, but between "easy to install a binary that works" and that binary being fast, for these smaller tools it just doesn't matter that much.