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]

Re: [patch] ldfile.c: Fix the search path ordering for a linker script.


On Thu, Apr 02, 2009 at 03:19:27PM +1030, Alan Modra wrote:
> On Wed, Apr 01, 2009 at 07:50:40PM -0700, Kazu Hirata wrote:
> >   http://sourceware.org/ml/binutils-cvs/2008-08/msg00062.html
> > 
> > seems to have changed the search path ordering for a linker script in
> > a way that contradicts what the ld documentation says.
> 
> There was a reason why I chose that particular search order.  Consider
> the most common case, where someone invokes ld without giving a -T
> or -dT option.  If your copy of ld supports built-in scripts then for
> the default target you'll always use one of the built-in scripts.  If
> ld doesn't support built-in scripts, then ld reads the script from
> ldscripts/, which is usually installed in $prefix/lib/.  Your change
> could make ld choose some ldscripts/ other than the one installed
> along with the ld binary.  For instance, if I build and install a new
> version of ld using a prefix of /usr/local, then I always want to use
> scripts in /usr/local/lib/ldscripts/.  I wouldn't want to pick up the
> old system scripts in /usr/lib/ldscripts/ if -L /usr/lib happened to
> be passed to ld!

Actually, I think that would be a reasonable thing to do... anyway,
can we treat the default linker scripts specially in this regard?  For
people with a customized linker script, having a copy of a system-wide
installed script is quite common.

-- 
Daniel Jacobowitz
CodeSourcery


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]