Change:
glib-compile-schemas $out/share/glib-2.0/schemas ''; <del> postFixup = '' # Patched meson does not add internal libraries to rpath patchelf --set-rpath "$out/lib/gnome-shell:$(patchelf --print-rpath $out/bin/.gnome-shell-wrapped)" $out/bin/.gnome-shell-wrapped ''; </del> enableParallelBuilding = true; passthru = {

Discussion:
Dejà dup requires a custom library in but meson, for some reason, adds to the : If I remove the , the path to the custom library is in but then we do not have the global ones: System: (Impala) Nix version: 1.11.15 Nixpkgs version: Sandboxing enabled: true
I found where those X’s come from. Could we maybe do something like this instead?
Or even better, skip the X nonsense:
As I understand it, the whole X business is to ensure the is not contaminated with the but I do not see what harm it could do – on Nix, the will not exist in the file system (nix store) yet, and for other systems, even if they were there (if this was upstreamed, we can expect paths like ) the paths will precede the .
Thanks for explaining, makes sense. Your patch is way better than mine, and I've completely overlooked rpath templating (I shouldn't have: I've wondered why upstream version of works at all, considering it only works ).
I asked about the patch in the meson issue
The problem with this patch is that it will pollute the when Nix-installed meson is used outside . We would need to strip the rpath on install inside meson.
Does that mean that is the right way to go?
What we actually want is a hybrid of the two variants: this patch plus in . Edit: We might not need the strip prevention, since we would only be making the rpath shorter.
In that case I think that just replacing class with our version would be easier to maintain. Does this hybrid approach have practical advantages over class in ?
Well our class from also does not strip the rpath so the effect is the same as for the patch above (modulo the screw ups preventing stripping). We would need something like: We could add the stripping to the class but the repeated calls would increase the probability of screw up.
Weird, the epiphany no longer finds , even though we are patching the rpath and according to it contains .
The issue is that is not loadable. You can see it with . prints .
The epiphany issue was fixed in .
As I understand it, the whole issue springs from two different requirements: Development – we need to run the program from the build directory.

Packaging – we need to run the program from Nix store. For third-party libraries this is fairly straight-forward – we add their locations to the rpath (or link them using absolute path on Darwin) and it will work in both scenarios. Once we want to link against an internal library, however, it will get ugly. If we do not want to fiddle with environment variables, we will need to use absolute paths for linking. Unfortunately, the package is built in a different location than it is installed to, so we do not have a single path to use. Instead, we could use origin-relative paths ( in figure A) but for most packages, the directory structure of the installed package will be different ( in figure B1 or even in figure B2), making it as useless as absolute paths. Obviously, a single path is not enough – we will need to add both paths to . To prevent contamination, we need to replace the dev paths for the packaging ones during during installation. <table<tr<tdFigure A </td<tdFigure B1 </td<tdFigure B2 </td</tr</tableThis is actually, what meson does except it removes too much – the whole gets nuked instead of just the development paths to the internal libraries. On the other hand, our removes too little – it does not remove anything at all – and on top of that, it prevents adding the local libraries to . The ideal patch would remove only the development links and insert the as vanilla meson does. Are absolute paths a good enough indication of non-development path to be kept? P.S.: On Darwin, there is something similar with s which they use in place of (see ).
Here is another draft based on the previous comment: But apparently Meson is not aware of libraries to rpath: Where do they come from? Edit: Apparently from .