Bug 2419092

What do you need this for?

That's actually a great question.

I was trying to build a statically-linked MUSL binary (specifically, `netavark`) to do some testing on an Aarch64 EL9 machine, but it didn't run because said binary linked the interpreter `/lib/ld-musl-aarch64.so.1`. I did a simple search and it seems like `musl` provides this file; that's why I thought I should request this package.

But on reflection today, I thought that was kind of weird. In my experience with MUSL, the binary should run just fine without any userspace dependencies. So I went down the rabbit hole investigating, eventually realising that configuring `rustc` to use `lld` as linker caused this weirdness, specifically for the `aarch64-unknown-linux-musl` target. See this question I posted on SO: https://stackoverflow.com/q/79841600/5637701.

Anyways coming back around, it seems like as long as I use the default linker (or otherwise figure out why `lld` has this behaviour), my MUSL binary would not need this package to run. So yeah, it would be nice to have of course, but no, I don't technically need it. Please feel free to close if you don't wish to move forward with this.

(In reply to cyq from comment #2)
> That's actually a great question.
> 
> I was trying to build a statically-linked MUSL binary (specifically,
> `netavark`) to do some testing on an Aarch64 EL9 machine, but it didn't run
> because said binary linked the interpreter `/lib/ld-musl-aarch64.so.1`. I
> did a simple search and it seems like `musl` provides this file; that's why
> I thought I should request this package.
> 

I don't think you actually built it statically in that case.

> But on reflection today, I thought that was kind of weird. In my experience
> with MUSL, the binary should run just fine without any userspace
> dependencies. So I went down the rabbit hole investigating, eventually
> realising that configuring `rustc` to use `lld` as linker caused this
> weirdness, specifically for the `aarch64-unknown-linux-musl` target. See
> this question I posted on SO: https://stackoverflow.com/q/79841600/5637701.
> 
> Anyways coming back around, it seems like as long as I use the default
> linker (or otherwise figure out why `lld` has this behaviour), my MUSL
> binary would not need this package to run. So yeah, it would be nice to have
> of course, but no, I don't technically need it. Please feel free to close if
> you don't wish to move forward with this.

It doesn't seem like you should need to do this, since netavark lives on the host anyway so using normal glibc should be fine.

(In reply to Neal Gompa from comment #3)
> I don't think you actually built it statically in that case.

Yeah I agree, although curiously `file` reports `statically linked`. I don't really know what's going on there.

> It doesn't seem like you should need to do this, since netavark lives on the
> host anyway so using normal glibc should be fine.

My local dev machine is Arch Linux, so if I target `x86_64-unknown-linux-gnu` (I tried), the GLIBC version requirement is too high for EL9. I also couldn't build on the deployment machine because its network access is restricted, which makes using `cargo` complicated.

In the end I pulled a Rocky Linux 9 container image and built in there targeting GNU, because at the time I didn't yet figure out the problem with my MUSL build.

Correction: `x86_64-unknown-linux-gnu` -> `aarch64-unknown-linux-gnu`.

Yeah, I would have done either a UBI9 or AlmaLinux 9 environment to build stuff. Or even if it was as an RPM, Mock would do the right thing for you anyway.