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

[Rainer Schuetze]

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.

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.