Can quickinstall/binstall be kept from giving unusable binaries when libc is old?

[EliahKagan]

Although I think this is a bug, I don't think it is a bug in gitoxide, since it is not specific to gitoxide. If this cannot otherwise be fixed, then the installation instructions in the gitoxide readme may benefit from mentioning it, which is one excuse reason for asking about it here (see below for another), and also maybe there is some way for individual projects like gitoxide to avoid it (while still having binary builds). I would be interested to report this where it can be fixed in general. Maybe that is cargo-quickinstall itself, I am not sure.

On CentOS 7, which has GNU libc 2.17 -- and presumably also on some other GNU/Linux systems whose libc version is old -- running cargo quickinstall gitoxide or cargo binstall gitoxide succeeds at building and installing gix and ein binaries, but these binaries cannot actually be run.

Here's some version information from the test system:

ek in 🌐 Eald in ~
❯ yum list installed 'glibc*'
Loaded plugins: copr, fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirror.clarkson.edu
 * epel: mirror.team-cymru.com
 * extras: us.mirrors.virtono.com
 * updates: mirror.clarkson.edu
Installed Packages
glibc.x86_64                                              2.17-326.el7_9                                       @anaconda
glibc-common.x86_64                                       2.17-326.el7_9                                       @anaconda
glibc-devel.x86_64                                        2.17-326.el7_9                                       @updates
glibc-headers.x86_64                                      2.17-326.el7_9                                       @updates

The problem happens with both quickinstall and binstall, when an arch-linux-unknown binary build is available for the latest stable version of gitoxide, at least when arch is x86_ 64, which is what I have tested.

The following shows what happens when I use quickinstall and try running gix and ein, but the effect with binstall is analogous.

ek in 🌐 Eald in ~
❯ cargo quickinstall gitoxide
Calling `cargo-binstall` to do the install
 INFO resolve: Resolving package: 'gitoxide'
 INFO resolve: Verified signature for package 'gitoxide-0.36.0-x86_64-unknown-linux-gnu': timestamp:1716428167  file:gitoxide-0.36.0-x86_64-unknown-linux-gnu.tar.gz    hashed
 WARN The package gitoxide v0.36.0 (x86_64-unknown-linux-gnu) has been downloaded from third-party source QuickInstall
 INFO This will install the following binaries:
 INFO   - ein (ein -> /home/ek/.cargo/bin/ein)
 INFO   - gix (gix -> /home/ek/.cargo/bin/gix)
 INFO Installing binaries...
 INFO Done in 8.169073189s

ek in 🌐 Eald in ~ took 8s
❯ gix
gix: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by gix)
gix: /lib64/libc.so.6: version `GLIBC_2.29' not found (required by gix)
gix: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by gix)
gix: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by gix)
gix: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by gix)

ek in 🌐 Eald in ~
❯ ein
ein: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by ein)
ein: /lib64/libc.so.6: version `GLIBC_2.29' not found (required by ein)
ein: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by ein)
ein: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by ein)
ein: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by ein)

I did this before the gitoxide build was recently deleted so it could be rebuilt (#1386 (comment)), so it is not a result of that event. I also believe this is not related to any aspect of #1386.

I also don't believe it is related to gitoxide, though maybe there is some way to prevent it, and maybe gitoxide should mention it in the readme. This seems to happen with any binary installed with cargo quickinstall or cargo binstall on such a system. Software installed with rustup and cargo install works, including cargo install quickinstall.

I think the expected behavior is that when no compatible binary is available, either the software is built from source instead or there is an error message.

This is separate from the libcurl-related issue reported in #1391, and I believe they are independent problems. This is mentioned there in the instructions to reproduce that issue (since those instructions include avoiding quickinstall and binstall). I wasn't sure where to properly report this as a bug, but without it being reported anywhere, my claim in #1391 that it was unrelated to that would not make sense (on the surface, since they are both library issues, they may seem related). So I have "reported" it here, and maybe there is something to be done to mitigate it in gitoxide, but this is really not a gitoxide-specific thing and I hope to report it more properly in the correct place or places.

Edit: @anaconda in yum list refers to the system installer and is not related to the other Anaconda.

[NobodyXu]

I think this issue should be in cargo-quickinstall.

The best solution forward would be to use cargo-zigbuild on x86_64-unknown-linx-gnu, to build for older glibc version.

https://github.com/cargo-bins/cargo-quickinstall/blob/ac9b17516b913284e70a2471e5ec99872e3b9414/build-version.sh#L132

In the meantime you can try x86_64-unknown-linux-musl

For cargo-binstall, we have cargo-bins/cargo-binstall#1332

[Byron]

Thanks for bringing this up here, @EliahKagan , and thanks for your constant pursuit of improvement, @NobodyXu :)!

