search

axodotdev / cargo-dist

📦 shippable application packaging
https://axodotdev.github.io/cargo-dist/
Apache License 2.0
1.49k stars 70 forks source link

linux: detect and record the host build machine's libc style/version #519

Open Gankra opened 12 months ago

Gankra commented 12 months ago

We have logic in the shell installer (and npm installer) to ask ldd for libc details:

https://github.com/axodotdev/cargo-dist/blob/e522919a69e7b7995c8bb283abc58b29ffa2b31e/cargo-dist/templates/installer/installer.sh.j2#L460-L473

However we compare the glibc version against a currently hardcoded number (the version on ubuntu-oldest github ci runners). We also have no given value for musl libc version. We should ideally get this information properly and store it in the dist-manifest alongside the rustc/cargo versions. Then the installers can read that info and properly set these values.

We actually already have some logic for build machines to transfer this kind of data through the dist-manifest to the final installer-building-machine. It's currently narrowly scoped to linkage, but can be generalized to include this data too: https://github.com/axodotdev/cargo-dist/blob/e522919a69e7b7995c8bb283abc58b29ffa2b31e/cargo-dist/src/lib.rs#L105-L135

bugadani commented 4 months ago

I would like to add that this issue means ARM binaries built with e.g. buildjet-2vcpu-ubuntu-2204-arm are incorrectly handled by the install script and the installed binaries may not work.

An example of this is trying to run probe-rs on raspbian bullseye: the script assumes that the distributed binaries are built for glibc 2.31, the installer detects 2.31 support, installs the -gnu binary which then fails to run because it's only compatible with glibc 2.32..=2.34.

As different binaries may be built with different builder images, the install script shouldn't assume a single glibc version.

mistydemeo commented 2 weeks ago

We've begun doing this for glibc (but not musl). We also properly use the glibc information per-platform when installing.