D hates to be dynamic linked

[Justin Johansson]

Rainer Schuetze wrote:
 > Hi,
 >
 > as I'm also hitting some problems with DLLs, here are some issues 
that I am now aware of (sorry, can't tell for linux shared objects, but 
I guess the situation is similar):
 >
 > 1. For D2, there is a major blocker with DLLs loaded after 
intialization on XP because of no TLS support from the OS. There is a 
simple workaround for single-threaded application (just setting FS:2c to 
a pointer to _tlsstart), but I'm considering a full emulation of the TLS 
initialization.
 >
 > 2. No multi-threading support: I've added a function to std.thread 
that allows adding a thread to the Thread.allThreads array, so it can be 
called from DLLMain/THREAD_ATTACH. That way the GC can suspend these, 
and allocations from different threads don't trample onto each other. Is 
there anything else needed for full multi-threading support?
 >
 > My patch is currently D1/Win32 only, but should not be too hard to 
extend to other platforms. Attaching to already existing threads is a 
bit harder, though, and it might not always be desired, because these 
threads might never call into D-code.
 >
 > 3. To try things out, I am playing around with the mydll-example, and 
it shows some quirks that you need to get around: the 
implementation-file for the DLL needs to use a file name different from 
the module name, because you need another file specifying the exports. 
Unfortunately this cannot be the di-file created from the source, 
because it contains two much information that will cause references to 
symbols not actually exported.
 >
 > Maybe some command line switch is needed to just write the exports 
into the di file without any implementations. Even better: import the 
implementation file, but don't create unnecessary references. (I think 
it's the module-initialization that's been called because of the import 
- maybe some modifier to the import could remove it).
 >
 > 4. The documentation on the website states, that you should use
 >
 >     DATA            PRELOAD SINGLE
 >
 > in the def-file. That probably is still there as a historical note to 
win 3.1, it will cause different processes to trample on each others 
data segments. This has caused a few hours of debugging, so please 
remove it, so others don't fall into the same trap. The mydll-example 
does not use the statement.
 >
 > 5. To share gc-collected objects between different DLLs, a common 
phobos-DLL seems necessary. Extracting the GC into a separate DLL and 
using the proxy-mechanism to attach any other client-DLL to it seems 
feasable, but are there other things that need to be shared between 
different phobos-instances? What about exception-handling?
 >





 > I'd say, if there is a way to put all public symbols into a def-file, 
then compile phobos into a DLL and create the import library and use 
this instead of a static library. The multi-threading-issue for DLLs 
needs to be solved before, though.

Hi Rainer,

Congrats.  Sounds like you are giving the problem a lot of thought.

Just regarding the public symbols though, I hazard a guess that you
might run into a name-mangling problem here.  Don't want to put a
damper on your effort though; just a forewarning that this might be
an issue.  Perhaps someone else who knows about exporting DLL
symbols might be gracious enough to chime in.

Cheers
Justin