Assuming that it's going to be fixed one way or another in cargo quickinstall, I think we can leave out that note suggested by @EliahKagan in the README here. Should anything change about that and a fix is further away, I think we should put it though to keep this knowledge in a place where people might profit (even more) from it.

[NobodyXu]

@EliahKagan I've opened cargo-bins/cargo-quickinstall#249

Currently set glibc to build against to 2.17, do you want it to be lower?

[EliahKagan]

Thanks! I expect that 2.17 is low enough. I don't know of any currently supported releases of any distribution that are older than, or use older software than, CentOS 7, though some may match it or come close.

Some distributions use eglibc (from before eglibc merged back into glibc, if I understand the history properly). One such distribution is Ubuntu 14.04 LTS, which remains supported for Ubuntu Pro subscribers (so long as only select packages are used). I have not tested this with that or any other distros that requires subscriptions to receive core security updates, but it uses eglibc 2.19, so supporting 2.17 and later is still new enough for that, as far as the version number is concerned.

I can look into whether I can manage to test on such a system, if there is value in checking what happens on a system that has eglibc rather than the usual glibc. (I could also check to see if my understanding is correct about which one of these CentOS 7 itself uses.) I'm not sure how much value there is in this, and maybe the issue is already well understood, or maybe there is no issue related to glibc/eglibc.

Anyway, as for the library version, I expect that anything older than 2.17 is extremely unusual (unlike CentOS 7, which is still used) and may not be worth supporting.

Should cargo-quickinstall be enhanced so that, for systems that have glibc/eglibc, it checks the version and automatically gets the musl build if the version is lower than supported by the prebuild binaries? I don't know how practical this would be or if there is a reason it has not been done, but I'd be interested to attempt implementing such a feature if you think it may be a good idea.

I expect that this would also allow a version higher than 2.17 to be the minimum version for the glibc builds, though I'm unsure if there is an advantage of that--are there significant disadvantages of supporting such an old library version?

[NobodyXu]

Thanks, it looks like glibc 2.17 is enough.

Supporting eglibc isn't something I'd consider given that it is already merged into glibc 2.19

Should cargo-quickinstall be enhanced so that, for systems that have glibc/eglibc, it checks the version and automatically gets the musl build if the version is lower than supported by the prebuild binaries? I don't know how practical this would be or if there is a reason it has not been done, but I'd be interested to attempt implementing such a feature if you think it may be a good idea.

I plan to implement this in cargo-binstall and I think goblin can be used for this cargo-bins/cargo-binstall#1332

cargo-quickinstall would stay as simple as possible though.

[EliahKagan]

I'm guessing existing built binaries that don't support glibc 2.17 will continue to be served for all versions of crates where builds were generated before this change incargo-quickinstall. So I'm not alarmed or concerned that nothing has changed yet on CentOS for any of the crates I was trying to install that way. When a new version of one of them is released, I'll test it again and update this. Thanks again!

[EliahKagan]

There haven't been updated quickinstall binaries yet for the crates I was testing with before, but I wanted to update this anyway, since CentOS 7 is going end-of-life in a few days, and I'm not sure how much longer I'll maintain that virtual machine for. (Some other distributions use old libc, though perhaps not as old as in CentOS 7.)

So I tested with just, which I know has received updates more recently. I had not tested with it before, but the errors had affected all binaries installed with cargo quickinstall on that system. Using cargo quickinstall just creates usable binaries:

ek in 🌐 Eald in ~
❯ cargo quickinstall just
Calling `cargo-binstall` to do the install
 INFO resolve: Resolving package: 'just'
 INFO resolve: Verified signature for package 'just-1.29.1-x86_64-unknown-linux-gnu': timestamp:1718415134      file:just-1.29.1-x86_64-unknown-linux-gnu.tar.gz        hashed
 WARN The package just v1.29.1 (x86_64-unknown-linux-gnu) has been downloaded from third-party source QuickInstall
 INFO This will install the following binaries:
 INFO   - just (just -> /home/ek/.cargo/bin/just)
 INFO Installing binaries...
 INFO Done in 2.416339316s

ek in 🌐 Eald in ~ took 2s
❯ just
error: No justfile found

I consider this to be a successful confirmation that the change made to support older glibc is successful.

Assuming I still have this CentOS 7 virtual machine when the next version of gitoxide is released, I'll still go ahead and update this again about that. But I consider this to be confirmed as working.

[NobodyXu]

Thanks, good to hear that it's working as intended!