[osg-users] Android osgPlugins

[Jan Ciger]

On Sun, Aug 23, 2015 at 7:22 PM, Christian Kehl <christian-kehl at web.de> wrote:
> Thanks for the explanation - never digged so much into the linker behaviour because usually libraries generate shared or static libraries consitently. This way into the Java sandbox and how to link dependency code for it was new to me. Still, in this case it was the only way I could make it work.

This isn't really an Android or Java specific issue, it is an
idiosyncracy of the GNU linker.

I think the problem happens only when you are taking a static library
(.a) and trying to convert it to a shared library (.so).

This is possible in Linux (and Android), however, it involves
relinking - and that is where things go wrong. If you don't tell the
linker to include the whole archive (.a) file, it will optimize the
"unused" code away. In extreme cases it will happily create a shared
library that has no code inside ...

Trying to link the OSG plugins (shared libraries) using static
dependencies is similar use case - the linker included only symbols
that were used by the rest of the plugin, but had no idea that it
should include also symbols that are only needed by other modules
after the shared library was loaded in memory.

That is, IMO, a compilation bug - each module should be linked with
everything it needs and not rely on the presence of a(nother) shared
library at runtime to bring in those 3rd-party dependencies (I think
it was zlib in your case). E.g. DLL compilation in Windows will fail
for such unresolved symbols. In Linux it passes, because the linker
allows late binding by default, assuming that the undefined symbols
will be resolved at runtime by the dynamic linker.

J.