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

[Eric Christopher]

Cool deal. Thanks.

-eric

On Mon, Nov 11, 2013 at 12:13 PM, Bob Wilson <bob.wilson at apple.com> wrote:
> We will change ld64 to link with an rpath setting.  Once a version of ld64 has been around for a while and has been released publicly, we can change back to using an @rpath for libLTO.
>
> I've changed libLTO back to using @executable_path in svn r194418.
>
> On Nov 5, 2013, at 8:53 PM, Benjamin Scarlet <flld0 at greynode.net> wrote:
>
>> Will there ever be any better time for changing both ld64 and libLTO? If I understand right, the rationale so far leads to perpetual lock-in. Since the old install name which doesn't use rpath effectively locks out other users of the library (unless they put their binaries in with the installed llvm binaries), I do think reverting the patch is less than ideal as far as LLVM is concerned.
>>
>> I seem to recall that last I looked at libLTO, it seemed rather narrowly targeted at the particular design of ld64 - which would suggest there wouldn't be too many other users of the library - but I'm no expert on that area. If that's the case, then accepting the less-than-ideal choice for LLVM for the sake of ld64 doesn't seem too awful.
>>
>> -Ben Scarlet
>>
>> On Nov 5, 2013, at 9: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?
>>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits