[lld] r247475 - Implement -rpath.

[Ed Maste via llvm-commits]

On 11 September 2015 at 18:54, Hal Finkel via llvm-commits
<llvm-commits at lists.llvm.org> wrote:
> ----- Original Message -----
>> From: "Joerg Sonnenberger via llvm-commits" <llvm-commits at lists.llvm.org>
>> To: "Rafael Espindola" <rafael.espindola at gmail.com>
>> Cc: llvm-commits at lists.llvm.org
>> Sent: Friday, September 11, 2015 5:26:44 PM
>> Subject: Re: [lld] r247475 - Implement -rpath.
>>
>> On Fri, Sep 11, 2015 at 09:18:57PM -0000, Rafael Espindola via
>> llvm-commits wrote:
>> > URL: http://llvm.org/viewvc/llvm-project?rev=247475&view=rev
>> > Log:
>> > Implement -rpath.
>>
>> Should we really unconditionally generate RUNPATH? IMO that's a bug
>> created by GNU for the semi-broken behavior of glibc's dynamic
>> linker.
>> This is certainly going to create problems at least for NetBSD.
>
> What behavior do you want here?
>
> We seem to have three choices:
>
>  1. Generate only DT_RPATH
>
>     At least on Linux, this overrides LD_LIBRARY_PATH
>
>  2. Generate only DT_RUNPATH
>
>     At least on Linux, this is searched after LD_LIBRARY_PATH
>
>  3. Generate both DT_RPATH and DT_RUNPATH
>
>     This is the behavior of GNU ld when -enable-new-dtags is provided, and because (at least on Linux), DT_RPATH is ignored when DT_RUNPATH is present, is equivalent to just generating DT_RUNPATH (except on pre-1999 systems which don't understand DT_RUNPATH).
>
> In my experience, the fact that DT_RPATH overrides LD_LIBRARY_PATH is often quite inconvenient. Furthermore, as I understand it, problems with LD_LIBRARY_PATH being overridden by DT_RPATH provided the motivation for DT_RUNPATH in the first place. I can, however, see making a security argument for using DT_RPATH instead of DT_RUNPATH in limited circumstances. However, at least on Linux, use of DT_RPATH is deprecated.
>
> Does the *BSD behavior differ here?

FreeBSD added DT_RUNPATH in July 2012, and all releases supported by
the security team include support, but it hasn't yet been long enough
that there won't be older FreeBSD systems still in operation. Those
older systems will likely compile applications with older tools
though, and so it will likely not matter what LLD choses here.

I agree that the documented DT_RPATH behaviour is silly, and so option
1 above isn't viable. Option 2 doesn't work on NetBSD today.

I suppose there's another option:

4. Generate DT_RUNPATH on systems that support it, else generate DT_RPATH.

although I don't really like that sort of target-dependent difference.