libio/testsuite/hounddog fails under hpux 10.20 with gas 2.9.5

John David Anglin dave@hiauly1.hia.nrc.ca
Tue May 2 16:05:00 GMT 2000


The following is the start of many similar test failures for gcc-2.96
(a fairly recent download from the CVS):

spawn /xxx/gnu/gcc-2.96/objdir/gcc/xgcc -B/xxx/gnu/gcc-2.96/objdir/gcc/ ../../../../libio/testsuite/../tests/hounddog.cc -O3 -I.. -I../../../../libio/testsuite/.. -nostdinc++ -I/xxx/gnu/gcc-2.96/libstdc++ -I/xxx/gnu/gcc-2.96/libstdc++/stl -L/xxx/gnu/gcc-2.96/objdir/hppa1.1-hp-hpux10.20/threads/libstdc++ -L/xxx/gnu/gcc-
2.96/objdir/hppa1.1-hp-hpux10.20/threads/libiberty -L/xxx/gnu/gcc-2.96/objdir/hppa1.1-hp-hpux10.20/threads/libiberty -Wl,-a,shared_archive -g -lstdc++ -liberty -lm -threads -o /xxx/gnu/gcc-2.96/objdir/hppa1.1-hp-hpux10.20/libio/testsuite/hounddog
<command line>: warning: The C standard requires whitespace after #define __STDC
_EXT__
collect2: ld terminated with signal 10 [Bus error]
/usr/ccs/bin/ld: Unsatisfied symbols:
   __builtin_delete (code)
   bad_typeid virtual table(data)
   __rtti_user (data)
   __rtti_si (data)
   type_info type_info function(data)
   type_info virtual table(data)
   bad_cast virtual table(data)
   bad_typeid::~bad_typeid(void)(code)
   bad_cast type_info function(data)
   exception type_info function(data)
   exception virtual table(data)
   bad_cast::~bad_cast(void)(code)
   bad_typeid type_info function(data)
   __builtin_vec_new (code)
   __user_type_info type_info function(data)
compiler exited with status 1

The version of as is 2.9.5 which has "weak" support.  The assembly
code re the definition of __builtin_delete in new2.cc used in building
opdel.o is:

        .weak   __builtin_delete
	.EXPORT __builtin_delete,ENTRY,PRIV_LEV=3,ARGW0=GR
__builtin_delete

The definition in libgcc.a(opdel.o) is:

__builtin_delete    |         0|sdef  |entry  |$CODE$

That is the weak attribute used in the definition of __builtin_delete
is represented as a secondary symbol definition in the library.

I have searched the manuals but can't find any indication that the
hpux linker can deal with secondary symbols.  It seems likely that
the link failure is a result of this.  If this is the case, weak
support may need to be disabled under hpux 10.20.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)


More information about the Gcc-bugs mailing list