Re[2]: [odb-users] Refer a persistent class from another persistent class, where both classes are implemented in different libraries

Сергей Никонов shprotello at mail.ru
Thu May 3 14:50:50 EDT 2018


Hi Boris,

I have the similar export setup for moduleA too, but with a different symbol defined: --export-symbol common:moduleA_EXPORT.
If I link the modules with a shared library (or application) that uses both classes everything is OK. 

I've resolved the issue temporarily by adding necessary code from moduleA to moduleB.

Thank you,
Sergey

>Вторник,  1 мая 2018, 18:11 +03:00 от Boris Kolpackov < boris at codesynthesis.com >:
>
>Сергей Никонов < shprotello at mail.ru > writes:
>
>> I've encountered a linking problem in the following situation:
>> - persistent class 'A' is defined in 'moduleA' library
>> - persistent class 'B' is defined in 'moduleB' library and refers to 'A'
>> - both modules are built with dynamic multi-database support
>> 
>> When I try to build a library with supporting database code for
>> 'moduleB' I get the following linker error:
>> 
>> error LNK2019: unresolved external symbol "public: static class std::shared_ptr<class A> __cdecl odb::access::object_traits_impl<class A,0>::find(class odb::database &,unsigned __int64 const &)" (...) referenced in function "protected: class std::shared_ptr<class A> __cdecl odb::database::find_<class A,0>(unsigned __int64 const &)" (...)
>> 
>> ODB compiler options for B.h compiling are (not all):
>> 
>> [...] --export-symbol common:moduleB_EXPORT
>
>Provided that you have a similar export setup for the moduleA library
>and that you link moduleA to moduleB, it should work.
>
>Are you able to link moduleA to an executable that calls database::load<A>()
>without unresolved symbols?
>
>
>Boris


More information about the odb-users mailing list