Re: Building lang/rust on Linux with Musl libc

[Tobias Nygren <tnn%NetBSD.org@localhost>]

On Sat, 26 Aug 2023 19:12:10 -0400
Greg Troxel <gdt%lexort.com@localhost> wrote:

> Nathan Fisher <nfisher.sr%gmail.com@localhost> writes:
> 
> > This port needs to fetch a binary toolchain to bootstrap the compiler
> > from source. It fails on Linux using Musl libc because after checking
> > what the OS is and determining that it is Linux it automatically grabs
> > the "gnu" version of the toolchain.
> >
> > .if ${MACHINE_PLATFORM:MLinux-*-aarch64} || make(distinfo) || make
> > (makesum) || make(mdi)
> > RUST_STAGE0_VER=    1.68.2
> > RUST_ARCH:=        aarch64-unknown-linux-gnu
> > ...etc
> >
> > I'm aware that there is no particularly good way to check for Musl at
> > compile time, but it would be great if this port could at the very
> > least have a way to override the assumption of Glibc, even if it's
> > just manually using the package options framework. Probably better
> > would be if there were a global flag that could go into
> > /usr/pkg/etc/mk.conf as I assume there have to be other packages that
> > would benefit by knowing that they are being compiled on a Musl
> > system? I'd be happy to put some work into a fix if there was some
> > concensus as to what the best way forward is.
> 
> My quick reaction is that in pkgsrc, we really deal with operating
> systems and not kernels.  So "linux" despite what it technically means,
> is really GNU/Linux, in that if you look at mk/platform/Linux.mk it will
> assume GNU.

> 
> You are using musl+?/Linux which is a different operating system from
> GNU/Linux, and it needs its own platform mk.   Then it needs a way to
> identify it, perhaps by bootstrap-time switch.  And finally, packages
> could have support for this platform.
> 
> I wouldn't want to push this into options; it doesn't fit.
> 
> Others may see it differently, and I might after thinking more, but
> that's how I see it now.

Not a fan of encoding musl as a different platform if it implies
$OPSYS diverges from `uname -s`. Worried it will cost more than it's
worth outside of mk/.

While binary packages linked with musl libc are not portable to
systems with glibc, this is a fact across all glibc Linux distros as
well due to different libstdc++.so major numbers, builtin packages,
systemd ABI unstability and so on. pkg_add should really refuse to work
with binary packages from a foreign distro but it's beyond the scope of
the rust problem we're discussing.

I would suggest to do a C preprocessor check during bootstrap in order
to set something like _OPSYS_HAS_MUSL automatically in the generated
mk.conf. Run-time preprocessor checks are generally a bad idea.

-Tobias