Skip to content

Installer doesn't work on alpine/musl #1326

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
konstin opened this issue Feb 20, 2024 · 3 comments
Closed

Installer doesn't work on alpine/musl #1326

konstin opened this issue Feb 20, 2024 · 3 comments

Comments

@konstin
Copy link

konstin commented Feb 20, 2024

If i use the installer script for linux (curl -LsSf https://get.nexte.st/latest/linux | tar zxf - -C ${CARGO_HOME:-~/.cargo}/bin) on an alpine docker container, i get a glibc build instead of the musl build:

To reproduce, start a docker container (in my case x86_64) with docker run --rm -it alpine and run the following commands in it:

apk add curl file tar
mkdir -p /root/.cargo/bin
curl -LsSf https://get.nexte.st/latest/linux | tar zxf - -C ${CARGO_HOME:-~/.cargo}/bin
file /root/.cargo/bin/cargo-nextest

Output:

/root/.cargo/bin/cargo-nextest: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.0.0, stripped

Running /root/.cargo/bin/cargo-nextest prints "not found".

Compared with a musl binary:

$ file /bin/tar
/bin/tar: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-x86_64.so.1, BuildID[sha1]=27564d92ae8bd019cb2e3511726a515526a95b5c, stripped

The musl binary from the releases page does work, it seems it's only the installer not checking the platform:

$ file /root/.cargo/bin/cargo-nextest
/root/.cargo/bin/cargo-nextest: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), static-pie linked, stripped

Since the statically linked musl version also works on glibc systems, would it be possible to link the musl version under https://get.nexte.st/latest/linux instead of the glibc version?

@sunshowers
Copy link
Member

Thanks for the report!

Ah ha -- so at the moment we don't actually have an installer script -- that command just untars a binary into the right spot. I think building out an installer script would be interesting. Though I'd want to hook it up to the release metadata we serve in releases.json. This would likely mean that the installer downloads a Rust binary -- which then fetches the release metadata and selects the right version for the platform. This is similar to how rustup-init works.

@sunshowers
Copy link
Member

Going to close this issue out since using the linux-musl version works here.

Since the statically linked musl version also works on glibc systems, would it be possible to link the musl version under https://get.nexte.st/latest/linux instead of the glibc version?

At the moment the musl version has a bug (rust-lang/rust#99740) that the glibc version does not, which is why the glibc version is recommended. However I have work in flight to fix it, likely by the time Rust 1.84 is out. Maybe after that, though in some casual profiling I've seen musl's malloc be significantly slower than glibc's.

@sunshowers sunshowers closed this as not planned Won't fix, can't repro, duplicate, stale Oct 4, 2024
@sunshowers
Copy link
Member

cargo-nextest 0.9.89 is built against Rust 1.84, which fixes the process spawn issue on the musl build. I'm in two minds about actually making it the default though -- musl's malloc is known to be slower. It might be worth trying out a custom malloc like mimalloc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants