dynamic library building and loading

[Maxim Fomin]

On Thursday, 27 September 2012 at 17:10:07 UTC, Jacob Carlborg 
wrote:
> On 2012-09-27 10:55, Maxim Fomin wrote:
>> On Thursday, 27 September 2012 at 08:26:08 UTC, Jacob Carlborg 
>> wrote:
>>> 1. Does this actually run?
>>>
>>
>> If it were non-runnable, I wouldn't posted it.
>>
>>> 2. This is statically linked with druntime and Phobos. What 
>>> happens
>>> when you create an executable that links with the D dynamic 
>>> library?
>>
>> Solution depends on a problem. I understood Andrei's post that 
>> he wanted
>> a .so file or DLL. I told originally that it is possible to 
>> make shared
>> libraries on linux. Now I see there is some misunderstanding. 
>> Is the
>> problem in diving D application on executables and shared 
>> libraries or
>> making druntime+phobos a shared library or loading a library 
>> at runtime?
>> A was speaking about the first.
>
> Actually, I seriously doubt everything is working as expected. 
> For example, what happens when an application loads (via dlopen 
> or similar) a D dynamic library:
>
> * Are exception handlers registered
> * Are module infos properly registered
> * What happens if I call Object.factory, will that find a class 
> in the dynamic library
> * Are GC sections registered
> * What happens when the library is unloaded, will all of the 
> above be unregistered and cleaned up
>
> A quick look in rt.minfo in druntime shows the it uses a single 
> array or linked list for all module infos. It expect the module 
> infos to be in just one place, i.e. in the application. There's 
> no handling when a dynamic library is loaded.
>
> Have a look at this:
>
> https://github.com/D-Programming-Language/druntime/blob/master/src/rt/minfo.d#L184
>
> That symbol points to the start of the linked list containing 
> module infos. That's only a single linked list, no handling of 
> module infos from multiple places.
>
> rt.minfo needs to be changed to use an associative array with 
> the keys pointing to images (executables and loaded dynamic 
> libraries) and the values mapped to module infos of the given 
> image. It also needs to intercept when a library is dynamically 
> loaded, extract the module infos and register it with the 
> runtime.
>
> I would think that the same is true for exception handling 
> tables, TLS and GC sections.

Posted code doesn't load libraries at runtime, it is just linked 
to shared libraries.