Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #13613 > unrolled thread

Undefined virtual Function Table

Back to article view | Back to comp.lang.c

Contents

  Undefined virtual Function Table Brian <nospam@nospam.com> - 2011-11-19 21:30 +0000
    Re: Undefined virtual Function Table Ian Collins <ian-news@hotmail.com> - 2011-11-20 10:35 +1300
      Re: Undefined virtual Function Table Seebs <usenet-nospam@seebs.net> - 2011-11-19 22:59 +0000
        Re: Undefined virtual Function Table Ian Collins <ian-news@hotmail.com> - 2011-11-20 12:25 +1300
    Re: Undefined virtual Function Table Keith Thompson <kst-u@mib.org> - 2011-11-19 14:23 -0800
      Re: Undefined virtual Function Table Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2011-11-19 23:32 +0100

#13613 — Undefined virtual Function Table

Hi,

   I am currently working on a big project, and I usually don't post
   to newsgroups as I like to get through problems on my own, or by
   talking to coworkers.  However, I have recently run across a problem
   that I am unable to resolve using the tools that I have available:

   While compiling an executable on the Sun-Solaris OS Version 2.4
   using gcc 2.8.1 and either the native sun linker or the ld that
   comes with binutils 2.9.1 we receive an undefined symbol:
     __vt_8NewClass  which demangles to 'TrackFiles virtual table'

   I have read that (On platforms that run neither collect nor the GNU
   linker, like Solaris, you may see an odd undefined symbol like
"_vt.3foo",
   where foo is a class name).

   This is probably because you are missing a definition for the first
   (non-inline) virtual function of the class. Since gcc-2.7.0, g++ uses
   a trick borrowed from cfront: the .o file containing the definition
   for the first non-inline virtual function for the class will also
   contain the virtual function table.

   I have also tried adding the -fvtable-thunks flag reccomended by
   EGCS in dealing with missing virtual talbe problems.  The problem
   is that I am unable to build an executable while this symbol
   remains undefined.

   This is the basic code that I am working with:
     class OldClass
     { public:
         OldClass() { /* some inlined code */ }
         virtual ~OldClass () { }
         virtual bool member_func();
         virtual int* get_int ( int* id, int component_type) = 0;
         virtual int  component2 (int id) = 0;
      // other pure virtual functions similar to these exist
     };

// now, in a seperate file which compiles into a seperate object file
// but is included in the same static library we have:

     class newClass : public OldClass
     { public:
         newClass();
         virtual ~newClass();  // this is implemented in the *.C file
       // no other virtual functions exist within this file
     };

I have tried:
  various code changes including making the destructor non-virtual,
  not explicitly defined, removing inlining of code, inlining the
  code, removing the destructor from the base class, and using nm to
  tell us what line the symbol appears to be defined on.  We have
  tried using the gnu linker vs. the solaris linker, we have attempted
  adding flags for inlining, and not inlining code for gcc, undefining
  the symbol via flags [I was desperate].  Throughout all of this I
  have been unable to either define this symbol, or make it go away.
  And yes, I have read the available FAQ's and documentation.

Any help you can give me in resolving this problem would be greatly
appreciated, as I am at my wits end with this.  Some things that are
not options at this time are: upgrading to an untested compiler,
combining the classes into one file, completely rewriting the code
from scratch, sacrificing small animals to solve the problem.  We are
tied to this platform as well.

Thank you for your time and consideration in this matter.

[toc] | [next] | [standalone]

#13614

On 11/20/11 10:30 AM, Brian wrote:
> Hi,
>
>     I am currently working on a big project, and I usually don't post
>     to newsgroups as I like to get through problems on my own, or by
>     talking to coworkers.  However, I have recently run across a problem
>     that I am unable to resolve using the tools that I have available:
>
>     While compiling an executable on the Sun-Solaris OS Version 2.4
>     using gcc 2.8.1 and either the native sun linker or the ld that
>     comes with binutils 2.9.1 we receive an undefined symbol:
>       __vt_8NewClass  which demangles to 'TrackFiles virtual table'

Has this post taken a decade to reach Usenet?  The tools and OS were old 
when people where worrying about the millennium bug.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#13619

On 2011-11-19, Ian Collins <ian-news@hotmail.com> wrote:
> Has this post taken a decade to reach Usenet?  The tools and OS were old 
> when people where worrying about the millennium bug.

Doesn't one of the regular trolls frequently repost ages-old questions
that are obviously not about C here using the address nospam@nospam.com?

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#13620

On 11/20/11 11:59 AM, Seebs wrote:
> On 2011-11-19, Ian Collins<ian-news@hotmail.com>  wrote:
>> Has this post taken a decade to reach Usenet?  The tools and OS were old
>> when people where worrying about the millennium bug.
>
> Doesn't one of the regular trolls frequently repost ages-old questions
> that are obviously not about C here using the address nospam@nospam.com?

Indeed:

http://groups.google.com/group/comp.lang.c/browse_thread/thread/c04867803874121c/85f055ecb09a845d?q=Undefined+virtual+Function+Table#85f055ecb09a845d


-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#13616

Brian <nospam@nospam.com> writes:
>    I am currently working on a big project, and I usually don't post
>    to newsgroups as I like to get through problems on my own, or by
>    talking to coworkers.  However, I have recently run across a problem
>    that I am unable to resolve using the tools that I have available:
>
>    While compiling an executable on the Sun-Solaris OS Version 2.4
>    using gcc 2.8.1 and either the native sun linker or the ld that
>    comes with binutils 2.9.1 we receive an undefined symbol:
>      __vt_8NewClass  which demangles to 'TrackFiles virtual table'
[...]
>    This is the basic code that I am working with:
>      class OldClass
[...]
>      };
[...]

Your code is C++, not C.  You *might* get better answers in
comp.lang.c++.

But why are you using such ancient tools?  gcc 2.8.1 was released
in 1998; the latest release is 4.6.2.  Solaris 2.4 was released in
1994, and was superseded by Solaris 2.5 in 1995.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#13617

Keith Thompson ha scritto:
[...]
> Your code is C++, not C.  You *might* get better answers in
> comp.lang.c++.
>
> But why are you using such ancient tools?  gcc 2.8.1 was released
> in 1998; the latest release is 4.6.2.  Solaris 2.4 was released in
> 1994, and was superseded by Solaris 2.5 in 1995.

I wonder if that's the same Brian who started this thread:
http://goo.gl/JukLw

-- 
Vincenzo Mercuri | www.backbox.org

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web