public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
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	[thread overview]
Message-ID: <200009201515.LAA09755@spill.landmark.com> (raw)

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

             reply	other threads:[~2000-09-20  8:16 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-20  8:16 markh [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-09-15 10:58 markh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200009201515.LAA09755@spill.landmark.com \
    --to=markh@landmark.com \
    --cc=gcc@gcc.gnu.org \
    --cc=markh@saturn.landmark.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).