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] fix testsuite ldscripts problem [was Re: mips and frv testsuite failures after plugin patch]


On Mon, Oct 25, 2010 at 09:23:18PM +0100, Dave Korn wrote:
>   A quick "ln -s ../ldscripts .libs/ldscripts" fixed it, so attached is a
> patch that does pretty much the same at "make check" time, what do you think?

Seems a reasonable fix.  Should be OK even without running libtool, ie.
always make a link in $xobjdir.

>   [ A bigger problem ISTM is that find_scripts_dir() will always prefer an
> existing installed ldscripts directory if there is one

Err, yeah.  For a typical setup,
-DSCRIPTDIR='"/usr/local/powerpc-linux/lib"'
-DBINDIR='"/usr/local/bin"'
-DTOOLBINDIR='"/usr/local/powerpc-linux/bin"'
the first call to check_for_scripts_dir in find_scripts_dir will look
for dir_path_to_ld/../powerpc-linux/lib/ldscripts, the second for
dir_path_to_ld/../lib/ldscripts, and the third for
/usr/local/powerpc-linux/lib/ldscripts.  The comment on the third call
says "We've been installed normally", however, that actually handles
the case where ld *hasn't* been installed normally.  The normal ld
install will be in /usr/local/bin, so the first call to
check_for_scripts_dir will find it, even when ld is a symbolic link to
/usr/local/bin/ld.

I think that we could probably remove the third call.  If ld is moved
somewhere without its accompanying ldscripts dir (assuming ld is built
to use ldscripts), I'd say that is an error on the part of whoever
moved ld.

-- 
Alan Modra
Australia Development Lab, IBM


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