http://d.puremagic.com/issues/show_bug.cgi?id=6019

           Summary: Implicit linking with D DLLs doesn't work
           Product: D
           Version: D2
          Platform: Other
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: andrej.mitrovich@gmail.com


--- Comment #0 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2011-05-16 16:02:19 PDT ---
Test case: http://dl.dropbox.com/u/9218759/dll_bug.zip

Use the build.bat file or issue these commands:
cd dll
dmd -H -of..\mydll.dll -L/IMPLIB mydll.d
cd..
dmd driver.d -I. dll\mydll.lib

The exported D function is found by the linker, and you can find the name in the mydll.dll, mydll.lib, and driver.obj files, it has this name: _D3dll5mydll3fooFiZi

However DMD also generates a mydll.obj file which references this symbol: _D3dll5mydll12__ModuleInfoZ

This symbol isn't exported in the DLL and you won't find it in the import lib, and hence the linker error.

Daniel Green made a comment from this thread http://www.digitalmars.com/d/archives/digitalmars/D/learn/.di_header_imports_with_DLL_symbols_fails_to_link_25571.html:

"Probably unrelated, but this same issue showed up in the GDC backend. Apparently, the compiler tried to be smart about exporting ModuleInfo only for those modules that needed it.  The fix was to always export it regardless."

Note that you cannot just pass a .di header file directly to DMD because DMD will statically compile the mydll.foo function found in the header file, and the application won't need the DLL anymore.

You also cannot prototype the foo() function directly in driver.d, because this
function will be mangled together with its module name (mangled mydll.driver vs
mangled driver.foo).

The alternative is manually figuring out the mangling of the function name and using explicit linking via GetProcAddress & friends.

---------------

One more thing: Apparently in v2.053 linking with core.dll_helper doesn't work
anymore:
import core.dll_helper;
void main() {}

 Error 42: Symbol Undefined _D4core10dll_helper12__ModuleInfoZ
--- errorlevel 1

Is that a known issue? Linking with core.sys.windows.dll does work though.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6019



--- Comment #1 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2011-05-16 18:41:33 PDT ---
Also the guide which shows how to write and use D DLLs using a similar technique and .def files exhibits the same problem (and it also imports the non-existent std.gc module):

http://d-programming-language.org/dll.html

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6019



--- Comment #2 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2011-05-16 18:47:19 PDT ---
(In reply to comment #0)
> 
> One more thing: Apparently in v2.053 linking with core.dll_helper doesn't work
> anymore:
> import core.dll_helper;
> void main() {}
> 
>  Error 42: Symbol Undefined _D4core10dll_helper12__ModuleInfoZ
> --- errorlevel 1
> 
> Is that a known issue? Linking with core.sys.windows.dll does work though.

Disregard that. It seems I've had this module leftover from 2.052. That should teach me not to copy/paste new releases over old ones.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6019



--- Comment #3 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2011-05-17 15:29:33 PDT ---
Ok, I think I have found a very simple test case: http://dl.dropbox.com/u/9218759/dll_bugs.zip

The only difference between the two projects is that the one which does an import to a Phobos function will not compile. So I'm changing the title of this bug report.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6019



--- Comment #4 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2011-05-17 15:49:02 PDT ---
Freakin' hell.

Ok so I've ran it down to blaming the header generation.

Here's an example with a hand-generated .di header file versus automatically generated .di file. The hand-edited one is almost the same as the compiler generates it, except it has imports to Phobos *commented out*.

http://dl.dropbox.com/u/9218759/DLL_bug_test_case.zip

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6019


Rainer Schuetze <r.sagitario@gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |r.sagitario@gmx.de


--- Comment #5 from Rainer Schuetze <r.sagitario@gmx.de> 2011-05-17 23:53:29 PDT ---
The import in the di file tells the compiler that there are dependencies to other modules that need to be respected during module initialization. That's why they are placed into the module info.

I agree it is very annoying not to be able to use the generated di files (let alone the d files). Two possible solutions:

- add a switch to the compiler to only put exported symbols into the di file and leave out imports. This might make it difficult to compile this file if there are still references to symbols defined by the imports.

- add a modifier to the "import" declaration that avoids adding dependencies to the module info. (IIRC this has also been discussed to break cyclic module initialization.) If used in driver.d, it might even restrict imported symbols to the symbols marked "export" in the di file. If used for the imports of the generated di-file, it might break the correct init order when used for modules built to static libraries (as druntime).

BTW: I checked the generated object files: the buggy version also adds symbols _D47TypeInfo_S3std6traits15__T8DemangleTkZ8Demangle6__initZ and _D3std6traits15__T8DemangleTkZ8Demangle6__initZ. I don't know why this happens, but as these are comdats, they problably won't break anything.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6019



--- Comment #6 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2011-06-24 10:37:27 PDT ---
It seems another workaround for this is to create a dummy symbol in the module that imports a header file, e.g.:

extern(C) int D3dll5mydll12__ModuleInfoZ;  // implicitly adds _ before the name

This fixes linker errors. However it has to be put in the module that imports "dll.mydll", and not inside dll.mydll module itself as that creates some kind of symbol clashes.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6019



--- Comment #7 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2011-12-18 10:43:50 PST ---
Created an attachment (id=1054)
DLL Bug

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6019



--- Comment #8 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2011-12-18 10:44:25 PST ---
(In reply to comment #7)
> Created an attachment (id=1054) [details]
> DLL Bug

The other samples bit-rotted, newest one is in the attachment.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6019



--- Comment #9 from Martin Nowak <code@dawg.eu> 2013-10-02 04:42:10 PDT ---
*** Issue 9220 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------