[PATCH] fix testsuite ldscripts problem [was Re: mips and frv testsuite failures after plugin patch]

[Dave Korn]

On 25/10/2010 12:06, Alan Modra wrote:
> On Mon, Oct 25, 2010 at 10:11:06AM +0100, Dave Korn wrote:
>>   On the other hand, your patch didn't make any difference when I tried it
>> against cross-frv-elf on HEAD: no change in the test results at all.
> 
> I did commit the ld/ part a bit later than the bfd/ part.  Perhaps you
> didn't get the ld/plugin.c change?

  I applied it manually to one of my sandboxes from your email, so no worry
there.  Thanks for taking care of it.

>>   On the third hand, it appears to me that those "FRV TLS relocs" failures
>> were all pre-existing before my patch.
> 
> It doesn't appear that way to me.

  It turns out there was a confounding factor causing them to fail anyway;
lots of the ld tests were failing with errors like this:

> Executing on host: sh -c {./ld-new -melf32frvfd
> -L/gnu/binutils/git.repo/binutils/ld/testsuite/ld-frv -static
> tmpdir/tls-1-dep.o -o tmpdir/dump tmpdir/dump0.o 2>&1} /dev/null ld.tmp
> (timeout = 300)
> spawn [open ...]
> /gnu/binutils/frv-elf.clean/ld/./.libs/ld-new: cannot open linker script
> file ldscripts/elf32frvfd.xc: No such file or directory
> failed with: </gnu/binutils/frv-elf.clean/ld/./.libs/ld-new: cannot open
> linker script file ldscripts/elf32frvfd.xc: No such file or directory>,
> expected: <>
> /gnu/binutils/frv-elf.clean/ld/./.libs/ld-new: cannot open linker script
> file ldscripts/elf32frvfd.xc: No such file or directory
> failed with: </gnu/binutils/frv-elf.clean/ld/./.libs/ld-new: cannot open
> linker script file ldscripts/elf32frvfd.xc: No such file or directory>,
> expected: <>
> FAIL: FRV TLS relocs, static linking

  As it happens, there's a bug w.r.t. using linker scripts in the testsuite on
hosts that require a libtool wrapper.  We rely on find_scripts_dir() in
ldfile.c to locate $objdir/ld/ldscripts/ by calling

>   dir = make_relative_prefix (program_name, ".", ".");

which works fine on (e.g.) linux hosts where program_name is
$objdir/ld/ld-new, but fails on hosts that need a libtool wrapper, where the
actual program is at ( $objdir/ld/.libs/ld-new.

  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?

ld/ChangeLog:

	* Makefile.am (ldscripts-link): New phony target.
	(check-DEJAGNU): Depend on it.
	* Makefile.in: Regenerate.

  [ A bigger problem ISTM is that find_scripts_dir() will always prefer an
existing installed ldscripts directory if there is one, but I haven't thought
what to do about that, and I'm going to punt on it, I have too much else going
on right now. ]

    cheers,
      DaveK

-------------- next part --------------
A non-text attachment was scrubbed...
Name: testsuite-ldscripts-fix.diff
Type: text/x-c
Size: 856 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20101026/27c699b0/attachment.bin>