<div dir="ltr">Apologies, I appear to have pasted the same link twice in my original email. This is the actual commit that introduced the @rpath feature: <a href="https://github.com/llvm-mirror/llvm/commit/c94f3ae0278dc781cd60051790bf8a8003a13873">https://github.com/llvm-mirror/llvm/commit/c94f3ae0278dc781cd60051790bf8a8003a13873</a><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 9, 2017 at 10:24 AM, Daniel Peebles <span dir="ltr"><<a href="mailto:pumpkingod@gmail.com" target="_blank">pumpkingod@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>I'm trying to understand why LLVM uses @rpath as the install name in its dynamic libraries on macOS. This complicates the process of linking against libLLVM from third-party tools and isn't nearly as common a practice on macOS as it is on Linux. I tried tracing through history on the LLVM repo and the main thing I could find was a commit from ages ago saying that the libraries are now relocatable. While that's indeed true, rpaths put a burden on all consumers of the library (who now need to pass special flags to their linker) and unless there's a pressing need for them, most libraries avoid the practice. Indeed, the use of @rpath in LLVM seems to have been a bit confusing and has undergone dozens of changes over time, with reverts, changes to and from @executable_path (a related but different relative path inside the macOS loader), and so on.</div><div><br></div><div>Here's the commit that seemed to introduce it: <a href="https://github.com/llvm-mirror/llvm/commit/fb24ccfa32c12dc7ab12b70f2c3db404dbab7581" target="_blank">https://github.com/llvm-<wbr>mirror/llvm/commit/<wbr>fb24ccfa32c12dc7ab12b70f2c3db4<wbr>04dbab7581</a></div><div>Here's one of the reverts of the reverts: <a href="https://github.com/llvm-mirror/llvm/commit/fb24ccfa32c12dc7ab12b70f2c3db404dbab7581" target="_blank">https://github.com/<wbr>llvm-mirror/llvm/commit/<wbr>fb24ccfa32c12dc7ab12b70f2c3db4<wbr>04dbab7581</a></div><div>Here's the switch to @executable_path: <a href="https://github.com/llvm-mirror/llvm/commit/692c94c1c9b5642cecb8fc7b6fa5ce3145b70ff1" target="_blank">https://<wbr>github.com/llvm-mirror/llvm/<wbr>commit/<wbr>692c94c1c9b5642cecb8fc7b6fa5ce<wbr>3145b70ff1</a></div><div>Here it is switching back to @rpath: <a href="https://github.com/llvm-mirror/llvm/commit/37c04a0d4d0df0e2efddcc76a1036a9fc384e61a" target="_blank">https://github.com/<wbr>llvm-mirror/llvm/commit/<wbr>37c04a0d4d0df0e2efddcc76a1036a<wbr>9fc384e61a</a></div><div><br></div><div>And here's an unanswered question about why it's there in the first place: <a href="http://lists.llvm.org/pipermail/llvm-dev/2016-January/094463.html" target="_blank">http://lists.llvm.org/<wbr>pipermail/llvm-dev/2016-<wbr>January/094463.html</a></div><div>Along with a downstream issue that needed to work around it: <a href="https://github.com/Homebrew/legacy-homebrew/issues/47149" target="_blank">https://github.com/<wbr>Homebrew/legacy-homebrew/<wbr>issues/47149</a></div><div>And another downstream issue that outright patches out LLVM's @rpath support (authored by me): <a href="https://github.com/NixOS/nixpkgs/pull/30150" target="_blank">https://github.com/NixOS/<wbr>nixpkgs/pull/30150</a></div><div><br></div><div>Anyway, I'm curious what the use case is for a relocatable libLLVM.dylib at the cost of downstream confusion. If it is indeed essential, could it be made an option in the build so that those of us who don't need relocatable LLVM libraries don't need to hack at the build files to turn it off?</div><div><br></div><div>Thanks,</div><div>Dan</div></div>
</blockquote></div><br></div>