Can quickinstall/binstall be kept from giving unusable binaries when libc is old? #1392
-
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 On CentOS 7, which has GNU libc 2.17 -- and presumably also on some other GNU/Linux systems whose libc version is old -- running Here's some version information from the test system:
The problem happens with both The following shows what happens when I use
I did this before the 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 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 Edit: |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 9 replies
-
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. In the meantime you can try x86_64-unknown-linux-musl For cargo-binstall, we have cargo-bins/cargo-binstall#1332 |
Beta Was this translation helpful? Give feedback.
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
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 possibl…