Get rid of most @rpath nonsense on Darwin

[copumpkin]

This requires some small changes in the stdenv, then working around the weird choice LLVM made to hardcode @rpath in its install name, and then lets us remove a ton of annoying workaround hacks in many of our Go packages. With any luck this will mean less hackery going forward.

Motivation for this change

I got sick of seeing people getting weird rpath-related errors when packaging Go programs.

Fixes #18131

@acowley this should fix the Go issue you encountered earlier today

Things left to do

• Test some other stuff that depends on LLVM (e.g., rustc) to make sure it still runs now that I took out the rpath install name in libLLVM. I expect it to but it might have an extraneous rpath load command or two in it.
• Remove rpath crap from other LLVM versions too, since they'll probably break without the stdenv support
• Rebase onto staging because this is a mass rebuild. I forgot to work off staging and was too lazy to switch over and wait another couple of hours for everything to build again
• Make sure I didn't break anything on Linux (but I'm pretty sure I didn't)

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
• Built on platform(s)
  • NixOS
  • macOS
  • Linux
• 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 nox --run "nox-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Fits CONTRIBUTING.md.

---

[orivej]

Do you know why the problem of rpaths causing cyclic references between Go outputs does not exist on Linux?

[dezgeg]

Because of the patchelf --shrink-rpath stdenv does.

[copumpkin]

Yeah, we could have replicated that, but given that the rpaths are almost entirely unnecessary on macOS, I'd rather just scrap them altogether than replicate the more complicated solution on a platform that doesn't need it.

[dezgeg]

How does dynamic library linkage work on darwin in general? (Just asking, I'm curious.) Do the binaries contain absolute paths to the .dylib files? If so, why does the concept of RPATH exist in the file format in the first place?

[orivej]

Do the binaries contain absolute paths to the .dylib files?

Yes, and the libraries contain absolute paths to themselves, so that when programs (and other libraries) are linked to a library, they refer to it by its builtin absolute path.

Linux ld loader also supports loading libraries by an absolute path (this is documented in ld.so(8)), but AFAIK ld linker can't write them.

[copumpkin]

What @orivej said, but to answer your "why" question, it's to support relocateable libraries. We often distribute .app "files" that are basically bundles of dependencies in a folder, and in those cases you don't want your dependencies to expect to be in any particular place.

So basically, you can add @rpath as a special element to a library's self-reported path (which ends up the thing that anyone depending on that library refers to) and then the loader will search any relevant rpath entries in the executable being loaded for that lib. There's also a couple of other special cases like @executable_path and @loader_path, which refer to the top-level binary being loaded and the specific binary making the reference, respectively.

[Ericson2314]

Looks great! Hope to do the same thing on Linux too, someday.

[LnL7]

I think the rpath flags for CoreFoundation are only added when this is not set. It probably should be moved outside of the conditional.

[copumpkin]

Hmm, sorry, I don't understand. Where is the CF rpath code?

[LnL7]

https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/cc-wrapper/ld-wrapper.sh#L145-L147

[copumpkin]

@Ericson2314 if you want it on Linux, is there a ticket for that? I'd be curious to hear some discussion of what's involved and see what the community thinks of it

[Ericson2314]

There's #24844

[copumpkin]

Thanks!

[orivej]

I'm going to pick this into release (via staging-17.09) to ease the porting of Go packages to release-17.09. (Otherwise some of them encounter the "cycle detected" error.)

[orivej]

Released in cfc55fe.

[copumpkin]

Cool, thanks @orivej