Request for adding {free/hardened}bsd and linux-musl to official releases

[tuncer]

I have one FreeBSD (HardenedBSD11) and another Linux-musl system where downloading+using or downloading+building Rust releases is not very practical. In either case, if I were to try bootstrapping Rust (or Cargo), then the build would use a specific nightly (in Rust’s case) to bootstrap itself, which requires running a glibc Rust nightly downloaded from rust-lang.org.

I’ve considered preparing and reusing old releases, in order to do this on each stable release, but because stable releases are bootstrapped with nightly snapshots, this is impossible to do, unless you want to go through doing many nightly bootstraps first (to arrive at the required nightly), or find a way to run the nightly snapshot via some glibc compat or linux emulation layer.

The question or feature request is this: Can we please have {free/hardened}bsd and linux-musl amd64 releases?

[alexcrichton]

We’re certainly always willing to have more rustc releases! Right now this falls within the category of our platform support, and you’ll notice that we have tier 2 (always builds) support for MUSL, but only for libstd. FreeBSD, however is currently tier 3 for both the compiler and standard library.

To get releases rolling, we’d need to move both of these platforms to tier 2 for both libstd and the compiler itself. This would likely involve:

• Fixing all tests on FreeBSD
• Start gating on FreeBSD for all auto commits, this probably involves setting up a FreeBSD AMI that we can run
• Get a MUSL compiler building
• Ensure all tests work with a MUSL compiler
• Start running a nightly build of the MUSL compiler.

There are two major things which probably need to happen which have blocked this in the past. FreeBSD has historically had pretty flaky tests, and we don’t always have the energy for fixing regressions. We’d probably want a cycle or two of stability without flaky builders before we start gating on it “for real”.

For a MUSL compiler we currently infer that “MUSL == statically linked”, which primarily means that operations like dlopen will not work. This is currently how compiler plugins are implemented, so the MUSL nightly compiler would not be as full featured as the other nightly compilers, and we don’t currently really support compilers that have half the features of others without a path to earning them.

Hope that helps!

[briansmith]

This is currently how compiler plugins are implemented,

Aren’t compiler plugins unstable? If so, then -beta and -nightly channel musl rustc would actually be more like a production release than normal builds of the compiler on -beta and -nightly. So, I don’t think that compiler plugins would get in the way.

Plus, dlopen is implemented by libdl, not libc. It seems like there must be a variety of ways to get musl-based systems to support dlopen or equivalent.

However, I see musl as more of a stepping stone than as an end-goal. We should be able to target Linux without libc and without loss of libstd functionality**. And, in particular, rustc should be able to run when built against such a version of libstd.

**I suspect such a project would find some parts of libstd to be unreasonable to implement and thus subject to deprecation generally. I’m thinking of CString and some synchronous/blocking networking APIs in particular. In other words, I think they are in the standard library because they are easy to implement over libc and implementing any alternative using (only) libc is hard, not because they are actually reasonable APIs.

[sorear]

Plus, dlopen is implemented by libdl, not libc. It seems like there must be a variety of ways to get musl-based systems to support dlopen or equivalent.

This is somewhat tangential but:

1. musl systems do not use libdl, libm, libpthread, etc; see http://www.musl-libc.org/faq.html (third from last item)
2. musl does implement dlopen, although dlclose is a no-op (probably won’t be a problem)

(disclaimer: I have not tested dlopen with musl myself)

[tuncer]

For a MUSL compiler we currently infer that “MUSL == statically linked”, which primarily means that operations like dlopen will not work.

Isn’t this quite limiting? I know that musl is used because it allows fully static linking, but your typical musl linux distro (alpine, void) does not link statically by default. That said, static linking can be a useful feature, so I’m not arguing to drop one for the other.

Either way, if adding statically linked musl releases is easier/quicker to accomplish, that will also suffice.

[tuncer]

There are two major things which probably need to happen which have blocked this in the past. FreeBSD has historically had pretty flaky tests, and we don’t always have the energy for fixing regressions.

An official builder that has failing tests on the desired platform is more valuable and useful for reaching the goal than keeping it external and out of focus (invisible). From experience I can say that this has higher chances of stuff getting fixed due to higher visibility and badge of approval as an official platform.

