Re: [PATCH 2/2 v5] gold: enable new dtags by default

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Tue, Feb 19, 2013 at 10:15 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Tuesday 05 February 2013 00:43:04 Ian Lance Taylor wrote:
>> On Mon, Feb 4, 2013 at 5:44 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> > This caused:
>> >
>> > http://www.sourceware.org/bugzilla/show_bug.cgi?id=15098
>> >
>> > I changed BFD linker not set new dtags with -rpath.
>>
>> I don't see why that is the right fix.  Since DT_RPATH/DT_RUNPATH are
>> only ever set by the linker's -rpath option, it seems like the right
>> fix is to always use DT_RPATH and never use DT_RUNPATH.
>>
>> Of course, since the only thing --new-dtags does in gold is select
>> DT_RUNPATH rather than DT_RPATH, this makes new--dtags completely
>> useless in gold.
>>
>> It seems that we have made sensible-seeming decisions to wind up in an
>> absurd place.  It seems that we should now make --new-dtags a no-op
>> and drop all support for generating DT_RUNPATH.  Which makes me wonder
>> why DT_RUNPATH was invented in the first place.
>
> sorry, but my main comp hd died, so i've been offline for a while.  it seems
> that the current status is that the linker no longer defaults to --enable-new-
> dtags, but bfd still only specifies DT_RUNPATH if the flag is enabled (rather
> than using both).  is that correct ?
>
> DT_RUNPATH is preferable to DT_RPATH because the latter is searched *before*
> LD_LIBRARY_PATH which is bad.  most of the use cases i've seen with rpath fall
> into two categories:
>  - people want to generate libraries with a custom path to loadable plugins --
> DT_RUNPATH works great
>  - people want their application to search a local path for all of its libs --
> DT_RPATH works here w/$ORIGIN
>  - people want to install their shared libs into a non-searchable path and
> have their application use it -- DT_RUNPATH works here
>
> i've seen build cases where DT_RPATH actively causes problems when there is a
> version already installed.  they compile their local binary and its shared
> libs, then attempt to use LD_LIBRARY_PATH to force the binary to use the local
> libs.  unfortunately, the DT_RPATH kicks in and loads everything from /
> instead and it falls down.
>
> considering Gentoo has been defaulting to --enable-new-dtags since at least
> 2004 and i have yet to see a bug report related to it, i wonder what actually
> broke that caused you to notice this ?  and if it's a minor case, is a better
> answer to tell people to use --disable-new-dtags if they really don't want the
> new DT_RUNPATH behavior ?  seems like the DT_RPATH behavior is the exception
> rather than the rule ... the only thing it has going for it is historical
> precedence.
>
> similarly, i don't think it generally makes sense for libraries to utilize
> DT_RPATH.  dare i suggest that a middle ground might be to default to
> DT_RUNPATH when -shared is in use, and DT_RPATH otherwise ?
> -mike

Since DT_RPATH != DT_RUNPATH. we need a new option to
specify DT_RUNPATH.

-- 
H.J.