This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Undefined Virtual Function Table Using GCC 2.8.1


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,
Sincerely,
  James Warner & David Mitchell


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]