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

[Walter Bright]

On 3/5/2013 12:01 PM, Rainer Schuetze wrote:
> On 05.03.2013 15:50, Walter Bright wrote:
>>
>> On 3/1/2013 9:38 AM, Rainer Schuetze wrote:
>>> IMO using the import functionality of "export" to support data imports
>>> through the import table is not an option as it pollutes the code (you
>>> might even need two different sources when building against a shared
>>> or static library) and introduces restrictions (like not being able to
>>> use the address of an imported symbol in static data initializers).
>>> That's why I am following the idea to patch code to refer to data in
>>> the shared library.
>>>
>>>
>>> - Is there something wrong with the whole concept?
>>
>> Yes. I'd just stick with the way DLL imports are designed to work, which
>> is the extra level of indirection, and just deal with any restrictions
>> that come out of that.
>
> I don't think it's a good idea to cripple the language for a nuisance by an 
> underpowered linking mechanism. E.g. not being able to use the same static 
> initializers as when linking statically would be annoying. To avoid that in 
> C/C++ runtime initializer functions are created (they do anything else than 
> the proposed patching).
>
> How do you want to deal with references to data objects from code? Annotate 
> everything with "export" (which is an "import" depending on whether an 
> initializer follows or not)? That will break the use of the same code for 
> static libraries as the "_imp_" symbols will be missing.

That's what the "export" protection level was designed for. (It'll serve both 
purposes, no need for import as well.)

>
> The only option I see is to use indirections for all data accesses, with the 
> data pointer being in the import table or elsewhere. That might be causing 
> linker problems, but at least that seems feasible at the cost of some runtime 
> performance loss.

I think on Windows that people are used to having a different interface when 
crossing DLL boundaries. Me, I think it's a terrible user code design to pass 
global data that way.