Bug? Where are these emitted?? (type_info, virtual table, etc)

[Phil Edwards <pedwards at ball dot com>]

I am still trying to get a decent account to use to subscribe, so for now 
/please/ Cc replies to this address.


I have installed and have been using
    [monkey 313]> g++ -v
    Reading specs from /usr/local/lib/gcc-lib/sparc-sun-
    solaris2.6/egcs-2.91.57/specs
    gcc version egcs-2.91.57 19980901 (egcs-1.1 release)
    [monkey 314]>
for a while with no problems.  Been loving it, up until a few hours ago.

I create a bunch of seperate classes, compiled with -fPIC, and then create a 
shared library for each group of classes, with -shared.  This has been 
working fine, and really helps testbeds.  I mention this only to avoid any 
confusion with the command line here:

    [monkey 322]> make driver
    g++ -o driver -L./lib -R./lib  -Wall  toplevel.o -lDBR -lLib
    -lMapper -lParsers -lWriters 2>&1
    Undefined                       first referenced
     symbol                             in file
    DBR type_info node                  ./lib/libDBR.so
    DBR type_info function              ./lib/libDBR.so
    DBR virtual table                   ./lib/libDBR.so
    ld: fatal: Symbol referencing errors. No output written to driver
    collect2: ld returned 1 exit status
    make: *** [driver] Error 1
    [monkey 323]>

DBR is a pure virtual base class.  I did find a solution, but am wondering 
about the real problem.

The hierarchy starts with this (useless stuff elided):

class DBR
{
  public:
	explicit DBR (FILE*);
	virtual ~DBR () = 0;         // is implemented
};

and is extended with this:

class DBR_v1 : public DBR
{
  public:
	// implementation calls DBR::DBR(FILE*) above
	explicit DBR_v1 (FILE*);

	~DBR_v1 ();           // is implemented
};


Everything was fine until this fn was added to the DBR public block:

	virtual int foo () const;    // NOT implemented

and this to the DBR_v1 public block:

	int foo () const;            // IS implemented

and then began the linker errors you saw above.  In desperate 
experimentation, I made the base member fn pure virtual,

	virtual int foo () const = 0;    // NOT implemented

and all was well.  Even though foo was never being called anywhere in client 
code, since I hadn't gotten that far.


Is this a problem with egcs 1.1, or am I violating the Standard?  The base 
class was already pure due to the dtor, so an "impure" virtual in the base 
class doesn't really make any sense, granted, but I didn't think it would 
cause errors.  (I'm going to leave them pure virtual anyhow, in the spirit of 
making more sense.)

Thanks for satisfying my curiosity!


--
/dev/phil            Ball Aerospace & Technologies Corp.
pedwards@ball.com    Advanced Systems & Technology Operations
(937-320-4048)