axodotdev / axodotdev/cargo-dist
linux: detect and record the host build machine's libc style/version
- Dominant language
- Rust
- Stars
- 2.1k
- Forks
- 149
- Avg merge
- 1d 11h
- Merged PRs (30d)
- 32
Description
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
Contributor guide
Research direction
Read the installer logic in cargo-dist/templates/installer/installer.sh.j2 at lines 460-473 and the dist-manifest transfer logic in cargo-dist/src/lib.rs at lines 105-135. Trace how libc and linkage data move from the build machine to the installer-building machine. Done means the manifest records the host libc details and both installers use those recorded values instead of only the hardcoded glibc version.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust, shell
- Domain
- build-system, release
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100