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.
