www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Dll support: testers needed

reply Benjamin Thaut <code benjamin-thaut.de> writes:
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.

-To try it out you will need to build dmd, druntime and phobos yourself. 
I'm not going to provide a binary distribution.
-You will need to target the microsoft linker. E.g. either use -m64 or 
-m32mscoff when compiling your programs.
-be warned, the state of the dll support is not final and subject to 
change. There is no garantuee that there won't be any breaking changes 
to dll support.

You can find a quick start guide here: 
http://stuff.benjamin-thaut.de/D/getting_started.html
If you need more information and examples take a look here: 
https://github.com/Ingrater/DIPs/blob/ReviveDIP45/DIPs/DIP45.md

Not all of phobos/druntime has correct export annotations yet as this is 
not the goal of my initial pull request. If you use a function from 
druntime/phobos that does not have a correct export annotation you will 
get a linker error. I'm not interrested in those. I'm interrested in 
cases where export is correctly used and you will still get linker 
errors / incorrect program behavior. So if you encounter a linker error 
first check if the declaration has a export annotation or not. Try 
adding it and see if the error goes away. If it does not go away, report 
it here or send me an e-mail to code at benjamin-thaut.de

If you find anything, small repro cases would be appreciated as it makes 
my life a lot easier.

-- 
Kind Regards
Benjamin Thaut
Jan 06
next sibling parent reply Rubn <where is.this> writes:
Looks good. If you want testers though, providing binaries would 
be beneficial. Compiling dmd/druntime/phobos on Windows can be a 
pain.
Jan 06
parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 07.01.2018 um 00:42 schrieb Rubn:
 Looks good. If you want testers though, providing binaries would be 
 beneficial. Compiling dmd/druntime/phobos on Windows can be a pain.
I made a binary distribution. I updated http://stuff.benjamin-thaut.de/D/getting_started.html with the details. -- Kind Regards Benjamin Thaut
Jan 07
prev sibling next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
+infinity

Few things I would like answered:

- Why -useShared and not -fPIC?
   - If -useShared why not use it on *nix to turn on -fPIC?
- Why isn't DllIsUsedFromC.no automatically detected?

Regarding C-runtime, yes we need to distribute every version that we 
support on Windows. The compiler will pick the latest (or the installer 
I guess) to use, but we should be able to switch between them. Either 
that or we ship a static lib of Phobos to be linked into a dll upon 
first request of a specific C-runtime.
Jan 06
parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 07.01.2018 um 03:57 schrieb rikki cattermole:
 +infinity

 Few things I would like answered:

 - Why -useShared and not -fPIC?
    - If -useShared why not use it on *nix to turn on -fPIC?
Because the DIP says that -useshared and -fPIC are loosley comparable. This does not mean that they are the same or interchangeable. In fact they are not. On linux when building a executable that uses a shared library -fPIC is not neccessary, unless your distribution requires position independend code everywhere. On windows on the other hand you will need to pass -useshared when building a executable that uses shared libraries.
 - Why isn't DllIsUsedFromC.no automatically detected?
Because its not possible. I don't know of any way to detect wether a dll is loaded by a c-executable or d-executable. As a result the user has to specify it. The main problem here is that currently D Dlls hijack all threads. This is neccessary because currently there is no shared version of phobos, so the information about the threads can't be shared between multiple D dlls. One possibility would also be to remove the thread hijacking alltogether and require the user to manually add threads that have been created from C. This is also the current state on linux if I'm not mistaken. But doing so would break backwards compatibility.
 Regarding C-runtime, yes we need to distribute every version that we 
support on Windows. The compiler will pick the latest (or the installer I guess) to use, but we should be able to switch between them. Either that or we ship a static lib of Phobos to be linked into a dll upon first request of a specific C-runtime. That really is a problem I'm not going to solve. It is more a problem of distributing dmd and building the installer which is beyond the scope of my current PR. -- Kind Regards Benjamin Thaut
Jan 07
prev sibling next sibling parent reply MrSmith <mrsmith33 yandex.ru> writes:
On Saturday, 6 January 2018 at 19:32:51 UTC, Benjamin Thaut wrote:
 You can find a quick start guide here: 
 http://stuff.benjamin-thaut.de/D/getting_started.html
 If you need more information and examples take a look here: 
 https://github.com/Ingrater/DIPs/blob/ReviveDIP45/DIPs/DIP45.md
Does the implementation support dynamically loaded dlls?
Jan 07
parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 07.01.2018 um 15:08 schrieb MrSmith:

 Does the implementation support dynamically loaded dlls?
Yes. There is even a test for it -- Kind Regards Benjamin Thaut
Jan 07
prev sibling next sibling parent reply solidstate1991 <laszloszeremi outlook.com> writes:
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.

 -To try it out you will need to build dmd, druntime and phobos 
 yourself. I'm not going to provide a binary distribution.
 -You will need to target the microsoft linker. E.g. either use 
 -m64 or -m32mscoff when compiling your programs.
 -be warned, the state of the dll support is not final and 
 subject to change. There is no garantuee that there won't be 
 any breaking changes to dll support.

 You can find a quick start guide here: 
 http://stuff.benjamin-thaut.de/D/getting_started.html
 If you need more information and examples take a look here: 
 https://github.com/Ingrater/DIPs/blob/ReviveDIP45/DIPs/DIP45.md

 Not all of phobos/druntime has correct export annotations yet 
 as this is not the goal of my initial pull request. If you use 
 a function from druntime/phobos that does not have a correct 
 export annotation you will get a linker error. I'm not 
 interrested in those. I'm interrested in cases where export is 
 correctly used and you will still get linker errors / incorrect 
 program behavior. So if you encounter a linker error first 
 check if the declaration has a export annotation or not. Try 
 adding it and see if the error goes away. If it does not go 
 away, report it here or send me an e-mail to code at 
 benjamin-thaut.de

 If you find anything, small repro cases would be appreciated as 
 it makes my life a lot easier.
I would volunteer, but I don't know how much I can do in my exam session. Maybe in February, until then not much.
Jan 07
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 08.01.2018 um 00:06 schrieb solidstate1991:
 On Saturday, 6 January 2018 at 19:32:51 UTC, Benjamin Thaut wrote:
 
 I would volunteer, but I don't know how much I can do in my exam 
 session. Maybe in February, until then not much.
Just do some testing whenever you find time, keep monitoring this thread foor upates. -- Kind Regards Benjamin Thaut
Jan 08
parent reply Dylan Graham <dylan.graham2000 gmail.com> writes:
On Monday, 8 January 2018 at 09:01:29 UTC, Benjamin Thaut wrote:
 Am 08.01.2018 um 00:06 schrieb solidstate1991:
 On Saturday, 6 January 2018 at 19:32:51 UTC, Benjamin Thaut 
 wrote:
 
 I would volunteer, but I don't know how much I can do in my 
 exam session. Maybe in February, until then not much.
Just do some testing whenever you find time, keep monitoring this thread foor upates.
I'm waiting on VS2015 and Windows SDK to install. Once that's done, I'll begin testing. Also, thanks a tonne for doing this.
Jan 08
parent reply Dylan Graham <dylan.graham2000 gmail.com> writes:
On Tuesday, 9 January 2018 at 03:50:25 UTC, Dylan Graham wrote:
 On Monday, 8 January 2018 at 09:01:29 UTC, Benjamin Thaut wrote:
 I'm waiting on VS2015 and Windows SDK to install. Once that's 
 done, I'll begin testing.

 Also, thanks a tonne for doing this.
I've done a test that mimics that the planned plugin system for my game. There is a core/engine which is built as a DLL. It exports a class called PluginBase. It also exports a function called getPlugins (to be run from an executable) that searches for plugin DLLs and calls a function from those plugin DLLs that returns their own override of PluginBase. It then runs a few functions on the object and prints the typeid(). The core is built with: dmd -m64 -shared -useshared -version=Shared -H pluginbase.d -L/IMPLIB:pluginbase.lib The resulting pluginbase.di and pluginbase.lib is copied into the directory of Plugin1 which builds against them. Command: dmd -m64 -shared -useshared plugin1.d pluginbase.lib I then made an executable that builds against pluginbase and calls getPlugins(). Command: dmd -m64 -useshared app.d pluginbase.lib pluginbase.dll and plugin1.dll are placed next to the executable. Running it prints this: PS C:\dmd-dll\test\execut> ./app.exe Plugin1 -- (name of plugin defined by overriden class) Hello world from Plugin1 -- (function of that class) plugin1.Plugin1 -- (typeid of that class) It's pretty basic but I'm glad it works. I'll try doing something more advanced.
Jan 08
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 09.01.2018 um 05:19 schrieb Dylan Graham:
 It's pretty basic but I'm glad it works. I'll try doing something more 
 advanced.
Hi Dylan, I'm glad that it works for you. I'm curios though, why are you using an import library for your plugin? Normally plugins are build without and import library (the -L/IMPLIB parameter) and then loaded dynamically through LoadLibrary by your main executable. This way you can add/remove plugins without the need to recompile your main executable. Usually such plugin systems are done like this: You have some common library that defines shared functionality and the base interfaces such as a Plugin base class or Plugin interface. This common library is build into a dll with import library. You have one ore multiple plugins that link against the common library and implement the plugin interface / plugin base class. Each of these plugins provides a function "getPluginImpl" or something along the lines which can be used to get an instance of the Plugin implementation. You have the main executable, which links against the common library. It dynamically loads the plugin.dlls and calls the getPluginImpl method on them to retrieve the implementation. No import library involved here. What your doing is also a valid use case. It is usually done when link times get to long or if you want to have clean interface between the different subsystems in your application. Your codebase is usually split into multiple dlls each with a import library which are then all used by the main executable. -- Kind Regards Benjamin Thaut
Jan 09
next sibling parent Dylan Graham <dylan.graham2000 gmail.com> writes:
On Tuesday, 9 January 2018 at 08:10:56 UTC, Benjamin Thaut wrote:
 Am 09.01.2018 um 05:19 schrieb Dylan Graham:
 It's pretty basic but I'm glad it works. I'll try doing 
 something more advanced.
Hi Dylan, I'm glad that it works for you. I'm curios though, why are you using an import library for your plugin? Normally plugins are build without and import library (the -L/IMPLIB parameter) and then loaded dynamically through LoadLibrary by your main executable.
In all honesty, I'm not sure. I saw the instructions on your website and just adapted it. Also, please excuse me, I'm fairly new to compiling native programs. I've been using DUB this entire time. With the common library (plugin base) DLL don't I need to generate a .lib for plugin implementations to compile/link against?
 This way you can add/remove plugins without the need to 
 recompile your main executable. Usually such plugin systems are 
 done like this:

 You have some common library that defines shared functionality 
 and the base interfaces such as a Plugin base class or Plugin 
 interface. This common library is build into a dll with import 
 library.

 You have one ore multiple plugins that link against the common 
 library and implement the plugin interface / plugin base class. 
 Each of these plugins provides a function "getPluginImpl" or 
 something along the lines which can be used to get an instance 
 of the Plugin implementation.
Check. I'm doing that.
 You have the main executable, which links against the common 
 library. It dynamically loads the plugin.dlls and calls the 
 getPluginImpl method on them to retrieve the implementation. No 
 import library involved here.
I'm doing that but the getPluginImpl call is done in the common library. The executable is only a bootstrap.
 What your doing is also a valid use case. It is usually done 
 when link times get to long or if you want to have clean 
 interface between the different subsystems in your application. 
 Your codebase is usually split into multiple dlls each with a 
 import library which are then all used by the main executable.
I am doing that. I don't need to recompile anything. I can add as many plugin implementations without recompiling the common library/executable.
Jan 09
prev sibling parent reply MrSmith <mrsmith33 yandex.ru> writes:
Is it possible to put common code in exe, and use that code from 
dlls? Or anything can be exported only by dll?

Is it possible to have circular dependencies between dlls?

Tips for doing dlls with dub?
Jan 09
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 09.01.2018 um 12:02 schrieb MrSmith:
 Is it possible to put common code in exe, and use that code from dlls? 
 Or anything can be exported only by dll?
You can only export from dlls. I don't know of any use case where exporting from a executable would make sense. No, you can't put common code into a executable and use that code from dlls. Thats not how dlls are designed to work on windows. If you absoutely still want to export from an executable you can still use -L/EXPORT:"mangledSymbolName"
 
 Is it possible to have circular dependencies between dlls?
No. You will get linker errors. Same as in C/C++.
 
 Tips for doing dlls with dub?
Well, first my PR will have to get merged. Then you'll have to wait until a release exists that actually has my changes and then maybe there is support added in dub. Before that I think trying to use dub to create dlls is wasted effort. -- Kind Regards Benjamin Thaut
Jan 09
parent reply Andre Pany <andre s-e-a-p.de> writes:
On Tuesday, 9 January 2018 at 14:43:43 UTC, Benjamin Thaut wrote:
 Am 09.01.2018 um 12:02 schrieb MrSmith:
 Is it possible to put common code in exe, and use that code 
 from dlls? Or anything can be exported only by dll?
You can only export from dlls. I don't know of any use case where exporting from a executable would make sense. No, you can't put common code into a executable and use that code from dlls. Thats not how dlls are designed to work on windows. If you absoutely still want to export from an executable you can still use -L/EXPORT:"mangledSymbolName"
 
 Is it possible to have circular dependencies between dlls?
No. You will get linker errors. Same as in C/C++.
 
 Tips for doing dlls with dub?
Well, first my PR will have to get merged. Then you'll have to wait until a release exists that actually has my changes and then maybe there is support added in dub. Before that I think trying to use dub to create dlls is wasted effort.
I am building a bridge between Delphi and D. At the moment the executable is written in D and the Dll (Firemonkey UI) is written in Delphi. But I think I want to enable also the other way around. The D coding which is then located in the Dll should be able to call Delphi methods located in the executable. The whole idea idea is that all logic is written in D and you only use the Framework (ui) and libraries Delphi provides. I think this might be a valid use case for a Dll calling functionality located in the exe. Kind regards Andre
Jan 09
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 09.01.2018 um 16:03 schrieb Andre Pany:
 
 I am building a bridge between Delphi and D. At the moment the 
 executable is written in D and the Dll (Firemonkey UI) is written in 
 Delphi. But I think I want to enable also the other way around. The D 
 coding which is then located in the Dll should be able to call Delphi 
 methods located in the executable. The whole idea idea is that all logic 
 is written in D and you only use the Framework (ui) and libraries Delphi 
 provides.
 
 I think this might be a valid use case for a Dll calling functionality 
 located in the exe.
 
 Kind regards
 Andre
First let me say that what you are describing is a very uncommon and ill-advised use case. As such there is not going to be any nice to use workflow to acieve what you are trying to do. Still this doesn't mean that it won't be possible. Why ill-advised? What you're describing is a cyclic dependency between your main executable and your dll written in delphi. If you google for "cyclic dependency dll" you will usually get the advice to break your cylic dependency by splitting your code into more dlls. My personal experience shows the same. Cyclic dependencies in dlls are usually not worth the additional effort and hassle. Also you want to export things from your executable, which is also very uncommon. What you should be doing is having 2 dlls and one executable. You have one common library written in D that is build into a dll. Then you have your delphi library which uses the common.dll. Finally you have your main executable written in D which uses both the common.dll and your delphi.dll. This should make it possibly to break the cycle and get you an easy setup. If you absolutley must do it the way you describe it, its still possible. You will have to compile all modules that export something from your executable with the "-c -shared" parameters. E.g. dmd -m64 -c -shared moduleThatExports1.d moduleThatExports2.d -ofexports.obj Now you link the resulting exports.obj file into your executable by calling dmd again dmd -m64 restOfModules.d exports.obj delphi.lib -ofmain.exe Finally you have to get the handle to your main executable by calling HMODULE handle; GetModuleHandleExA(0, null, &handle); in your delphi dll and then fetching the function pointer for each and every function you want to call from delphi via: GetProcAddress(handle, "mangeledFunctionSymbol") Now finally you can call these functions pointers from delphi and they will call into the D code within your executable. Instead of all that hassle you could instead just have a function in your delphi dll: void recieveFunctionPointer(const(char)* name, void* ptr); which you call for every function that you want to make available from D to delphi. Your delphi code then stores away these pointers depending on the name. That way you don't need to export anything from your executable and can build it normally. Instead of having a function call per function you could obviosuly also use a struct that is defined the same way in D and delphi and contains all relevant functions pointers. -- Kind Regards Benjamin Thaut
Jan 09
parent reply Andre Pany <andre s-e-a-p.de> writes:
On Tuesday, 9 January 2018 at 18:32:24 UTC, Benjamin Thaut wrote:
 Am 09.01.2018 um 16:03 schrieb Andre Pany:
 [...]
