[D-runtime] DLL initialization in Druntime

[Rainer Schuetze]

Sean Kelly wrote:
> On Jan 18, 2011, at 11:37 AM, Rainer Schuetze wrote:
> 
>> Sean Kelly wrote:
>>> The unfortunate part is that this isn't necessary when using Runtime.loadLibrary(), since that will do the right thing.  It would only be necessary for a non-D hosting app.  I guess if it has an "already ran" flag in it then the library writer could have his init_my_lib() routine call it instead.  *sigh*  No automatic alternatives, huh?
>> What about creating a DLL that just contains the GC and exports the proxy pointer? Any DLL/EXE that wants to use the shared GC links against the import library of this DLL and sets its proxy pointer before any other initialisation.
>>
>> In case of multi threading, a bit more needs to done to forward TLS ranges to the proxy. But this will probably not work anyway, because the threads also need to be shared.
>>
>> So, better create a druntime.dll/phobos.dll to share everything...
> 
> A druntime/phobos DLL would be a clean way to handle this, though shared libraries complicate distribution of user code.  

Yes, welcome to DLL hell...

> Although, didn't Visual Studio eliminate the option of statically linking its runtime library?  

I think the option is only missing in the express versions (cannot say 
for sure for VS2010, but VS2008 has static libraries).

> We'd still need a reasonable short-term solution though. 

I guess, Walters' tests pass with the fix to the proxy, and it will work 
with the same restrictions as before. I would not expect many people 
using it, so this is probably no blocker.

> I don't even know what would be required to ship druntime/phobos in a DLL, but I'm guessing it's more than a few simple changes.  We'd probably need export labels all over the place, etc, right?

Yes, I've done that through a compiler switch: 
http://d.puremagic.com/issues/show_bug.cgi?id=4071

But it is more tricky than that, because you need to access data in the 
DLL, and the import table only allows this if there is support from the 
compiler which has to add an indirection.

My solution checks the relocation table and patches relocations into the 
import table to directly point into the phobos.dll. The executable just 
needs to link against another library that contains a different startup 
code and the imports.