[parisc-linux] problems with binutils and/or g++

[parisc-linux] problems with binutils and/or g++

[David Huggins-Daines]

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?

-- 
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.

Re: problems with binutils and/or g++

[Alan Modra]

On 17 Oct 2000, David Huggins-Daines wrote:

> 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.

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.

Re: problems with binutils and/or g++

[Alan Modra]

On 17 Oct 2000, David Huggins-Daines wrote:

> 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?

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.

Re: problems with binutils and/or g++

[Randolph Chung]

> 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.

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/
  (----)
 ( >__< )
 ^^ ~~ ^^

Re: problems with binutils and/or g++

[Alan Modra]

On Wed, 18 Oct 2000, Randolph Chung wrote:

> > 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.
> 
> 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.

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.

Re: problems with binutils and/or g++

[David Huggins-Daines]

Randolph Chung <randolph@tausq.org> writes:

> 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.

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.

-- 
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.

Re: problems with binutils and/or g++

[John David Anglin]

> Randolph Chung <randolph@tausq.org> writes:
> 
> > 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.
> 
> 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.

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                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)