dynamic library building and loading

[Johannes Pfau]

Am Mon, 01 Oct 2012 14:34:21 +0200
schrieb Jacob Carlborg <doob at me.com>:

> On 2012-10-01 12:42, Johannes Pfau wrote:
> 
> > There are some reasons for dynamic libraries linked at compile time,
> > one is that we have to start somewhere and they are required for
> > plugins / dynamically loaded libraries as well ;-)
> >
> > So I started a small test suite for GDC (could be adapted to other
> > compilers). It currently only tests compile time linking of dynamic
> > libraries, but adjusting the test to use runtime loading should be
> > easy. But it's pointless as long as we have no runtime support.
> > https://github.com/jpf91/dso-test
> >
> > It should also be enhanced to test multiple shared libraries.
> >
> > The good news:
> > * Exception handling is working
> > * ModuleInfos are working
> > * unit tests are working
> > * Static variables, gshared variables, tls variables are working
> > * Object.factory is working
> > * Calling functions, passing function pointers, passing classes
> > between dso/app is working
> 
> That's good. Have you tested this with DMD?

Not yet.
> 
> > The bad news:
> > * The GC doesn't scan TLS/__gshared/static data in dynamic
> > libraries, it only scans the main app.
> 
> That should be fairly trivial on Mac OS X. But I'm suspecting it
> won't be that easy on Linux.
> 
> BTW, is the runtime and phobos statically linked both with the
> dynamic library and the executable?

I tested two different configurations:

druntime and phobos are shared libraries as well (this is the correct
solution, it's mostly working except for the GC issues)

druntime and phobos static linking: phobos and druntime are statically
linked into the app, libdso.so is not linked against druntime/phobos at
all. (this is a hack to get better test results: With a shared
druntime, you can't call GC.collect twice, because the first call
frees important objects in druntime and then the second call segfaults)