[lld] r247475 - Implement -rpath.

[Hal Finkel via llvm-commits]

----- Original Message -----
> From: "Ed Maste" <emaste at freebsd.org>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Joerg Sonnenberger" <joerg at britannica.bec.de>, "llvm-commits" <llvm-commits at lists.llvm.org>
> Sent: Sunday, September 13, 2015 9:11:22 AM
> Subject: Re: [lld] r247475 - Implement -rpath.
> 
> 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.

Just to confirm, generating both DT_RPATH and DT_RUNPATH is a reasonable option for NetBSD and older FreeBSD systems?

 -Hal

> 
> 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.
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory