dynamic library building and loading

Johannes Pfau nospam at example.com
Mon Oct 1 03:42:34 PDT 2012


Am Sat, 29 Sep 2012 15:19:30 +0200
schrieb Jacob Carlborg <doob at me.com>:

> On 2012-09-28 20:25, Maxim Fomin wrote:
> 
> > I tried to check how TLS, EX, etc. (mostly exposed to dll issue) are
> > working and here is some kind of test:
> > https://github.com/mxfm/sharedtest. Unfortunately scope(exit) isn't
> > executed when it is situated in a shared library and which calls
> > some throwing function from another shared library. Unittests
> > aren't working either. Regarding other parts - they seem to work.
> 
> That's a fairly uninteresting test. You are linking to the dynamic 
> library. What's interesting is loading a dynamic library using
> dlopen, or similar. What's the point of using dynamic libraries if
> you're linking with them?
> 

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

The bad news:
* The GC doesn't scan TLS/__gshared/static data in dynamic libraries,
  it only scans the main app.


More information about the Digitalmars-d mailing list