This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH 2/2 v5] gold: enable new dtags by default
On Tue, Feb 19, 2013 at 10:15 PM, Mike Frysinger <firstname.lastname@example.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 <email@example.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
> 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 ?
Since DT_RPATH != DT_RUNPATH. we need a new option to