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]

[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; \

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