Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

meson: Fix my mistakes #86283

Merged
merged 2 commits into from Apr 29, 2020
Merged

meson: Fix my mistakes #86283

merged 2 commits into from Apr 29, 2020

Conversation

Ericson2314
Copy link
Member

Motivation for this change

Fixes #86229 and something that @matthewbauer noticed.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

The old `CC=.. CXX= .. meson ...` env var hack I removed in
3c00ca0 had a side effect of ensuring
that Meson always had access to a native C compiler, which unforunately
it expects in most cases. Thankfully, that will be fixed soon.
In my haste to unbreak eval, I screwed up and got the bit-widths,
backwards.
@@ -58,6 +59,10 @@ python3Packages.buildPythonApplication rec {

setupHook = ./setup-hook.sh;

# Ensure there will always be a native C compiler when meson is used, as a
# workaround until https://github.com/mesonbuild/meson/pull/6512 lands.
depsHostHostPropagated = [ pkgsHostHost.stdenv.cc ];
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Something tells me this is the first depsHostHostPropagated 😂

@samueldr
Copy link
Member

samueldr commented Jun 5, 2020

I have bisected an issue with systemd's cross-compilation to this PR.

Since 05d26ad, nix-build -A pkgsCross.aarch64-multiplatform.systemd fails with the following:

...
Option prefix is: /nix/store/0rjxdagi2y3crgf8a5n809zhwy5gwxrz-systemd-245.3-aarch64-unknown-linux-gnu [default: /usr]
Found ninja-1.10.0 at /nix/store/2cjrhrq96f4bb20yywnd4zgbqv87g21m-ninja-1.10.0/bin/ninja
Using 'STRIP' from environment with value: 'aarch64-unknown-linux-gnu-strip'
Using 'STRIP' from environment with value: 'aarch64-unknown-linux-gnu-strip'
building
build flags: -j12 -l12
[602/1257] Generating stub.so with a custom commandstemd_userdb-glue.c.o'.o'K[Kn-gperf.c.o'[KKo'o'
FAILED: src/boot/efi/stub.so
/nix/store/41vfz2mi98j2wkgqx6ggj71bl314f604-gcc-wrapper-9.3.0/bin/ld -o src/boot/efi/stub.so -T /nix/store/zp7a35566pc4vvq3rfnzm8f3xzadd2vk-gnu-efi-3.0.11-aarch64-unknown-linux-gnu/lib/elf_aarch64_efi.lds -shared -Bsymbolic -nostdlib -znocombreloc -L /nix/store/zp7a35566pc4vvq3rfnzm8f3xzadd2vk-gnu-efi-3.0.11-aarch64-unknown-linux-gnu/lib /nix/store/zp7a35566pc4vvq3rfnzm8f3xzadd2vk-gnu-efi-3.0.11-aarch64-unknown-linux-gnu/lib/crt0-efi-aarch64.o --defsym=EFI_SUBSYSTEM=0xa src/boot/efi/disk.c.o src/boot/efi/graphics.c.o src/boot/efi/measure.c.o src/boot/efi/pe.c.o src/boot/efi/util.c.o src/boot/efi/linux.c.o src/boot/efi/splash.c.o src/boot/efi/stub.c.o -lefi -lgnuefi /nix/store/jj72ah48qnr2qx8bawd62wj3s9fcfndm-aarch64-unknown-linux-gnu-stage-final-gcc-debug-9.3.0/lib/gcc/aarch64-unknown-linux-gnu/9.3.0/libgcc.a
/nix/store/bfi8cjnhmqs8nd79ryr9n23myvlwhc4l-binutils-2.34/bin/ld: cannot represent machine `aarch64'
[613/1257] Generating boot.c.o with a custom commandwn-core@sta/nspawn-oci.c.o'.o'
ninja: build stopped: subcommand failed.
builder for '/nix/store/fwzs1q8qvfjz43lmiaxs3addxls6rxx3-systemd-245.3-aarch64-unknown-linux-gnu.drv' failed with exit code 1

https://gist.github.com/da2b61d3f18656acf5a94a7f3193ceeb

With the important bit being cannot represent machine `aarch64'


With that said, this may not be the PR that introduced the actual regression, but only the PR that made it fail in this particular exact way. The cause may be deeper, and introduced whenever the issue that caused #86229 was introduced (introduced in 9073a0c). Bisecting this does not look trivial.

Any idea?

The failure seems related to GNU EFI, as this allows the build to complete:

diff --git a/pkgs/os-specific/linux/systemd/default.nix b/pkgs/os-specific/linux/systemd/default.nix
index 00a545ed3f5..7f9d9e7f3ad 100644
--- a/pkgs/os-specific/linux/systemd/default.nix
+++ b/pkgs/os-specific/linux/systemd/default.nix
@@ -141,7 +141,7 @@ in stdenv.mkDerivation {
     "-Dsystem-gid-max=999"
     # "-Dtime-epoch=1"
 
-    (if !stdenv.hostPlatform.isEfi then "-Dgnu-efi=false" else "-Dgnu-efi=true")
+    (if /*!stdenv.hostPlatform.isEfi*/ true then "-Dgnu-efi=false" else "-Dgnu-efi=true")
     "-Defi-libdir=${toString gnu-efi}/lib"
     "-Defi-includedir=${toString gnu-efi}/include/efi"
     "-Defi-ldsdir=${toString gnu-efi}/lib"

@matthewbauer
Copy link
Member

/cc @Ericson2314

@Ericson2314
Copy link
Member Author

Ericson2314 commented Jun 8, 2020

I've since fixed the issue in a239864. I wouldn't be surprised if it was still user the wrong ld, but somehow successfully, before---FWIW I can't imagine how before this fix the build was passing "for the right reasons".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants