[odb-users] Delayed initialization of polymorphic_entry_for_X and create_schema_entry_

[steffen at boast.nl]

On 14-01-2016 18:59, Boris Kolpackov wrote:
> Hi Steffen,
> 
> steffen at boast.nl <steffen at boast.nl> writes:
> 
>> I ran into a problem which I think is related to delayed
>> initialization of the variable polymorphic_entry_for_X.
>> 
>> I have a polymorphic object structure that is peristed to ODB, say A
>> : B. I now try to read all objects using database.query<B>().
>> Entities are stored using perist(QSharedPointer<B>); Thus, odb is
>> never (compile time) made aware of the existence of type A in this
>> case. I have two applications with the same code; one works, one
>> throws a "no type information" exception?
>> 
>> By adding a reading database.query<A>() to the code, it works in
>> both applications. As the code is shared between the two
>> application, the only cause I can think of is a delayed
>> initialization of polymorphic_entry_for_A. Is that correct?
> 
> The only situation where you can have delayed static global (as opposed 
> to
> function-local) object initialization is if you delay loading the 
> shared
> library that contains it. I've never heard of delayed initialization of
> objects that are already loaded into the process' memory. Maybe with
> RTLD_LAZY? Or, perhaps, you are using a static library and since nobody
> references A, the corresponding object file doesn't get linked. I think
> this must be it.
> 
> What exactly is your setup (i.e., is A in a static/shared library and 
> if
> so how is it loaded) and platform?
> 
> Boris

Hi Boris,

Sorry, forgot to mention my setup. I also did some more research in the 
mean time.  We're using qt's .pro files as a build system. All the 
entities + generated code are part of the application. However, the .pro 
files are organized in modules, and they are all compiled separately 
into libs and then statically linked into a single executable. So that's 
probably where the problem is. The application that did not have the 
problem consists of a single .pro file.

The C++ standard explicitly allows a compiler to postpone initialization 
until something from the compilation unit is called. So it probably is 
allowed for the linker to ignore the compilation unit, since it was 
never explicitly used.

Thanks for the help!

Steffen