rustc: use targetPlatform to detect pkgsLLVM, unbreak with LLVM and musl

[getchoo]

Pseudo-alternative to #330037

Following #376988, it seems pkgsLLVM.pkgsMusl and similar combinations work as expected! This has led me to do a bit of testing based on this comment from a Rust developer on using LLVM/libunwind:

Systems without a GNU userland shouldn't use the *-linux-unknown-gnu toolchains, which explicitly require a GNU userland. Your supposed to use *-linux-unknown-musl.

Sure enough after a little tweaking, pkgsLLVM.pkgsMusl.rustc appears to be fully functional :)

Tested against #375030 and with the following:

> nix build -f . pkgsLLVM.pkgsMusl.rustc.unwrapped.tests.{fd.tests,ripgrep} --print-out-paths
/nix/store/mlbxa62xnyq1sbdvhnxxvsaspcgpbql7-fd-x86_64-unknown-linux-musl-10.2.0-test-version
/nix/store/axbmix7qmp670xllvny8w9s4xiyfw46f-ripgrep-x86_64-unknown-linux-musl-14.1.1

We should of course continue looking for ways to get pkgsLLVM alone to build rustc properly, but hopefully this can hold us over until a solution is found

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[pwaller]

Heads up the requisite has been reverted in #379615. Hopefully it gets fixed and relanded before too long.

[wolfgangwalther]

Heads up the requisite has been reverted in #379615. Hopefully it gets fixed and relanded before too long.

Unfortunately, it's impossible to land this soon, it requires a deprecation phase on the NixOS side which imho can't be avoided and can't be worked around. So.. don't hold you breath - I have put it on hold for me for now :(

[getchoo]

That is sad to hear. The composition introduced in that PR was honestly a game changer in solving this problem

I'll see if we can get the same logic working OOTB with pkgsLLVM in the meantime ;)

[alyssais]

The composition introduced in that PR was honestly a game changer in solving this problem

Is it not just sugar for setting { useLLVM = true; config = "x86_64-unknown-linux-musl"; } or whatever?

[getchoo]

Basically lol, I was just having some trouble with trying to extend the current stdenv with some of those variables -- it's the same as what happens with packages evaluated from pkgsLLVM.pkgsMusl now AFAICT

This PR will continue to work with

import <nixpkgs> {
  localSystem.system = "x86_64-linux";
  crossSystem = {
    config = "x86_64-unknown-linux-musl";
    useLLVM = true;
    linker = "lld";
  };
  config = { };
  overlays = [ ];
}

But I'm not sure how we can make this buildable again directly 🤷

[wolfgangwalther]

The composition introduced in that PR was honestly a game changer in solving this problem

Is it not just sugar for setting { useLLVM = true; config = "x86_64-unknown-linux-musl"; } or whatever?

Essentially yes. I guess the most value those predefined package sets bring is.. the fact that they encode this knowledge and thus you're more likely to find something that doesn't immediately break everything. Similar to lib/systems/examples.nix, but for non-cross. So yeah, convenience.

[wolfgangwalther]

That is sad to hear. The composition introduced in that PR was honestly a game changer in solving this problem

We probably found a way without touching NixOS and hopefully without lengthy deprecation phases.

Can you try this on top of #380342?

[emilazy]

I think this PR is based on somewhat of a misconception. The linked comment reads:

Systems without a GNU userland shouldn't use the *-linux-unknown-gnu toolchains, which explicitly require a GNU userland. Your supposed to use *-linux-unknown-musl.

But this is in the context of someone using a (Musl‐based) Alpine system, and LLVM is only mentioned in the context of Gentoo’s llvm-musl profile. The intended meaning is not “systems without [a GCC‐based compilation toolchain]”, but “systems without [a glibc‐based runtime]”. (Following discussion reveals that the reporter was actually using *-linux-unknown-musl and the whole thing was a miscommunication.)

pkgsLLVM should be largely orthogonal to glibc vs. Musl. (I suspect the reason it’s working with Musl is due to Rust’s conflation of Musl with static‐linking‐by‐default or something?) I don’t think it’s the case that Rust only supports Musl when using an LLVM‐based compilation toolchain, and that wouldn’t make much sense. I think that the correct alternative to this and #330037 would be to pass the appropriate target flags to make Rust use libunwind directly, or maybe use a custom target definition if necessary. At most maybe the Rust standard library needs patching for incorrect assumptions about the unwinder library? However, I do think that this PR is an improvement over the status quo apart from the inaccurate comment, since the symlink is a terrible hack that we shouldn’t need.

I think that the more general solution is probably going to be packaging llvm-libgcc, though that shouldn’t be necessary for Rust. As the linked documentation says, glibc makes assumptions about libgcc, so replacing libgcc with compiler-rt + libunwind while using glibc works best with a libgcc shim. (But it’s possible this is out of date or I’m misunderstanding things.)

cc @RossComputerGuy