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

[Benjamin Scarlet]

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?

-Ben Scarlet

On Nov 4, 2013, at 7:38 PM, Bob Wilson <bob.wilson at apple.com> wrote:

> Benjamin,
> 
> Your patch to use @rpath for various llvm dylibs on OS X, which Eric applied in svn r187641, is breaking LTO builds with Apple's linker. You won't see the problem unless you rebuild the linker with the @rpath-version of libLTO.dylib installed. But, if you do rebuild the linker, the linker will look for libLTO.dylib via the rpath instead of relative to itself, and since there is no rpath set up, the library cannot be found.
> 
> I'm not sure how to resolve this.  Obviously the simplest solution would be to revert your change, at least for libLTO.dylib.  Are you using libLTO.dylib for something that requires it to have the @rpath set?
> 
> --Bob