meson: 0.46.1 → 0.48.2 #46020
meson: 0.46.1 → 0.48.2 #46020
Conversation
@dtzWill I ran a GNOME session built with this and did not experience any problems. Tests are passing too. What issues did you encounter again? |
We patch(ed?) meson to change how it writes RPATH, which caused particularly painful (and not immediately obvious) results since apparently it works like this:
It's a hack in the first place but we managed to very much break things by replacing paths of length ~30 ("dummy") with ones very much longer (> 200) which of course often resulted in invalid rpath searching but especially bad since those extra 170 chars or whatever overwrote whatever followed, which uhh hopefully wasn't important or something ;). Bit more details here, although I was a bit battle-weary so didn't explain it very well: As I recall, all the relevant parts of meson are the ones we already touch with our patches. I think. :). |
In particular, everything was broken: #44040 (comment) But it'd be good to ensure we're not generating corrupt binaries or at least be somewhat confident that's unlikely to happen.... |
We have a testing ground for meson now #45950, https://hydra.nixos.org/jobset/nixpkgs/gnome Seems like things are working better than last time at least, I'm eg. able to run Doing this produces identical results, where nixpkgs.systemd is from master and ~/nixpkgs is the gnome branch with the meson update:
@dtzWill any tips on how to check if the rpath is wrong? |
It looks like $ rg shared-library $(nix-build -A atk.dev)/share/gir-1.0/Atk-1.0.gir
14: shared-library="/nix/store/iiamyk9c1j8bzlxrf3lbz9g45xb8zlgd-atk-2.30.0/lib/libatk-1.0.so.0"
$ rg shared-library $(nix-build -A gst_all_1.gstreamer.dev)/share/gir-1.0/Gst-1.0.gir
16: shared-library="/nix/store/drpcbmhq0znjn86k1xzij947kb247hr1-gstreamer-1.14.2/lib/libgstreamer-1.0.so.0"
$ rg shared-library $(nix-build -A gst_all_1.gstreamer.dev)/share/gir-1.0/Gst-1.0.gir
16: shared-library="/nix/store/drpcbmhq0znjn86k1xzij947kb247hr1-gstreamer-1.14.2/lib/libgstreamer-1.0.so.0" |
@dtzWill at #45950 (comment) wrote:
I still cannot reproduce this failure when trying to build the following expression: {pkgs ? import <nixpkgs> {} }:
let
config.boot.loader.supportsInitrdSecrets = false;
config.boot.isContainer = false;
config.boot.initrd.secrets = {};
config.boot.initrd.extraUtilsCommands = "";
config.boot.initrd.extraUtilsCommandsTest = "";
config.system.build.fileSystems = [];
config.systemd.package = pkgs.systemd;
inherit (pkgs) lib;
utils = import <nixpkgs/nixos/lib/utils.nix> pkgs;
stage-1 = import <nixpkgs/nixos/modules/system/boot/stage-1.nix> { inherit pkgs lib utils config; };
in stage-1.config.content.system.build.extraUtils |
Using that expression fails for me building against the gnome PR (where I commented) and when setting NIX_PATH appropriately, I'll try it against this PR shortly. |
Yeah, you're probably right. We're most likely already violating the assumptions made by meson when we're moving the stuff added by |
I cannot reproduce the issue at the moment. |
Based on #45950 (comment), our |
Re-added the patch. |
Meson no longer propagates it so we need to re-add it.
Meson no longer propagates it so we need to re-add it.
Meson no longer propagates it so we need to re-add it.
Meson no longer propagates it so we need to re-add it.
Meson no longer propagates it so we need to re-add it.
Meson no longer propagates it so we need to re-add it.
Meson no longer propagates it so we need to re-add it.
FYI: I also ran into the |
Ah, sorry for the confusion, I should've made it clear that I was talking about the branch without the clear old_rpath fix. I was working under the assumption that the fix wasn't safe, but when reading #46020 (comment) again I can see I didn't specify that at all :( |
Let's merge this and see what happens. |
85bd2a7
into
NixOS:staging
Motivation for this change
Things done
sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)nix path-info -S
before and after)