[Scummvm-devel] Release plans, once again

[Marcus Comstedt]

Max Horn <max at quendi.de> writes:

>> Ok Max, here's a tricky dynamic plugin question for you:
>>
>> The "scumm" plugin depends on "Common::ReadStream::readUint32LE()".
>> This function is defined in libcommon.a.  But the scumm plugin is not
>> linked against libcommon.a?!  The main scummvm binary is linked
>> against libcommon.a, but since it doesn't use any ReadStream functions
>> itself, the relevant object file doesn't get included.
>
> You mean it gets stripped out of the binary?

No.  It never gets put in.  .a-archives only contribute with those
object modules which are actually referenced from somewhere.


> One way would be to add a list of symbols which should explicitly be
> exported.

The symbol can't be exported if it's not defined.  It's not a symbol
issue; it's just the code itself which never gets included.


>> How do you solve this on Unix (should be same problem there)?
>>
> Actually, it links just fine, at least on OSX (anybody tried on Linux
> recently) ? However, the plugin version doesn't work for me right now
> anyway -- the launcher works, but running a game fails. I haven't yet
> investigated this, though -- last time it occured for me it was due to
> a compiler bug <sigh>. Might be that there are problems with global
> objects (and singletons) might cause me problems.

My guess is that the reason it fails is that it tries to call one of
those functions which never got included in the main binary.  Since
you're using lazy resolution, you won't get a warning when you load
the library, it will appear to work until the functions are actually
used.


  // Marcus