[odb-users] undefined reference link error when use odm.dll

[Alessandro Catania]

Hi Boris,
Code is complex and made by several hands .

>  Are these the pure virtual or the empty from your description above?
in file .hxx destructor is defined pure virtual
class BaseClass {
     ....
     virtual ~BaseClass() =0
     ....
}

// baseclass extends BaseClass
DerivedClass:: public BaseClass {
    ...

in file baseclass.cpp BaseClass destructor is implemented as:
BaseClass::~BaseClass(){};


I found in code that use orm.dll a strange use like this:

    typedef odb::query<DerivedClass>  queryD;
    typedef odb::result<DerivedClass> resultD;

    resultD res (db->query<DerivedClass> (queryD::id="blabla"));
    for (resultD::iterator i(res.begin()); i!=res.end(); ++i)  {
        DerivedClass p; // this cause undefined reference
BaseClass::~BaseClass() error
        i.load(p);            // why don't use iterator i directly instead
of load in p and use p??


Il giorno ven 3 set 2021 alle ore 14:58 Boris Kolpackov <
boris at codesynthesis.com> ha scritto:

> Alessandro Catania <alcatania at gmail.com> writes:
>
> > I work on c++ code that use orm 2.3.0 on windows an gcc compiler.
>
> Very old version, you should consider upgrading.
>
>
> > Orm code is generated by odb and is a library (that I call orm.dll) and
> > contains polymorphism, in particular some destructors are defined pure
> > virtual in base class. Empty destructors are implemented in Cxx source.
> > Symbols are exported in my orm library as explained in manual in "16.2.2
> > Dynamic Loading of Database Support Code"
> >
> > This library compile correctly, but when I use it in another part of code
> > linker give error undefined reference for destructors of base classes
> > (defined as virtual).
>
> Are these the pure virtual or the empty from your description above?
>
>
> > Could be that destructors symbols of base classes are not exported?
> > But orm should export all class and then also destructors.
>
> This is most likely an idiosyncrasy of Windows DLL exporting semantics.
> If these are the pure virtual destructors we are talking about, make
> sure their classes have some non-inline function definition to "anchor"
> the vtable (and if there aren't any, try to turn the pure virtual
> destructor into just virtual with an non-inline definition).
>