oh yea, stdenv.cc.cc, guess you will need stdenv :(. Good atempt though :)

you could try to do ORIGIN=$(patch-elf --print-rpath $file); patch-elf --set-rpath "libPath:$ORIGIN" $file but that's kind of ugly, but it would prevent you from destroying the default patching.

oh yea, stdenv.cc.cc, guess you will need stdenv :(. Good atempt though :)

you could try to do ORIGIN=$(patch-elf --print-rpath $file); patch-elf --set-rpath "libPath:$ORIGIN" $file but that's kind of ugly, but it would prevent you from destroying the default patching.

Not sure if I'm reading this correctly, but it doesn't seem to work

diff --git a/pkgs/development/web/postman/default.nix b/pkgs/development/web/postman/default.nix
index b56cdf6c811..15038bdfbc7 100644
--- a/pkgs/development/web/postman/default.nix
+++ b/pkgs/development/web/postman/default.nix
@@ -84,7 +84,7 @@ stdenv.mkDerivation rec {
     patchelf --set-interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)" _Postman
 
     for file in $(find . -type f \( -name \*.node -o -name _Postman -o -name \*.so\* \) ); do
-      patchelf --set-rpath ${libPath}:$out/share/postman $file || true
+      ORIGIN=$(patchelf --print-rpath $file); patchelf --set-rpath "libPath:$ORIGIN" $file || true
     done
     popd
   '';

./result/bin/postman: error while loading shared libraries: libgtk-3.so.0: cannot open shared object file: No such file or directory

Furthermore, is breaking the default patching even a concern with binary packages like this?

./result/bin/postman: error while loading shared libraries: libgtk-3.so.0: cannot open shared object file: No such file or directory

I'm not sure given the information, you can use ldd on a .so or elf to see where it did or didn't a given link. You may want to try dontPatchELF = true;, this will prevent the default phases from trying to reset rpath.

Furthermore, is breaking the default patching even a concern with binary packages like this?

I find that most pre-built binaries are usually patched in this way :(.

Ah. I think I just mistyped some things in my initial attempt based on your suggestions.
Had to move the makeLibraryPath to postFixup rather than preFixup, but everything seems to work now.

Anything else I can do to get this merged?

I have squashed the commits and moved the addition of myself to the list of maintainers (wait, do we need to do this per package or just for top-level maintainers?)
I also bumped the package to 7.6.0.
The application seems to still work fine.

@jonringer Any other thoughts before this gets merged?

You need to add various libs to buildInputs for the application to be properly wrapped.
Else, when you launch a file chooser within the app, it will crash with " No GSettings schemas are installed on the system". Note that's in pure environments.

Perhaps add libPath to buildInputs.

Moving everything into buildInputs and constructing libPath off of that was one method I found worked well.
I wasn't sure how to otherwise add libPath to buildInputs without duplicating dependency references.

When attempting to remove libPath and utilize autoPatchelfHook, I get no abnormal build output, but the application dumps core before launching.

@worldofpeace Given the strange behavior when I try to use autoPatchelfHook and so on, do you have any thoughts on how the expression looks right now?

@worldofpeace Thank you! This feels a lot less messy.
Is commit cleaning all that's left, now? (e.g. one for adding me to postman maintainers, one for the package updates)

@worldofpeace Thank you! This feels a lot less messy.
Is commit cleaning all that's left, now? (e.g. one for adding me to postman maintainers, one for the package updates)

Yep, you can cleanup the git history and I'll merge 👍