[D-runtime] druntime should be a shared library/DLL

[Rainer Schuetze]

On 20.02.2013 09:39, Walter Bright wrote:
>
> On 2/20/2013 12:16 AM, Rainer Schuetze wrote:
>> On 15.02.2013 23:34, Rainer Schuetze wrote:
>>>
>>> In contrast to the version in the bugzilla report (which linked the DM C
>>> runtime library snn.lib into the DLL, but exported all its symbols) I
>>> now used the shared C runtime library snd.lib which is the import
>>> library for sccrt70.dll). I think that this is the better approach as it
>>> allows sharing the C runtime with non-D DLLs. In addition it is easier
>>> to translate to other C-runtimes.
>>>
>>> Now I realize that this library and the DLL are not found in the free
>>> dmc compiler distribution, but only in the commercial distribution.
>>> Walter, is there a problem with also adding snd.lib and sccrt70.dll to
>>> the DMD release?
>>
>>
>> Ping. Walter, does it make sense to assume that snd.lib and
>> sccrt70.dll will be distributed with dmd?
>
>
> They need updating first. But I suspect users would prefer that there
> just be one dll (your first approach).

I was afraid you would say that ;-) If you are in DLL hell, I don't 
think it makes a big difference whether you have to deal with one or two 
libraries. Also, sccrt70.dll is probably not a fast moving target.

What you lose with compiling the C runtime into the D DLL is sharing it 
with a C host or DLL. If this gets ported to Win64 and the MS runtime, 
it might be more important because it seems more common to use the 
shared MS-CRT.

Also, the build process is a lot cleaner with snd.lib, because snn.lib 
has to be teared apart. I'm also a bit worried that not all objects in 
snn.lib are prepared for being used from multiple client DLLs.