On 1 October 2012 13:34, Jacob Carlborg <d...@me.com> wrote: > 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? > > >> 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? > > -- > /Jacob Carlborg
On Linux, there has already been an runtime implementation written that scans /proc/self/maps and adds all data sections to the GC that way. Whether or not DMD wishes to go down that route is their own decision. I am looking into a solution that doesn't have any bearing on what platform it's running on... Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
