@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:

• build using dummy rpath that's "surely" long enough
• afterwards "blindly" replace dummy path with actual path, which is "known to be safe" since dummy was long enough.

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:
#44040

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 nixos.tests.login sucessfully. nixos.tests.systemd fails one of two tests, not sure if it's related though.

Doing this produces identical results, where nixpkgs.systemd is from master and ~/nixpkgs is the gnome branch with the meson update:

diff <(readelf -d $(nix eval nixpkgs.systemd --raw)/lib/libnss_resolve.so.2) \
     <(readelf -d $(nix eval -f ~/nixpkgs systemd --raw)/lib/libnss_resolve.so.2)

@dtzWill any tips on how to check if the rpath is wrong?

It looks like ./gir-fallback-path.patch is no longer needed?

$ 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:

NixOS's extraUtils fails with this due to reference that's not allowed-- at first I feared this was the same problem as before (since the symptom is the same as when we were corrupting things re:meson), but I think it's unrelated :). Regardless I suspect you're running into this and if you haven't you probably will (or have fixed it and I'm on wrong branch :D).

In short the fix is adding -Dlink-udev-shared=false to systemd's mesonFlags. I didn't chase down why it suddenly started happening, but I can say I noticed in past few months various other distributions making changes regarding this so perhaps it's due to a meson upgrade they did before us :).

The harder fix, and untested, is that the extraUtils find-libs-and-copy-and-patchelf stuff is both too complicated and in particular fails to account for transitive dependencies (libraries that need other libraries). Well "fails" may be incorrect, this is possibly a feature and some would argue a case of underlinking but all I mean is this wouldn't happen if the xz dep was pulled in and patched to be used.

I think the solution proposed (meson flags) is the best as it prevents general systemd deps (== take over the world) from being pulled into our early boot process. We may want to do the same for systemctl (similar option) but that's not necessary so I'll leave that for another time.

Anyway thanks for your work, hope this helps, LMK if you have any questions or whatnot :).

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

I still cannot reproduce this failure when trying to build the following expression:

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.

The current solution already should not leave any partial references since it replaces the whole length of the RPATH entry with NULL bytes before writing the new_rpath. Keeping the trailing part of old_rpath will not help with the potential Xorg issue because it will most definitely be stripped (the paths at the end are the ones added by ld-wrapper). I do not see how is the proposed solution any better than the current one.

Yeah, you're probably right. We're most likely already violating the assumptions made by meson when we're moving the stuff added by ld-wrapper to the start. So I don't really have any problems with going with the current solution. Just saw that you've already pushed the fix to the the gnome branch 👍

I cannot reproduce the issue at the moment.

Based on #45950 (comment), our gir-fallback-path.patch is apparently still needed. The old patch is not really trivially portable, since our --fallback-library-path hack does not expect multiple libraries that are now supported.

Re-added the patch.

FYI: I also ran into the is not allowed to refer to error previously. I'm unable to reproduce the issue with the latest commits.

(from irc) @jtojnar > hedning_: I am suspicious because you said you reproduce it after I pushed the current fix

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.