This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
[PATCH] fix testsuite ldscripts problem [was Re: mips and frv testsuite failures after plugin patch]
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
Index: ld/Makefile.am
===================================================================
RCS file: /cvs/src/src/ld/Makefile.am,v
retrieving revision 1.292
diff -p -u -r1.292 Makefile.am
--- ld/Makefile.am 14 Oct 2010 01:31:29 -0000 1.292
+++ ld/Makefile.am 25 Oct 2010 19:45:45 -0000
@@ -1916,7 +1916,16 @@ EXTRA_ld_new_SOURCES += $(ALL_EMULATION_
# This is the real libbfd.a created by libtool.
TESTBFDLIB = @TESTBFDLIB@
-check-DEJAGNU: site.exp
+ldscripts-link:
+ -eval "x`$(LIBTOOL) --config | $(GREP) ^objdir=`" && \
+ if test -d $$xobjdir; then \
+ test ! -e $$xobjdir/ldscripts \
+ && $(LN_S) ../ldscripts $$xobjdir/ldscripts; \
+ fi
+
+.PHONY: ldscripts-link
+
+check-DEJAGNU: site.exp ldscripts-link
srcroot=`cd $(srcdir) && pwd`; export srcroot; \
r=`pwd`; export r; \
LC_COLLATE=; LC_ALL=; LANG=; export LC_COLLATE LC_ALL LANG; \