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

[Daniel Peebles via llvm-dev]

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/692c94c1c9b5642cecb8fc7b6fa5ce3145b70ff1
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/5365f92f/attachment.html>