Am 10.01.2018 um 05:18 schrieb Domain:
> On Saturday, 6 January 2018 at 19:32:51 UTC, Benjamin Thaut wrote:
>> I'm currently back on dll support and I'm applying finishing touches to my dll support PR. Now I want to know if I missed any corner cases and it would be great if a few more people gave the dll support a try.
>>
>> [...]
> 
> I am glad to see this happen. But my use case is not working:
> http://forum.dlang.org/post/giywzmvfeuddvmvkrpal@forum.dlang.org

Hi Domain,

what your describing is a very simple use case and should definitly work. Did you try it using my binary distribution? Please post a repro-case. I don't have the time to rebuild everyones use case and saying "My use case is not working" does not help at all.

-- 
Kind Regards
Benjamin Thaut

On Wednesday, 10 January 2018 at 11:30:47 UTC, Benjamin Thaut wrote:
> Am 10.01.2018 um 05:18 schrieb Domain:
>> On Saturday, 6 January 2018 at 19:32:51 UTC, Benjamin Thaut wrote:
>>> I'm currently back on dll support and I'm applying finishing touches to my dll support PR. Now I want to know if I missed any corner cases and it would be great if a few more people gave the dll support a try.
>>>
>>> [...]
>> 
>> I am glad to see this happen. But my use case is not working:
>> http://forum.dlang.org/post/giywzmvfeuddvmvkrpal@forum.dlang.org
>
> Hi Domain,
>
> what your describing is a very simple use case and should definitly work. Did you try it using my binary distribution? Please post a repro-case. I don't have the time to rebuild everyones use case and saying "My use case is not working" does not help at all.

Sorry, my mistake. But I cannot use your binary:

D:\>dmd -m64 -shared dll.d -ofdll.dll
Error: unrecognized file extension dll

Am 10.01.2018 um 13:39 schrieb Domain:
> 
> Sorry, my mistake. But I cannot use your binary:
> 
> D:\>dmd -m64 -shared dll.d -ofdll.dll
> Error: unrecognized file extension dll
> 
> 

This works just fine for me. What is the output when you execute "dmd --version"?

-- 
Kind Regards
Benjamin Thaut

On Wednesday, 10 January 2018 at 13:14:10 UTC, Benjamin Thaut wrote:
> Am 10.01.2018 um 13:39 schrieb Domain:
>> 
>> Sorry, my mistake. But I cannot use your binary:
>> 
>> D:\>dmd -m64 -shared dll.d -ofdll.dll
>> Error: unrecognized file extension dll
>> 
>> 
>
> This works just fine for me. What is the output when you execute "dmd --version"?

I restart my computer, and it can produce dll now. But when I compile exe:
dmd -m64 -useshared app.d -ofapp.exe

app.obj : error LNK2019: 无法解析的外部符号 _D3std12experimental6logger4core17stdThreadLocalLogFNdNfZCQCeQCdQBsQBo6Logger，该符号在函数 _D3std12experimental6logger4core__T18defaultLogFunctionVEQCdQCcQBrQBn8LogLeveli64Z__TQByVii9VAyaa5_6170702e64VQra8_6170702e6d61696eVQBna15_766f6964206170702e6d61696e2829VQCza3_617070TQDmZQFwFNfLQDxZv 中被引用
app.obj : error LNK2019: 无法解析的外部符号 _D6object__T8__equalsTxaTxaZQqFNaNbNiNfAxaQdZb，该符号在函数 _D3std5array__T8AppenderTAyaZQo4Data11__xopEqualsFKxSQBzQBy__TQBvTQBpZQCdQBqKxQBaZb 中被引用
app.obj : error LNK2019: 无法解析的外部符号 _D3std12experimental6logger4core14globalLogLevelFNdNiNfZEQCdQCcQBrQBn8LogLevel，该符号在函数 _D3std12experimental6logger4core6Logger__T15memLogFunctionsVEQChQCgQBvQBr8LogLeveli64Z__T7logImplVii9VAyaa5_6170702e64VQra8_6170702e6d61696eVQBna15_766f6964206170702e6d61696e2829VQCza3_617070TQDmZQEdMFNfLQDyZv 中被引用
app.obj : error LNK2019: 无法解析的外部符号 _D3std11concurrency7thisTidFNdNfZSQBgQBf3Tid，该符号在函数 _D3std12experimental6logger4core6Logger__T15memLogFunctionsVEQChQCgQBvQBr8LogLeveli64Z__T7logImplVii9VAyaa5_6170702e64VQra8_6170702e6d61696eVQBna15_766f6964206170702e6d61696e2829VQCza3_617070TQDmZQEdMFNfLQDyZv 中被引用
app.obj : error LNK2019: 无法解析的外部符号 _D3std8datetime8timezone9LocalTime6opCallFNaNbNeZyCQBxQBwQBqQBk，该符号在函 数 _D3std12experimental6logger4core6Logger__T15memLogFunctionsVEQChQCgQBvQBr8LogLeveli64Z__T7logImplVii9VAyaa5_6170702e64VQra8_6170702e6d61696eVQBna15_766f6964206170702e6d61696e2829VQCza3_617070TQDmZQEdMFNfLQDyZv 中被引用
app.obj : error LNK2019: 无法解析的外部符号 _D3std12experimental6logger4core8MsgRange6__ctorMFNcNfCQCbQCaQBpQBl6LoggerZSQCwQCvQCkQCgQCe，该符号在函数 _D3std12experimental6logger4core6Logger__T15memLogFunctionsVEQChQCgQBvQBr8LogLeveli64Z__T7logImplVii9VAyaa5_6170702e64VQra8_6170702e6d61696eVQBna15_766f6964206170702e6d61696e2829VQCza3_617070TQDmZQEdMFNfLQDyZv 中被引用
app.obj : error LNK2019: 无法解析的外部符号 _D3std8datetime7systime7SysTime6__ctorMFNaNbNcNflyCQBxQBw8timezone8TimeZoneZSQCxQCwQCqQCl，该符号在函数 _D3std8datetime7systime5Clock__T8currTimeVE4core4time9ClockTypei0ZQBiFNfyCQCuQCt8timezone8TimeZoneZSQDuQDtQDn7SysTime 中被引用
app.obj : error LNK2019: 无法解析的外部符号 _D3std8datetime7systime17FILETIMEToStdTimeFNfMxPS4core3sys7windows7winbase8FILETIMEZl，该符号在函数 _D3std8datetime7systime5Clock__T11currStdTimeVE4core4time9ClockTypei0ZQBmFNdNeZl 中被引用
app.obj : error LNK2019: 无法解析的外部符号 _D3std12experimental6logger4core8MsgRange3putMFNfwZv，该符号在函数 _D3std5range10primitives__T5doPutTSQBh12experimental6logger4core8MsgRangeTaZQBxFNfKQBxKaZv 中被引用
app.obj : error LNK2001: 无法解析的外部符号 _D3std8datetime7systime7SysTime6toHashMxFNaNbNiNfZm
app.obj : error LNK2001: 无法解析的外部符号 _D3std8datetime7systime7SysTime8opEqualsMxFNaNbNfKxSQByQBxQBrQBmZb
app.obj : error LNK2001: 无法解析的外部符号 _D3std8datetime7systime7SysTime8__xopCmpFKxSQBqQBpQBjQBeKxQpZi
app.obj : error LNK2001: 无法解析的外部符号 _D3std8datetime7systime7SysTime8toStringMxFNbNfZAya
app.exe : fatal error LNK1120: 13 个无法解析的外部命令
Error: linker exited with status 1120


Sources:

///////app.d:

import std.experimental.logger;
import core.sys.windows.windows;
import core.runtime;
extern(C) alias void function() startFn;
void main()
{
    info("Loading dll1.dll");
    auto handle1 = cast(HMODULE)Runtime.loadLibrary("dll1.dll");
    auto fp1 = GetProcAddress(handle1, "start");
    (cast(startFn)fp1)();

    info("Loading dll2.dll");
    auto handle2 = cast(HMODULE)Runtime.loadLibrary("dll2.dll");
    auto fp2 = GetProcAddress(handle2, "start");
    (cast(startFn)fp2)();
}

///////dll1.d

import std.stdio;
import std.experimental.logger;
import core.sys.windows.dll;
mixin SimpleDllMain!(DllIsUsedFromC.no);
class MyLogger : Logger
{
    this(LogLevel lv) @safe
    {
        super(lv);
    }
    override protected void writeLogMsg(ref LogEntry entry) @trusted
    {
        writefln("MyLogger: %s", entry.msg);
    }
}
export extern(C) void start()
{
    info("dll1 starting");
    sharedLog = new MyLogger(LogLevel.info);
    info("dll1 started");
}

///////dll2.d

import std.stdio;
import std.experimental.logger;
import core.sys.windows.dll;
mixin SimpleDllMain!(DllIsUsedFromC.no);
export extern(C) void start()
{
	info("dll2 started");
}

dmd -m64 app.d -ofapp.exe
dmd -m64 -shared dll1.d -ofdll1.dll
dmd -m64 -shared dll2.d -ofdll2.dll

output:

2018-01-11T12:04:51.635:app.d:main:9 Loading dll1.dll
2018-01-11T12:04:51.894:dll1.d:start:22 dll1 starting
MyLogger: dll1 started
2018-01-11T12:04:51.897:app.d:main:14 Loading dll2.dll
2018-01-11T12:04:52.164:dll2.d:start:9 dll2 started

