January 18, 2011 [D-runtime] DLL initialization in Druntime | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | 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. |
Copyright © 1999-2021 by the D Language Foundation