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

[Bob Wilson]

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?