[aidanhs]

I don’t think dynamically linked musl would help (in the goal of official releases of static musl) because it’s effectively a different target to static musl. Even if you get compiler plugins working on dynamic musl, static musl is still crippled and wouldn’t qualify for nightly releases per “we don’t currently really support compilers that have half the features of others without a path to earning them” (which I can understand).

To copy+paste from https://github.com/rust-lang/rust-buildbot/issues/24:

I think the next step is to do one of two things:

1. Convince the rust team that they should do stable releases of MUSL even though there aren’t nightlies. Probably a tough sell!
2. Figure out some way to make compiler plugins work in musl. Here’s some useful info on dlopen and static linking if anyone’s interested - http://www.openwall.com/lists/musl/2012/12/08/4. Sounds decidedly nontrivial.

[sfackler]

It should be noted that plugins may transition away from being dlopen-ed to running in a separate process and talking over some IPC bridge.

[briansmith]

Maybe instead of asking the Rust core teams to maintain an official musl port with official releases, somebody else could maintain the musl port and issue releases? And the core teams could at least make a good-faith effort to accept the patches into mainline that are necessary to make that port work?

Personally, I think a switch from a glibc-based target to a musl-based target makes much more sense for things that aren’t written in Rust. For Rust, I think musl libc is a transitional tool to a libc-less libstd.

[globin]

I’ve actually packaged up rust with musl as libc in nix, it currently isn’t upstream in nixos yet because I’m hacking around the libunwind stuff for musl which is a bit hacky but still planning to do that.

Built packages are at https://hydra.mayflower.de/jobset/nixos/rust#tabs-jobs

Implementation at: https://github.com/mayflower/nixpkgs/blob/master/pkgs/development/compilers/rustc/musl.nix

Nix/nixos might actually be interesting to quite some rust users, but I’m aware that people won’t necessarily want even more package managers or switch distributions. If you have questions also feel free to ping me (globin) in #rust or #nixos on freenode

[tuncer]

Maybe instead of asking the Rust core teams to maintain an official musl port with official releases, somebody else could maintain the musl port and issue releases? And the core teams could at least make a good-faith effort to accept the patches into mainline that are necessary to make that port work?

It’s important to maintain a musl (or freebsd) build, regardless of completeness, in the official build matrix. Keeping it external is too much work, due to the arguments above regarding bootstrapping requirements. Once in the build matrix, it’s highly visible and failing tests will not be hidden in some external developer’s private build log somewhere.

[tuncer]

@aidanhs, I’m not asking for static musl support, but if that’s easier to achieve, then that’ll do. I use voidlinux-musl (which does not statically link everything), and if I’m not mistaken, plugins should work there as well.

[aidanhs]

and you’ll notice that we have tier 2 (always builds) support for MUSL, but only for libstd

Could the default linux compiler come with both glibc and musl stdlib support? A rust compiler built with --target=x86_64-unknown-linux-musl is able to compile to glibc as well as musl, so this solves one major use-case (static compilation on glibc platforms).

I’ve actually packaged up rust with musl as libc in nix, it currently isn’t upstream in nixos yet because I’m hacking around the libunwind stuff for musl which is a bit hacky but still planning to do that.

libunwind stuff? Doesn’t it Just Work?

@aidanhs, I’m not asking for static musl support, but if that’s easier to achieve, then that’ll do. I use voidlinux-musl (which does not statically link everything), and if I’m not mistaken, plugins should work there as well.

I’ve realised that my use-case is orthogonal to yours - you want to build rustc on a musl linux, I want to use a musl-targeting compiler on a glibc linux. Couple of links which look related to your use-case - https://github.com/rust-lang/rust/issues/31322, https://github.com/rust-lang/rust/issues/28667.

[aidanhs]

Could the default linux compiler come with both glibc and musl stdlib support? A rust compiler built with --target=x86_64-unknown-linux-musl is able to compile to glibc as well as musl, so this solves one major use-case (static compilation on glibc platforms).

Hardworking people have quietly made this suggestion a reality - the new rustup can download the musl stdlib for you. See Static binary support in rust and the linked thread from there.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.