First let me say that what you are describing is a very uncommon and ill-advised use case. As such there is not going to be any nice to use workflow to acieve what you are trying to do. Still this doesn't mean that it won't be possible. Why ill-advised? What you're describing is a cyclic dependency between your main executable and your dll written in delphi. If you google for "cyclic dependency dll" you will usually get the advice to break your cylic dependency by splitting your code into more dlls. My personal experience shows the same. Cyclic dependencies in dlls are usually not worth the additional effort and hassle. Also you want to export things from your executable, which is also very uncommon. What you should be doing is having 2 dlls and one executable. You have one common library written in D that is build into a dll. Then you have your delphi library which uses the common.dll. Finally you have your main executable written in D which uses both the common.dll and your delphi.dll. This should make it possibly to break the cycle and get you an easy setup. If you absolutley must do it the way you describe it, its still possible. You will have to compile all modules that export something from your executable with the "-c -shared" parameters. E.g. dmd -m64 -c -shared moduleThatExports1.d moduleThatExports2.d -ofexports.obj Now you link the resulting exports.obj file into your executable by calling dmd again dmd -m64 restOfModules.d exports.obj delphi.lib -ofmain.exe Finally you have to get the handle to your main executable by calling HMODULE handle; GetModuleHandleExA(0, null, &handle); in your delphi dll and then fetching the function pointer for each and every function you want to call from delphi via: GetProcAddress(handle, "mangeledFunctionSymbol") Now finally you can call these functions pointers from delphi and they will call into the D code within your executable. Instead of all that hassle you could instead just have a function in your delphi dll: void recieveFunctionPointer(const(char)* name, void* ptr); which you call for every function that you want to make available from D to delphi. Your delphi code then stores away these pointers depending on the name. That way you don't need to export anything from your executable and can build it normally. Instead of having a function call per function you could obviosuly also use a struct that is defined the same way in D and delphi and contains all relevant functions pointers.
Thanks for your deep analysis. There are several reasons I want to have the exe as Delphi application: 1) I faced some minor (Delphi) IDE/Libraries bugs with having the Delphi gui within a dll. 2) The Delphi IDE provides you the possibility to e.g. easily change the exe icon/attach additional resources to the exe, ... 3) Delphi lets you also create android/iPhone applications. I assume there will be no other way than place the D coding within a shared object for this scenario. I completely agree with you, it is mad. My gut feeling is, you have the greatest benefit from the IDE and convenience if the executable is written in Delphi. I try to support both ways in my library, so the developer can decide. Kind regards Andre
Jan 09
parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Tuesday, 9 January 2018 at 20:07:03 UTC, Andre Pany wrote:
 On Tuesday, 9 January 2018 at 18:32:24 UTC, Benjamin Thaut 
 wrote:
 Thanks for your deep analysis. There are several reasons I want 
 to have the exe as Delphi application:
 1) I faced some minor (Delphi) IDE/Libraries bugs with having 
 the Delphi gui within a dll.
 2) The Delphi IDE provides you the possibility to e.g. easily 
 change the exe icon/attach additional resources to the exe, ...
 3) Delphi lets you also create android/iPhone applications. I 
 assume there will be no other way than place the D coding 
 within a shared object for this scenario.
