On Tuesday 05 February 2013 00:43:04 Ian Lance Taylor wrote: > On Mon, Feb 4, 2013 at 5:44 PM, H.J. Lu 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