I expected:
2018-01-11T12:04:51.635:app.d:main:9 Loading dll1.dll
2018-01-11T12:04:51.894:dll1.d:start:22 dll1 starting
MyLogger: dll1 started
MyLogger: Loading dll2.dll
MyLogger: dll2 started

On Wednesday, 10 January 2018 at 13:14:10 UTC, Benjamin Thaut wrote:
> Am 10.01.2018 um 13:39 schrieb Domain:
>> 
>> Sorry, my mistake. But I cannot use your binary:
>> 
>> D:\>dmd -m64 -shared dll.d -ofdll.dll
>> Error: unrecognized file extension dll
>> 
>> 
>
> This works just fine for me. What is the output when you execute "dmd --version"?

D:\git\testdll\source>dmd --version
DMD64 D Compiler v2.078.0

Copyright (C) 1999-2018 by The D Language Foundation, All Rights Reserved written by Walter Bright

Am 11.01.2018 um 05:10 schrieb Domain:
> I restart my computer, and it can produce dll now. But when I compile exe:
> dmd -m64 -useshared app.d -ofapp.exe
> 
> app.obj : error LNK2019: 无法解析的外部符号 _D3std12experimental6logger4core17stdThreadLocalLogFNdNfZCQCeQCdQBsQBo6Logger， 该符号在函数 _D3std12experimental6logger4core__T18defaultLogFunctionVEQCdQCcQBrQBn8LogLeveli64Z__TQByVii9VAyaa5_6170702e64VQra8_6170702e6d61696eVQBna15_766f6964206170702e6d61696e2829VQCza3_617070TQDmZQFwFNfLQDxZv 中被引用

As I said in the first post, I'm not interrested in linker errors due to missing 'export' annotation. std.experimental.logger does not have an export annotations and therefor will cause linker errors. If you absolutely must use std.experimental.logger you will have to annotate it with 'export' and recompile phobos. The idea behind my initial PR is to build in basic support for dlls, not to fully annotate all of phobos with 'export'.

> 
> dmd -m64 app.d -ofapp.exe
> dmd -m64 -shared dll1.d -ofdll1.dll
> dmd -m64 -shared dll2.d -ofdll2.dll

Your command line is wrong. You are missing the -useshared option and therefore your dlls / executable don't share the same version of druntime.

> 
> output:
> 
> 2018-01-11T12:04:51.635:app.d:main:9 Loading dll1.dll
> 2018-01-11T12:04:51.894:dll1.d:start:22 dll1 starting
> MyLogger: dll1 started
> 2018-01-11T12:04:51.897:app.d:main:14 Loading dll2.dll
> 2018-01-11T12:04:52.164:dll2.d:start:9 dll2 started

How can you get the output of your program if it fails to link?

-- 
Kind Regards
Benjamin Thaut

On Thursday, 11 January 2018 at 18:56:23 UTC, Benjamin Thaut wrote:
> Am 11.01.2018 um 05:10 schrieb Domain:
>> [...]
>
> As I said in the first post, I'm not interrested in linker errors due to missing 'export' annotation. std.experimental.logger does not have an export annotations and therefor will cause linker errors. If you absolutely must use std.experimental.logger you will have to annotate it with 'export' and recompile phobos. The idea behind my initial PR is to build in basic support for dlls, not to fully annotate all of phobos with 'export'.
>
>> [...]
>
> Your command line is wrong. You are missing the -useshared option and therefore your dlls / executable don't share the same version of druntime.
>
>> [...]
>
> How can you get the output of your program if it fails to link?

I misunderstand what you mean. I thought -useshared is used when I want to use phobos as a dll.

On Thursday, 11 January 2018 at 18:56:23 UTC, Benjamin Thaut wrote:
> Am 11.01.2018 um 05:10 schrieb Domain:
>> [...]
>
> As I said in the first post, I'm not interrested in linker errors due to missing 'export' annotation. std.experimental.logger does not have an export annotations and therefor will cause linker errors. If you absolutely must use std.experimental.logger you will have to annotate it with 'export' and recompile phobos. The idea behind my initial PR is to build in basic support for dlls, not to fully annotate all of phobos with 'export'.

So I cannot use phobos as a static library when I use dll?

Am 12.01.2018 um 04:02 schrieb Domain:
> On Thursday, 11 January 2018 at 18:56:23 UTC, Benjamin Thaut wrote:
>> Am 11.01.2018 um 05:10 schrieb Domain:
>>> [...]
> 
> So I cannot use phobos as a static library when I use dll?

If you have a single D-dll that is used from a C program then you can use phobos as a static library. In all other cases you must use the dll version of phobos otherwise the sharing of objects between dlls/exe doesn't work correctly.

-- 
Kind Regards
Benjamin Thaut