DIP 45 - approval discussion

[Walter Bright]

On 11/10/2013 1:25 PM, Benjamin Thaut wrote:
> Am 10.11.2013 20:33, schrieb Walter Bright:
>> On 11/10/2013 4:13 AM, Benjamin Thaut wrote:
>>> Addition: It is necessary to export the module info. Because as soon
>>> as you
>>> import a module and use any part of it, the compiler will reference
>>> the module
>>> info.
>>
>> Actually, it isn't entirely clear to me why the moduleinfo needs to be
>> exported.
>>
>> The moduleinfo is needed to run the static ctors/dtors, etc., but that
>> is needed by the code internal to the dll that initializes the dll.
>
> Well if the dll initializes all the modules, it has to initialize _all_ the
> modules because it can't know which are used and which are not. This is most
> certenly the way to go when loading a D dll with the LoadLibrary windows api
> function(s).

Yes, and that's also the way shared library support has been implemented in 
druntime.


> But when you link against a D dll using a genereated import library there would
> be the option to make it behave exactly like static libraries where only modules
> get initiliazed, which are actually used.

I don't believe it is necessary to support this. I don't think the C or C++ 
standard shared runtime library does. The general idea with DLLs is they become 
an indivisible unit - if you want to load only part of a DLL, you should split 
it into multiple DLLs.


> Also lets assume you do not export module infos, how does the compiler know that
> the module is inside a dll so that the module info is not referenced? That goes
> against the basic design of this DIP. The entire idea was to make static /
> shared liraries more similar and require less effort from the user. And not the
> other way around. If this is not wanted we can go right back to the C/C++ way of
> defining both dllexport and dllimport.

The trouble with dllexport and dllimport is the same module is both depending on 
how it is used - I don't think that is very viable (C/C++ deal with this using 
macros). The idea is to use export for both, and then use the context to figure 
out if it is dllimport or dllexport.