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

[Mike Frysinger]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://sourceware.org/pipermail/binutils/attachments/20130220/b0fd49a4/attachment.sig>