On 11/18/2013 06:13 AM, Walter Bright wrote:
>
> Why? dmd is very fast at compiling. I'm not sure what is being saved here.

It's not the time argument, but correctly listing all modules that go into the same DLL as additional compilation argument.

You can see an earlier proposals of the DIP.

http://wiki.dlang.org/?title=DIP45&oldid=2921 - export(exampleLib)
    dmd -m64 -export libA -of"libA.dll" dllmain.d libA.d -L/DLL -L/IMPLIB:"libA.lib"
    dmd -m64 -export libB -import libA -of"libB.dll" dllmain.d libB.d -L/DLL -L/IMPLIB:"libB.lib" -LlibA.lib
    dmd -m64 -import libB -import libA main.d -LlibA.lib -LlibB.lib

On 11/18/2013 06:12 AM, Walter Bright wrote:
>
> I'm very much against the suggested rewriting of obj files to strip the
> export records :-)

That is only one particular aspect of the DIP. It's not essential and maybe we'll find a different solution during implementation.
The need to statically link a library into a DLL is rare enough to delegate this to an extra tool.

On 11/18/2013 06:12 AM, Walter Bright wrote:
> I'm very much against the suggested rewriting of obj files to strip the
> export records :-)
>
Changed
http://wiki.dlang.org/?title=DIP45&diff=3201&oldid=3094

On 2 December 2013 06:05, Martin Nowak <code@dawg.eu> wrote:

> On 11/18/2013 06:12 AM, Walter Bright wrote:
>
>>
>> I'm very much against the suggested rewriting of obj files to strip the export records :-)
>>
>
> That is only one particular aspect of the DIP. It's not essential and
> maybe we'll find a different solution during implementation.
> The need to statically link a library into a DLL is rare enough to
> delegate this to an extra tool.
>

Sorry, I'm just casually following this thread. I'm very interested to have
this mess resolved, but don't have a great deal of input.
This comment surprised me a little though, you say it's rare to statically
link a lib into a DLL?

In my experience, I don't think that's rare at all, I'd say it's very
common, in fact, in my experience, I can't think of many instances where
I've built some code as a DLL which hasn't included other lib's (statically
linked).
Maybe it's just me, but if I'm building something as a DLL (rather than a
static lib), it's precisely because it is quite large, and offers generally
self-contained functionality (which often depends on other libs).
The only exception in my experience is plugin functionality.

Just a comment on other aspects of this thread...
There's all this debate around dllimport vs dllexport. And this is probably
my ignorance, but I have to wonder why dllimport even exists?
I've been using DLL's for a long time, and I've never used dllimport (that
I'm aware of).
I either statically link an import lib (which binds to the exports in a
nice efficient way), or I call LoadLibrary and find symbols manually...
I'm not really even sure what dllimport does. Why is it so important, and
why is it causing so much fuss?

On 02.12.2013 05:59, Manu wrote:
> Just a comment on other aspects of this thread...
> There's all this debate around dllimport vs dllexport. And this is
> probably my ignorance, but I have to wonder why dllimport even exists?
> I've been using DLL's for a long time, and I've never used dllimport
> (that I'm aware of).
> I either statically link an import lib (which binds to the exports in a
> nice efficient way), or I call LoadLibrary and find symbols manually...
> I'm not really even sure what dllimport does. Why is it so important,
> and why is it causing so much fuss?

For function imports, not using dllimport magically works, but adding it to the declaration can avoid one jump when calling the imported function.

Imports to data variables don't have that magic, it can either be accessed directly, or it has to be accessed by an indirection through the import table. The dllimport specifies which code has to be generated.

I actually have an implementation, that patches the data accesses as a secondary relocation step, circumventing the indirection through the import table. Unfortunately it does not work on 64-bit. The problem here is that dmd generated code only uses 32-bit relative addressing, but that disallows accessing data in another shared library directly.

The respective discussion where this approach was rejected by Walter is supposed to be here: http://forum.dlang.org/thread/8bd42b4e-8c3b-42a6-9f00-2081b1329cd2@me.com , but it seems it is somehow reduced to a single post.