problems with binutils and/or g++

Hi,

With current binutils (as of Oct. 13) and GCC, I get the following error when building APT:

../build/obj/cmdline/apt-get.o: In function `global destructors keyed to c0out':
/home/build/apt-0.3.19/cmdline/apt-get.cc:1429: undefined reference to `pkgArchiveCleaner type_info function'
/usr/bin/ld: ../build/obj/cmdline/apt-get.o(.gnu.linkonce.t.__tf10LogCleaner+0x1c): cannot find stub entry 00000010___tf17pkgArchiveCleaner+0 /usr/bin/ld: ../build/obj/cmdline/apt-get.o(.gnu.linkonce.t.__tf10LogCleaner+0x1c): cannot handle R_PARISC_PCREL17F for pkgArchiveCleaner type_info function /home/build/apt-0.3.19/cmdline/apt-get.cc:1429: undefined reference to pkgArchiveCleaner type_info node' /home/build/apt-0.3.19/cmdline/apt-get.cc:1429: undefined reference to pkgArchiveCleaner type_info node'

I'm not sure if this is a g++ or linker bug. The symbol names look really suspicious, suggesting that it might be a bug in RTTI (I'll try recompiling with -fno-rtti, as I don't think APT uses it). But on the other hand we've had problems with link-once sections in the past.

Any thoughts?

[email protected], http://www.linuxcare.com/
Linuxcare. Support for the revolution.

Translation: Alan has been mucking around with link-once section symbols and may have broken something.

I'll take a look.

Linuxcare.  Support for the Revolution.

After fixing a zillion bugs of the "friend foo" -> "friend class foo" type and assorted protected/private/public issues, I finally managed to have apt compile. Same error as you found. It's not a linker bug as it's not a case of the linker dropping some section; the undefined symbol really isn't defined anywhere. I don't know enough C++ to debug the problem further.

Recompiling with -fno-rtti results in a successful build.

Linuxcare.  Support for the Revolution.

Alan, for my curiosity, could you explain this particular line from g++'s output (from dhd's message)?

../build/obj/cmdline/apt-get.o(.gnu.linkonce.t.__tf10LogCleaner+0x1c):
cannot handle R_PARISC_PCREL17F for pkgArchiveCleaner type_info function

that seems to be causing the "undefined" symbol messages.

randolph

   @..@                                         http://www.TauSq.org/
  (----)
 ( >__< )
 ^^ ~~ ^^

That message actually comes from the linker in response to an error during final link. See bfd/elf32-hppa.c:elf32_hppa_relocate_section. It's saying a particular relocation couldn't be relocated for some reason. In this case, the undefined symbol is the cause of the message (not the other way around), and since the linker already reported the undefined symbol it's rather redundant. I should probably not report "cannot handle.." for undefined symbols.

Alan Modra

Linuxcare.  Support for the Revolution.

No, it's caused *by* the undefined symbol. If a symbol is undefined, it won't have a stub hash entry. If it doesn't have a stub hash entry and it is either in a shared library or out of branch range, then relocations to it can't be handled. Thus the error message.

The case where a symbol is defined, and yet is unreachable, results in a different warning (should be an error, but for some reason it seemed to be non-fatal last time I encountered it) message which tells you to recompile with -ffunction-sections.

We might want to get rid of the 'cannot handle R_PARISC_FOO' messages in the undefined symbol case, as they are evidently misleading.

[email protected], http://www.linuxcare.com/
Linuxcare. Support for the revolution.

I have observed problems with cc1plus regarding weak symbols that sometimes don't get output. For example, libg++ wouldn't build under i386 linux for a number of weeks because of this. Turning off math inlining (define __NO_MATH_INLINES) would for some strange reason fix the problem. The problem was fixed a week or two ago, although it is not clear what patch fixed the problem. The problem didn't seem to occur for the pa port under hpux.

On the otherhand, cc1plus has problems compiling tFile.cc in the libio testsuite under hpux. Although the compile does complete sucessfully after a long time, it uses an enormous amount of memory. This doesn't happen under i386 linux. I have determined the memory blow up occurs in the gcse pass but haven't been able to find the cause as of yet.

Dave

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)