I wrote a mixed language app with interdependent components (no D though). The exe is minimal and does not export anything, its main function is practically a one liner that calls into one of the DLLs; but it could contain a lot more. First only the export library is built for component 1. With it, component 2 is built completely, giving a DLL and export lib. Now the DLL for component 1 can be built and the exe. I don’t know if this is possible in your case, but you may be able to have a Delphi exe wth the things that must be there but no exports, then have a Delphi DLL and D DLL with exports to each other. Not sure if it would make a difference, but this construction works well for us.
Jan 09
prev sibling parent reply Domain <dont_email empty.com> writes:
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
Jan 09
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
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
Jan 10
parent reply Domain <dont_email empty.com> writes:
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
Jan 10
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
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
Jan 10
next sibling parent reply Domain <dont_email empty.com> writes:
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_617 70TQDmZQFwFNfLQDxZv 中被引用 app.obj : error LNK2019: 无法解析的外部符号 _D6object__T8__equalsTxaTxaZQqFNaNbNiNfAxaQdZb,该符号在函数 _D3std5array__T8AppenderTAyaZQo4Data11__xopEqualsFKxSQBzQBy__TQ vTQBpZQCdQBqKxQBaZb 中被引用 app.obj : error LNK2019: 无法解析的外部符号 _D3std12experimental6logger4core14globalLogLevelFNdNiNfZEQCdQCcQBrQBn8LogLevel 该符号在函数 _D3std12experimental6logger4core6Logger__T15memLogFunctionsVEQChQCgQBvQBr8LogLeveli64Z__T7logImplVii9VAyaa5_6170702e64VQra8_6170702e6d61696eVQBna15_766f6964206170702e6d61696e2829VQCza3_6170 0TQDmZQEdMFNfLQDyZv 中被引用 app.obj : error LNK2019: 无法解析的外部符号 _D3std11concurrency7thisTidFNdNfZSQBgQBf3Tid,该符号在函数 _D3std12experimental6logger4core6Logger__T15memLogFunctionsVEQChQCgQBvQBr8LogLeveli64Z__T7logImplVii9VAyaa5_6170702e64VQra8_6170702e6d61696eVQBna15_766f6964206170702e6d61696e2829VQCza3_6170 0TQDmZQEdMFNfLQDyZv 中被引用 app.obj : error LNK2019: 无法解析的外部符号 _D3std8datetime8timezone9LocalTime6opCallFNaNbNeZyCQBxQBwQBqQ k,该符号在函 数 _D3std12experimental6logger4core6Logger__T15memLogFunctionsVEQChQCgQBvQBr8LogLeveli64Z__T7logImplVii9VAyaa5_6170702e64VQra8_6170702e6d61696eVQBna15_766f6964206170702e6d61696e2829VQCza3_6170 0TQDmZQEdMFNfLQDyZv 中被引用 app.obj : error LNK2019: 无法解析的外部符号 _D3std12experimental6logger4core8MsgRange6__ctorMFNcNfCQCbQCaQBpQBl6LoggerZSQCwQCvQCkQCgQCe 该符号在函数 _D3std12experimental6logger4core6Logger__T15memLogFunctionsVEQChQCgQBvQBr8LogLeveli64Z__T7logImplVii9VAyaa5_6170702e64VQra8_6170702e6d61696eVQBna15_766f6964206170702e6d61696e2829VQCza3_6170 0TQDmZQEdMFNfLQDyZv 中被引用 app.obj : error LNK2019: 无法解析的外部符号 _D3std8datetime7systime7SysTime6__ctorMFNaNbNcNflyCQBxQBw8timezone8TimeZoneZSQCxQCwQCqQCl 该符号在函数 _D3std8datetime7systime5Clock__T8currTimeVE4core4time9ClockTypei0ZQBiFNfyCQCuQCt8timezone8TimeZon ZSQDuQDtQDn7SysTime 中被引用 app.obj : error LNK2019: 无法解析的外部符号 _D3std8datetime7systime17FILETIMEToStdTimeFNfMxPS4core3sys7windows7winbase8FILETIMEZl 该符号在函数 _D3std8datetime7systime5Clock__T11currStdTimeVE4core4time9Cl ckTypei0ZQBmFNdNeZl 中被引用 app.obj : error LNK2019: 无法解析的外部符号 _D3std12experimental6logger4core8MsgRange3putMFNfwZv,该符号在函数 _D3std5range10primitives__T5doPutTSQBh12experimental6logger4core8MsgRa geTaZQBxFNfKQBxKaZv 中被引用 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
Jan 10
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
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: 无法解析的外部符号 
 _D3std12experimental6logger4core17stdThreadLocalLogFNdNfZCQC
QCdQBsQBo6Logger, 
 该符号在函数 
 _D3std12experimental6logger4core__T18defaultLogFunctionVEQCdQCcQBrQBn8LogLeveli64Z__TQByVii9VAyaa5_6170702e64VQra8_6170702e6d61696eVQBna15_766f6964206170702e6d61696e2829VQCza3_617
70TQDmZQFwFNfLQDxZv 
 中被引用
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
Jan 11
next sibling parent Domain <dont_email empty.com> writes:
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.
Jan 11
prev sibling parent reply Domain <dont_email empty.com> writes:
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?
Jan 11
parent Benjamin Thaut <code benjamin-thaut.de> writes:
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
Jan 11
prev sibling parent Domain <dont_email empty.com> writes:
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
Jan 10