The patch http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00712.html causes more than 1000 failures: http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01089.html The problem seems uniuqe to ia64. The good ones: [hjl@gnu-4 libjava]$ readelf --wide - sr ./java/util/logging/.libs/natLogger.o | grep ZN4java4util7logging6Logger7getNameEv 0000000000000d17 0000000800000027 R_IA64_DIR64LSB 0000000000000000 .gnu.linkonce.t._ZN4java4util7logging6Logger7getNameEv + 0 0000000000000d1f 0000000800000027 R_IA64_DIR64LSB 0000000000000000 .gnu.linkonce.t._ZN4java4util7logging6Logger7getNameEv + 20 0000000000000231 0000000800000027 R_IA64_DIR64LSB 0000000000000000 .gnu.linkonce.t._ZN4java4util7logging6Logger7getNameEv + 0 0000000000000000 0000000800000027 R_IA64_DIR64LSB 0000000000000000 .gnu.linkonce.t._ZN4java4util7logging6Logger7getNameEv + 0 0000000000000008 0000000800000027 R_IA64_DIR64LSB 0000000000000000 .gnu.linkonce.t._ZN4java4util7logging6Logger7getNameEv + 2 0000000000000020 0000000800000027 R_IA64_DIR64LSB 0000000000000000 .gnu.linkonce.t._ZN4java4util7logging6Logger7getNameEv + 0 19: 0000000000000000 32 FUNC WEAK DEFAULT 11 _ZN4java4util7logging6Logger7getNameEv [hjl@gnu-4 libjava]$ readelf --wide -sr ./java/util/logging/.libs/Logger.o | grep ZN4java4util7logging6Logger7getNameEv 00000000000000e0 000000ef00000081 R_IA64_IPLTLSB 0000000000000df0 _ZN4java4util7logging6Logger7getNameEv + 0 0000000000000640 000000a000000047 R_IA64_FPTR64LSB 0000000000000df0 .L_ZN4java4util7logging6Logger7getNameEv13 + 0 160: 0000000000000df0 32 FUNC LOCAL DEFAULT 1 .L_ZN4java4util7logging6Logger7getNameEv13 239: 0000000000000df0 32 FUNC GLOBAL DEFAULT 1 _ZN4java4util7logging6Logger7getNameEv Even if ld sees natLogger.o first, the definitions in Logger.o will be used. The bad ones are [hjl@gnu-4 libjava]$ readelf --wide - sr ./java/util/logging/.libs/natLogger.o | grep ZN4java4util7logging6Logger7getNameEv 0000000000000d17 0000000800000027 R_IA64_DIR64LSB 0000000000000000 .gnu.linkonce.t._ZN4java4util7logging6Logger7getNameEv + 0 0000000000000d1f 0000000800000027 R_IA64_DIR64LSB 0000000000000000 .gnu.linkonce.t._ZN4java4util7logging6Logger7getNameEv + 20 0000000000000231 0000000800000027 R_IA64_DIR64LSB 0000000000000000 .gnu.linkonce.t._ZN4java4util7logging6Logger7getNameEv + 0 0000000000000000 0000000800000027 R_IA64_DIR64LSB 0000000000000000 .gnu.linkonce.t._ZN4java4util7logging6Logger7getNameEv + 0 0000000000000008 0000000800000027 R_IA64_DIR64LSB 0000000000000000 .gnu.linkonce.t._ZN4java4util7logging6Logger7getNameEv + 2 0000000000000020 0000000800000027 R_IA64_DIR64LSB 0000000000000000 .gnu.linkonce.t._ZN4java4util7logging6Logger7getNameEv + 0 19: 0000000000000000 32 FUNC WEAK DEFAULT 11 _ZN4java4util7logging6Logger7getNameEv [hjl@gnu-4 libjava]$ readelf --wide -sr ./java/util/logging/.libs/Logger.o | grep ZN4java4util7logging6Logger7getNameEv 0000000000000df6 0000004100000027 R_IA64_DIR64LSB 0000000000000000 .gnu.linkonce.t._ZN4java4util7logging6Logger7getNameEv + 0 0000000000000dfe 0000004100000027 R_IA64_DIR64LSB 0000000000000000 .gnu.linkonce.t._ZN4java4util7logging6Logger7getNameEv + 20 00000000000005db 0000004100000027 R_IA64_DIR64LSB 0000000000000000 .gnu.linkonce.t._ZN4java4util7logging6Logger7getNameEv + 0 00000000000000e0 0000019500000081 R_IA64_IPLTLSB 0000000000000000 _ZN4java4util7logging6Logger7getNameEv + 0 0000000000000640 0000011c00000047 R_IA64_FPTR64LSB 0000000000000000 .L_ZN4java4util7logging6Logger7getNameEv13 + 0 000000000000033a 0000004100000027 R_IA64_DIR64LSB 0000000000000000 .gnu.linkonce.t._ZN4java4util7logging6Logger7getNameEv + 0 0000000000000342 0000004100000027 R_IA64_DIR64LSB 0000000000000000 .gnu.linkonce.t._ZN4java4util7logging6Logger7getNameEv + 2 00000000000000a0 0000004100000027 R_IA64_DIR64LSB 0000000000000000 .gnu.linkonce.t._ZN4java4util7logging6Logger7getNameEv + 0 284: 0000000000000000 32 FUNC LOCAL DEFAULT 134 .L_ZN4java4util7logging6Logger7getNameEv13 405: 0000000000000000 32 FUNC WEAK DEFAULT 134 _ZN4java4util7logging6Logger7getNameEv The ones in Logger.o will be discarded. The problem may be .L_ZN4java4util7logging6Logger7getNameEv13. Discarding definitions in Logger.o seems to cause problems on ia64.
Are you sure that this is not a linker problem.
I am investigating the ia64 linker. I think the ia64 linker should issue an error if it can't get it to work at the run time.
.L_ZN4java4util7logging6Logger7getNameEv13 is a local alias of _ZN4java4util7logging6Logger7getNameEv. When _ZN4java4util7logging6Logger7getNameEv is discarded, I am trying to figure out what happened to .L_ZN4java4util7logging6Logger7getNameEv13. My simple testcase indicates linker will issue an error. But gcc shouldn't use .L_ZN4java4util7logging6Logger7getNameEv13 when _ZN4java4util7logging6Logger7getNameEv is a link once symbol. It should use _ZN4java4util7logging6Logger7getNameEv directly. I think this bug affects all link once targets. It is just that it shows up on ia64 immediately.
Ok, linkder did complain: /usr/local/bin/ld: `.L_ZN4java4util7logging6Logger7getNameEv13' referenced in section `.data.rel' of ./.libs/libgcj0_convenience.a(Logger.o): defined in discarded section `.gnu.linkonce.t._ZN4java4util7logging6Logger7getNameEv [java::util::logging::Logger::getName()]' of ./.libs/libgcj0_convenience.a (Logger.o) /usr/local/bin/ld: BFD 2.16.90.0.2 20050414 assertion fail elf64-ia64.c:3371 It is a gcc bug.
A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01915.html
*** Bug 21109 has been marked as a duplicate of this bug. ***
I'm seeing the same error in some C++-only packages. The smallest example I could find is jikes <http://prdownloads.sourceforge.net/jikes/jikes-1.22.tar.bz2>: g++ -O2 -fmessage-length=0 -Wall -o jikes ast.o body.o bytecode.o case.o class.o code.o control.o decl.o definite.o depend.o diagnose.o double.o dump.o error.o expr.o incrmnt.o init.o javaact.o jikes.o jikesapi.o long.o lookup.o lpginput.o modifier.o op.o option.o parser.o platform.o scanner.o segment.o set.o stream.o symbol.o system.o tab.o unparse.o unzip.o zip.o /usr/lib/gcc/ia64-suse-linux/4.0.1/../../../../ia64-suse-linux/bin/ld: `.gnu.linkonce.t._ZN12ConstantPool9CPInvalidD1Ev' referenced in section `.gnu.linkonce.ia64unw._ZN12ConstantPool9CPInvalidD1Ev' of class.o: defined in discarded section `.gnu.linkonce.t._ZN12ConstantPool9CPInvalidD1Ev[ConstantPool::CPInvalid::~CPInvalid()]' of class.o /usr/lib/gcc/ia64-suse-linux/4.0.1/../../../../ia64-suse-linux/bin/ld: final link failed: Bad value
Which binutils are you using? It looks like this problem http://sourceware.org/ml/binutils/2005-04/msg00011.html
I'm using binutils 2.16.90.0.2.
That is a binutils bug: http://sources.redhat.com/bugzilla/show_bug.cgi?id=940
Is this now fixed?
I didn't see those failures today.