B
Brian
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.
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.