I committed and tested commit 15470fe, and the build was successful without setting the rpath.

@RossComputerGuy @alyssais It would be great to get this merged, because it blocks kernel builds on pkgsLLVM.

Can the commit message please explain why each of these changes is being made?

Done

It doesn't really explain why still, just what changes are happening, which I can see from the diff. Why is each of these changes the correct thing to do?

Idk how to explain why, it just does.

I don't think it should be necessary to do any of this llvmPackages or llvmSharedFor stuff at all. Why wouldn't llvmPackages just work, even in pkgsLLVM?

I get the strong impression that there is something buggy with how the toolchain is wired up in pkgsLLVM that is creating the perceived need for all these ad-hoc unexplained workarounds for it across the tree. I know Darwin is a different case to pkgsLLVM in many ways, e.g. around the unwinder library and soon libc++, but it's similar enough that the fact that we don't need any of it there makes me strongly suspect the problem here is not with LLVM or Rust. (Though I wouldn't be surprised if there is a still a degree of "Linux = GCC" confusion in Rust's build system, but e.g. Chimera Linux uses an LLVM toolchain and has none of this stuff (other than perhaps this patch, but it seems to relate more to Musl).)

I am worried about adding to these hacks if we can't explain them, because when we start to move these yo principled toolchain conditions they will start to apply to Darwin and we will need to explain what they are actually conditioning on. I think there needs to be more work put into figuring out what the underlying problem with pkgsLLVM is before we extend workarounds that we already have no explanation for. I know there's at least one known issue there with the broken libgcc_s.so. If we're going to move our toolchain bootstrap and checks to be more granular and consistent then overriding stuff at random until it happens to build isn't the right approach.

I don't think it should be necessary to do any of this llvmPackages or llvmSharedFor stuff at all. Why wouldn't llvmPackages just work, even in pkgsLLVM?

Because when rust is a dependency, it comes from buildPackages. When that happens, llvmPackages comes from another stage. The problem which made the special llvmPackages is because things were linking to libstdc++ instead of libc++. This is because things were being accessed too deep.

I did find an easier solution to the cc for one of the overridden dependencies which prompted the first change. However, the libunwind stuff broke since lib.optional was used which made libunwind not discoverable.

If buildPackages uses libstdc++, then it's correct for the Rust compiler to link against it, right? Is this the problem where Rust can't distinguish between a build and host platform with the same target triple, or something else? It probably makes sense for pkgsLLVM to arrange for its buildPackages to use libc++, if it's intended to provide a "native" experience.

If buildPackages uses libstdc++, then it's correct for the Rust compiler to link against it, right?

No because it's linking from something like pkgsLLVM.buildPackages.hostPackages.llvmPackages. At that stage, it is pre-LLVM so it ends up not linking to libc++.

I really don't think this is ready for review… It's blocked by a change request, and we're still waiting to find out why it works.

I thought we already knew the why:

1. Funky splicing of buildPackages vs pkgs which causes useLLVM = false at some point, making libc++ not used
2. libunwind was being provided by lib.optional () [] which causes it to not propagate

I thought we already knew the why:

Well last time I asked, I got "Idk how to explain why, it just does.", and the discussion since didn't seem particularly conclusive, still none of that information is in the commit message, and Emily's further probing on Matrix from earlier is still unresponded to, so I'm not sure how the reviewability is supposed to have changed here.

Emily's further probing on Matrix from earlier is still unresponded to

When was that? It might've been when I was at work or asleep.

still none of that information is in the commit message,

Updated the commit message

Emily's further probing on Matrix from earlier is still unresponded to

When was that? It might've been when I was at work or asleep.

https://matrix.to/#/!kxOJEqURGkuOHTRRQB:matrix.org/$jfJfEVIbG_BXOxjKQw4CMiQfwVWRVdrZrGkt_CVnCjk?via=matrix.org&via=nixos.dev&via=tchncs.de (it pinged you)

We add llvmPackages.libunwind to buildInputs depending on stdenv.targetPlatform.isLLVM. The libgcc_s hack aside, I don’t see how that can be correct – it should surely be either stdenv.hostPlatform.isLLVM or be a libunwind for the target platform.

Other than that, it seems like this is likely downstream of either or both of issues wiring up llvmPackages, and the Rust derivation’s confusion about cross. pkgsLLVM.buildPackages.hostPackages doesn’t exist, but assuming we’re talking about targetPackages instead, perhaps these lines are the culprit?

      ccForBuild = ccPrefixForStdenv pkgsBuildBuild.targetPackages.stdenv;
      cxxForBuild = cxxPrefixForStdenv pkgsBuildBuild.targetPackages.stdenv;
      ccForHost = ccPrefixForStdenv pkgsBuildHost.targetPackages.stdenv;
      cxxForHost = cxxPrefixForStdenv pkgsBuildHost.targetPackages.stdenv;
      ccForTarget = ccPrefixForStdenv pkgsBuildTarget.targetPackages.stdenv;
      cxxForTarget = cxxPrefixForStdenv pkgsBuildTarget.targetPackages.stdenv;

Emily's further probing on Matrix from earlier is still unresponded to

When was that? It might've been when I was at work or asleep.

https://matrix.to/#/!kxOJEqURGkuOHTRRQB:matrix.org/$jfJfEVIbG_BXOxjKQw4CMiQfwVWRVdrZrGkt_CVnCjk?via=matrix.org&via=nixos.dev&via=tchncs.de (it pinged you)

GOException: no routes for location: im.fluffychat://chat/! kxOJEqURGkuOHTRRQB:matrix.org

Rebased messed up

Managed to do some testing and the funky llvmPackages magic we had is no longer needed afaict.