[llvm-dev] LLVM's use of rpath on macOS

[Daniel Peebles via llvm-dev]

Apologies, I appear to have pasted the same link twice in my original
email. This is the actual commit that introduced the @rpath feature:
https://github.com/llvm-mirror/llvm/commit/c94f3ae0278dc781cd60051790bf8a8003a13873


On Mon, Oct 9, 2017 at 10:24 AM, Daniel Peebles <pumpkingod at gmail.com>
wrote:

> Hi all,
>
> 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.
>
> Here's the commit that seemed to introduce it: https://github.com/llvm-
> mirror/llvm/commit/fb24ccfa32c12dc7ab12b70f2c3db404dbab7581
> Here's one of the reverts of the reverts: https://github.com/
> llvm-mirror/llvm/commit/fb24ccfa32c12dc7ab12b70f2c3db404dbab7581
> Here's the switch to @executable_path: https://
> github.com/llvm-mirror/llvm/commit/692c94c1c9b5642cecb8fc7b6fa5ce
> 3145b70ff1
> Here it is switching back to @rpath: https://github.com/
> llvm-mirror/llvm/commit/37c04a0d4d0df0e2efddcc76a1036a9fc384e61a
>
> And here's an unanswered question about why it's there in the first place:
> http://lists.llvm.org/pipermail/llvm-dev/2016-January/094463.html
> Along with a downstream issue that needed to work around it:
> https://github.com/Homebrew/legacy-homebrew/issues/47149
> And another downstream issue that outright patches out LLVM's @rpath
> support (authored by me): https://github.com/NixOS/nixpkgs/pull/30150
>
> 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?
>
> Thanks,
> Dan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171009/7fc24570/attachment-0001.html>