wrapRustcWith: fix linking with libgcc_s with llvm #330037
Conversation
RossComputerGuy
requested review from
zowoq,
winterqt and
figsoda
as code owners
RossComputerGuy
force-pushed
the
fix/pkgsllvm/rustc-wrapper
branch
5 times, most recently
from
b1d7c36 to
751864f
Compare
RossComputerGuy
force-pushed
the
fix/pkgsllvm/rustc-wrapper
branch
from
751864f to
e99b72c
Compare
RossComputerGuy
force-pushed
the
fix/pkgsllvm/rustc-wrapper
branch
from
e99b72c to
02551bf
Compare
|
rusti-cal builds, mesa which this is mainly needed for doesn't build until the deps are fixed. |
| @@ -26,4 +26,5 @@ if (( "${NIX_DEBUG:-0}" >= 1 )); then | |||
| printf " %q\n" "${extraAfter[@]}" >&2 | |||
| fi | |||
|
|
|||
| export NIX_LDFLAGS="@ldflags@ $NIX_LDFLAGS" | |||
There was a problem hiding this comment.
NIX_LDFLAGS_@suffixSalt@ is sometimes used for cross compiling, but it's not clear to me if we need it here.
There was a problem hiding this comment.
Yeah, I can't tell either. Maybe it'll be good to check how CC wrapper works and see if this could affect cross compiled LLVM Rust packages and if it does then add the suffix?
There was a problem hiding this comment.
@Ericson2314 probably knows. But not sure if his GitHub feed is too swamped as well.
There was a problem hiding this comment.
Is this a blocker or can it be resolved later?
There was a problem hiding this comment.
Not if nix-build -A tests.rust-hooks still succeeds.
wegank
added
the
2.status: merge conflict
RossComputerGuy
force-pushed
the
fix/pkgsllvm/rustc-wrapper
branch
2 times, most recently
from
4ad8701 to
38a1443
Compare
RossComputerGuy
removed
the
2.status: merge conflict
RossComputerGuy
force-pushed
the
fix/pkgsllvm/rustc-wrapper
branch
2 times, most recently
from
6cd78d3 to
195ebac
Compare
RossComputerGuy
force-pushed
the
fix/pkgsllvm/rustc-wrapper
branch
from
195ebac to
20ff4c0
Compare
| runCommand "libunwind-libgcc" { } '' | ||
| mkdir -p $out/lib | ||
| ln -s ${rustc-unwrapped.llvmPackages.libunwind}/lib/libunwind.so $out/lib/libgcc_s.so | ||
| ln -s ${rustc-unwrapped.llvmPackages.libunwind}/lib/libunwind.so $out/lib/libgcc_s.so.1 |
There was a problem hiding this comment.
This looks extremely weird. I think we need a much better explanation of why this is the right fix, if indeed it is.
There was a problem hiding this comment.
I don't fully remember why but I know it's the same reason as why we need https://github.com/NixOS/nixpkgs/blob/nixos-24.11/pkgs/development/compilers/rust/rustc.nix#L350-L358
There was a problem hiding this comment.
The URL in that comment is broken.
There was a problem hiding this comment.
It opens up correctly for me, not sure how it's broken.
There was a problem hiding this comment.
https://github.com/gentoo/gentoo/blob/master/dev-lang/rust/rust-1.78.0.ebuild#L284 is 404 page not found. Seems like it's critical to understanding what's going on here — would you mind updating it to an exact commit hash rather than "master" so it won't rot?
There was a problem hiding this comment.
Looks like it might be setting a specific flag at compile time?
Shouldn't we be using that instead then?
We should, I remember trying it before and it didn't work.
I think using musl is just as much of a hack as symlinking stuff is.
If Musl is the intended target for non-GNU userlands -- as the Rust developer above said -- I'm not sure how that even approaches renaming a library to pretend to be another one. These are not ABI compatible, and if rustc is requesting them, I'd imagine it probably has a reason to and this could easily lead to breakages when the library is actually used and not just linked. If it doesn't have a reason to, this is most definitely an upstream bug or an issue with our configuration...and I'm leaning towards it being latter since AFAICT, literally no other distribution uses this method, including the one we originally sourced this hack from
The other "option" is waiting for LLVM to land the LLVM ABI but that implies the LLVM libc.
There was a problem hiding this comment.
It looks like no matter what flags I set, I cannot get rustc to compile like it does on Gentoo. We might have to live with the stupid symlink hack.
There was a problem hiding this comment.
Gentoo dropped it in gentoo/gentoo@349e9c0…
There was a problem hiding this comment.
it seems a solution may be to actually target the musl abi instead of GNU -- as said rust-lang/rust#119504 (comment)
This sort of "just works" now with pkgsLLVM.pkgsMusl. Opened #379632
There was a problem hiding this comment.
I think the best way forward here would be to ask the author of the Gentoo change how come they were able to drop the hack.
RossComputerGuy
force-pushed
the
fix/pkgsllvm/rustc-wrapper
branch
from
20ff4c0 to
d8bd0ae
Compare
|
Good to merge if |
|
You need to rebase onto #379269 |
Description of changes
Follow up to #320432
This is necessary to get some rust packages building with LLVM, notably mesa.
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.