enabling clients to use rpath to find LLVM shared libraries on OS X

Eric Christopher echristo at gmail.com
Tue Nov 5 18:55:54 PST 2013


On Tue, Nov 5, 2013 at 6:31 PM, Bob Wilson <bob.wilson at apple.com> wrote:

>
> On Nov 4, 2013, at 6:37 PM, Rafael EspĂ­ndola <rafael.espindola at gmail.com>
> wrote:
>
> > On 4 November 2013 18:27, Benjamin Scarlet <flld0 at greynode.net> wrote:
> >> I would have thought that the proper solution would be to link the
> linker with an appropriate rpath. After my change, responsibility for
> specifying the path to the library moves from the library to the executable
> - thus enabling it to be different for different executables. If the linker
> is to be rebuilt, it needs to have "-rpath @executable_path/../lib" or such
> passed to the linker when linking the new linker. (If the linker to link
> the new linker is invoked by a compiler driver like clang or gcc, then that
> probably means you need to put a "-Wl," before each of those flags to get
> them passed through to the linker, so "-Wl,-rpath
> -Wl, at executable_path/../lib".). There's an example of this on line 622 of
> the Makefile.rules in the root directory of the llvm source.
> >>
> >> To answer your direct question, I'm not using libLTO.dylib at all, so
> reverting my change there wouldn't directly cause me any trouble. I do
> think it'd be a step backward in general, though.
> >>
> >> Is the code for the linker that's using libLTO.dylib in the llvm tree
> somewhere I missed in in my patch, or is it outside the llvm tree?
> >
> > I think it is this one:
> >
> > http://www.opensource.apple.com/source/ld64/
>
> Right.  We could change ld64 to link with a -rpath option, but we don't
> publicly release new versions of ld64 very often.  It would be quite a
> while before anyone could get a copy of ld64 that works with trunk llvm.
>  It would also mean that you couldn't freely mix and match old and new
> versions of ld64 vs. llvm.  If there's a good reason to make that change, I
> think we can do it, but I'm not convinced it is worth the trouble.
>
> Does anyone object if we keep most of Benjamin's patch and revert just the
> part for libLTO.dylib?
>

No objection, I mean, it's better if you start using rpath with ld64 etc,
but it's also nice if darwin works so... :)

-eric


> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131105/ebaec656/attachment.html>


More information about the llvm-commits mailing list