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

[Kazu Hirata]

Hi Daniel and Alan,

>> 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.

Do you mean something like this?

If -T is explicitly specified anywhere in the command line:
   we search:
     current directory
     search -L directories
     what find_scripts_dir finds
else
   we search
     current directory
     what find_scripts_dir finds
     search -L directories

In any event, I'd like consistency between the documentation and 
implementation.  If we are leaving the implementation as is, we should 
document that the user cannot have a linker script that's named identically 
to one of the system-wide scripts.

Kazu Hirata