From mboxrd@z Thu Jan  1 00:00:00 1970
From: markh@landmark.com
To: gcc@gcc.gnu.org
Cc: markh@saturn.landmark.com
Subject: link errors using the latest snapshot
Date: Wed, 20 Sep 2000 08:16:00 -0000
Message-id: <200009201515.LAA09755@spill.landmark.com>
X-SW-Source: 2000-09/msg00471.html

GCC Maintainers,

Here are some more details about my gcc snapshot build:

   O/S: HP-UX 11.00
   Canonical triplet: hppa2.0n-hp-hpux11.00
   Compiler used to build snapshot: gcc version 2.95.2
   Binary utilities version: binutils 2.10
   Configuration switches:
        --enable-languages=c++
        --enable-threads=posix
        --enable-version-specific-runtime-libs
        --with-gnu-as

   I reported the following problem in last week's snapshot.  I am
   seeing it still in this week's snapshot.  Should I be asking this
   question on a different mailing list?  I'm not reporting a bug --
   I'm asking a question about the information reported by the 'nm'
   program (and, indirectly, about the compiler and linker).

   The linker is generating the following errors while linking a small
   program I have:

   __builtin_delete (code)
   bad_typeid virtual table(data)
   operator new(unsigned long, void *)(code)
   __builtin_new (code)
   ios virtual table(data)
   type_info type_info function(code)
   stdiobuf virtual table(data)
   type_info virtual table(data)
   bad_cast virtual table(data)
   bad_typeid::~bad_typeid(void)(code)
   bad_cast type_info function(code)
   ostream::operator<<(ostream &(*)(ostream &))(code)
   filebuf virtual table(data)
   ios type_info function(code)
   exception type_info function(code)
   exception virtual table(data)
   bad_cast::~bad_cast(void)(code)
   bad_typeid type_info function(code)
   __builtin_vec_delete (code)
   __builtin_vec_new (code)
   __user_type_info type_info function(code)

When I track down these symbols, for example, 'operator new', using
'nm', it reports the following:

libgcc.a:new.o:00000000 t operator new(unsigned long, void *)

The curious item here is the lower case 't'.  Normally, functions are
identified with an upper case 'T', and this appears to be why the
linker (/usr/ccs/bin/ld) is saying it cannot find the function code in
libgcc.a.  Can someone explain what the lower case 't' indicates?  It
is not documented in the 'nm' (binutils) info files.

-- 
## Mark Harig
## Landmark Systems, Reston, Virginia, USA
## Email: mharig@landmark.com