Am Mon, 01 Oct 2012 14:34:21 +0200 schrieb Jacob Carlborg <d...@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)
