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

[Rainer Schuetze]

On 05.03.2013 22:58, Walter Bright wrote:
>
> 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.)
>

That will make the source unusable as a static library, which is a 
horrible idea. You will also need two versions of the files, one with 
initalizer/function implementation, and one without. di-file generation 
might help but comes with its own set of problems.


>>
>> 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.

I think it is inevitable in D, e.g. with runtime reflection and module 
dependencies.