This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ 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]

[v3] Don't create unlinkable 64-bit libtestc++.a on IRIX 6


On IRIX 6.5, many 64-bit tests failed like this:

ld64: WARNING 126: The archive ./libtestc++.a defines no global symbols. Ignoring.
ld64: WARNING 84 : /usr/lib/../lib64/libm.so is not used for resolving any symbol.
ld64: ERROR   33 : Unresolved data symbol "__gnu_test::verify_demangle(char const*, char const*)" -- 1st referenced by /var/tmp//ccEFuyo4.o.
	Use linker option -v to see when and which objects, archives and dsos are loaded.  
ld64: INFO    152: Output file removed because of error.
collect2: ld returned 2 exit status
compiler exited with status 1

Upon further investigation, this happens because the 64-bit libtestc++.a is
misconstructed:

ar -rc ./libtestc++.a testsuite_abi.o testsuite_allocator.o testsuite_character.o testsuite_hooks.o verified_cmd_line_input.o prog_bar.o elapsed_timer.o 
Executing on host: ar -rc ./libtestc++.a testsuite_abi.o testsuite_allocator.o testsuite_character.o testsuite_hooks.o verified_cmd_line_input.o prog_bar.o elapsed_timer.o    (timeout = 300)
ar: Warning:./libtestc++.a had 32 bit objects but testsuite_abi.o is a 64 bit object file.
  The archive ./libtestc++.a cannot be used for linking.


and many more such warnings.

The issue is that one cannot mix 32 and 64-bit objects in a single
archive and trying to do so turns the archive unlinkable.  ar(1) states:

     This version of ar produces both 32-bit and 64-bit archives.  The 32-
     bit archive format is defined in the System V Release 4 ABI.  The 64-
     bit archive format is defined in the 64-bit ELF OBJECT File
     Specification.  32-bit objects and 64-bit objects cannot be mixed in
     an archive.  The first object determines whether the archive will be
     32-bit or 64-bit, if the archive does not exist to begin with.  In
     compilers of version 7.x and higher, the archiver also archives WHIRL
     objects.  Mixing is allowed between 32-bit relocatable ELF objects and
     32-bit WHIRL objects, and between 64-bit relocatable ELF objects and
     64-bit WHIRL objects.

     While you can mix 32-bit objects and 64-bit objects in the same
     archive, once you mix files in the archive, the archive cannot be used
     by ld.

To avoid this problem, one needs to remove the archive file before
creating it with ar -rc, as the following patch does.

I've rerun make -k check for both multilibs with the patch, and all the
failures above have vanished.  The only thing I'm uncertain about is
whether remote_file build delete is correct for all scenarios.

Ok for mainline (and the 4.4 and 4.5 branches after testing)?

	Rainer


2010-11-27  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	* testsuite/lib/libstdc++.exp (v3-build_support): Delete
	libtestc++.a before creation.

diff -r 5a323c5047ad libstdc++-v3/testsuite/lib/libstdc++.exp
--- a/libstdc++-v3/testsuite/lib/libstdc++.exp	Sat Nov 27 10:46:29 2010 +0100
+++ b/libstdc++-v3/testsuite/lib/libstdc++.exp	Sat Nov 27 10:59:56 2010 +0100
@@ -589,6 +589,9 @@
     }
 
     # Collect into libtestc++.a
+    # Delete libtestc++.a first.  Mixed 32 and 64-bit archives cannot be
+    # linked on IRIX 6.
+    remote_file build delete "./libtestc++.a"
     if  [info exists env(AR)] {
 	set ar $env(AR)
     } else {


-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University


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