This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Wednesday 20 February 2013 12:16:51 H.J. Lu wrote: > 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 ? > > Since DT_RPATH != DT_RUNPATH. we need a new option to > specify DT_RUNPATH. i'm aware "DT_RPATH != DT_RUNPATH" is a true statement. however, my point still stands that for the majority of cases, people want runpath tags to specify custom paths for loading libraries and in that regard, DT_RUNPATH is the same as DT_RPATH. imo, the example you posted is the exception rather than the rule when it comes to expected behavior and already works w/the patches i posted -- if you want that behavior, use -rpath --disable-new-dtags. hence the idea is to improve the default rather than requiring everyone to change flags. -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |