mesa: fix cross compilation to x86_64 #233628
Conversation
alyssais
added
6.topic: rust
6.topic: cross-compilation
alyssais
requested review from
jtojnar,
mmahut,
RaghavSood,
zowoq,
winterqt,
figsoda,
Mic92,
Ericson2314 and
matthewbauer
as code owners
github-actions
bot
added
6.topic: GNOME
This comment was marked as resolved.
This comment was marked as resolved.
|
@ofborg eval |
alyssais
force-pushed
the
mesa-cross
branch
2 times, most recently
from
c58048e
to
5f13c40
Compare
This comment was marked as outdated.
This comment was marked as outdated.
alyssais
force-pushed
the
mesa-cross
branch
3 times, most recently
from
5762742
to
c0d3cbb
Compare
|
I've rebased to fix the merge conflict, and I've also:
All suggested by @Ericson2314. |
ghost
dismissed
their stale review
main issue fixed; will approve once builds complete
ghost
mentioned this pull request
We need this stuff to be available in lib so make-derivation.nix can access it to construct the Meson cross file. This has a couple of other advantages: - It makes Rust less special. Now figuring out what Rust calls a platform is the same as figuring out what Linux or QEMU call it. - We can unify the schema used to define Rust targets, and the schema used to access those values later. Just like you can set "config" or "system" in a platform definition, and then access those same keys on the elaborated platform, you can now set "rustcTarget" in your crossSystem, and then access "stdenv.hostPlatform.rustcTarget" in your code. "rustcTarget", "rustcTargetSpec", "cargoShortTarget", and "cargoEnvVarTarget" have the "rustc" and "cargo" prefixes because these are not exposed to code by the compiler, and are not standardized. The arch/os/etc. variables are all named to match the forms in the Rust target spec JSON. The new rust.target-family only takes a list, since we don't need to worry about backwards compatibility when that name is used. The old APIs are all still functional with no warning for now, so that it's possible for external code to use a single API on both 23.05 and 23.11. We can introduce the warnings once 23.05 is EOL, and make them hard errors when 23.11 is EOL.
In particular, fix cross compilation of rusticl.
|
I agree, this should be merged before the branch-off. However,
I think that ship has sailed 😆 unless |
|
The sphinx build failure on x86_64-linux seems to be intermittent / load-related. Let's try again: @ofborg build mesa mesa.passthru.tests stdenv stdenv.passthru.tests |
I've been getting (and I don't think it is caused by this PR) We should consider disabling the tests for the |
|
OfBorg hasn't given me the aarch64 builds for days, so I'm just going to merge. I've tested locally on x86_64-linux and aarch64-linux, and IIRC mesa is broken on Darwin anyway. In the unlikely event there are failures, we'll catch them in staging. |
|
Seems like this PR broke all packages that use |
|
Nevermind, I found #267876 which should fix this. |
|
Fix is #268168. |
Description of changes
In particular, fix cross compilation of rusticl. Previously, Nixpkgs has not been equipped to handle non-Cargo Rust cross compilation. That's getting increasingly important, now that we're building Mesa with Rust, and soon the kernel, and potentially systemd in not too long.
This is a bigger PR than I usually like to make, but it's difficult to explain each of these changes out of context, so I've bundled them into a single PR. I'd definitely recommend reviewing commit by commit though. The commit messages contain the details of each change.
Spiritual successor to #159064.
Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)