<div dir="ltr">Going a bit out of order, I think there are three things going on here:<div><br></div><div>1. My patch in nixpkgs: I think you're incorrect there; my patch isn't just for LLVM 3.5; you'll see that nixpkgs has packages for LLVM (3.4) 3.5, 3.7, 3.8, 3.9, 4, and 5, and I patch each of them slightly differently to disable rpath there. Each of them involves some on-the-fly patching of CMake files but they're in different places and work differently each time.</div><div><br></div><div>2. My motivation: we package a ton of FOSS libraries for macOS in nixpkgs and I recently made a change to avoid jumping through hoops to support rpaths, because the only library I've found in our packages that goes out of its way to enable rpaths (relocatable libraries are less relevant in the Nix world) is LLVM. The basic point is that using rpath in a library imposes a burden on any consumer of the library (to pass -rpath into the linker invocation of the final executable, which is probably more painful in nix than elsewhere because LLVM lives in its own folder rather than somewhere global like /usr/lib)</div><div><br></div><div>3. The background for rpath usage in LLVM: fully admit that I'm probably wrong here. I guess rpaths are much more common in graphical apps on macOS which I admittedly don't build very often, and it took me a long time to figure out the chain of commits and underlying motivations for using rpath as the explicit install name of the dylib, so I probably missed key steps there.</div><div><br></div><div>Given #2, it seems like we'd be best served by just creating a CMake boolean flag for "use rpaths" or something like that. I'd set it to false and everyone else would use the current value for it. I'd be happy to submit such a patch if what I'm saying sounds reasonable.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 9, 2017 at 1:48 PM, Chris Bieneman <span dir="ltr"><<a href="mailto:beanz@apple.com" target="_blank">beanz@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Can you please describe the actual problem you're trying to fix?<div><br></div><div>Many of the things you link to seem a bit disjointed to me because it is people experiencing different problems that aren't as related as you might think.</div><div><br></div><div>More comments inline below.</div><div><br><div><span class=""><blockquote type="cite"><div>On Oct 9, 2017, at 7:24 AM, Daniel Peebles via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="m_449805431456600255Apple-interchange-newline"><div><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.</div></div></div></blockquote><div><br></div></span><div>I very much disagree. I think rpaths are very common on Darwin platforms. We see them all over the place.</div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div> 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></div></blockquote><div><br></div></span><div>The chain of switching back and forth between @rpath and @executable_path pretty clearly illustrates that we *had* a problem with how we are setting the rpaths, not what the problem is. The reason I say *had* is because you left off one really important commit on the chain:</div><div><br></div><div><a href="https://github.com/llvm-mirror/llvm/commit/3a876bdaec4dd8e43d21e0ce369f17db274431c0" target="_blank">https://github.com/llvm-<wbr>mirror/llvm/commit/<wbr>3a876bdaec4dd8e43d21e0ce369f17<wbr>db274431c0</a></div><div><br></div><div>That patch I deleted all the code that sets the CMAKE_* global variables, and instead we set up rpaths on a per-library basis. I also moved to @loader_path, which is a more modern version of @executable_path.</div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><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></div></blockquote><div><br></div></span><div>I don't believe this comment is so much about setting the rpath, but rather the silly mechanism that we used in CMake to do it. I believe this has been settled since then.</div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><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></div></blockquote><div><br></div></span><div>The problem here is that libc++ is linking libcxxabi via @rpath instead of @loader_path. Also there are some historical differences between the way the Darwin build is done and the other build platforms. I believe that libcxx re-exporting libcxxabi is something we haven't historically done on Darwin, but I could be mis-remembering that.</div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><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></div></blockquote><div><br></div></span><div>This patch won't do anything against LLVM trunk and seems to be applying to LLVM 3.5. If you're looking for us to fix this on an old LLVM release, I don't expect you'll get much traction.</div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><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></div></blockquote><div><br></div></span><div>libLLVM must be relocatable for many of our use cases. If it is a problem for you, we can certainly consider an option to disable that, although I'm more curious what the actual problem is. Creating a relocatable library shouldn't be causing downstream problems.</div><div><br></div><div>-Chris</div><br><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>Thanks,</div><div>Dan</div></div>
______________________________<wbr>_________________<br>LLVM Developers mailing list<br><a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br></div></blockquote></div><br></div></div></blockquote></div><br></div>