Hello,

I'm having another attempt at solving ModuleInfo not being exported on Windows.

This is an issue as it prevents D executable importing a D module in a DLL.

So far I've managed to get exported and added to the importedModules member, except:

Its being added as ModuleInfo**[] rather than ModuleInfo*[].

In dmodule.d ~364: Symbol* isym; /// Import version of csym

In toobj.d ~190 in the importedModules handling:

            import std.algorithm : canFind;
            if (mod.ident.toString().canFind("second")) {
                if (!mod.isym) {
                    mod.isym = s.toImport(mod.loc);
                    outdata(mod.isym);
                }
                s = mod.isym;
                //s.Sflags |= SFLweak;
                dtb.xoff(s, 0, TYnptr);
            } else {
                /* Weak references don't pull objects in from the library,
                 * they resolve to 0 if not pulled in by something else.
                 * Don't pull in a module just because it was imported.
                 */
                s.Sflags |= SFLweak;
                dtb.xoff(s, 0, TYnptr);
            }

And of course the export:

    objmod.export_symbol(m.csym, 0);

This is very frustrating, what should be quite simple, doesn't appear to be easily solved (by me) and is a massive blocker.

Note: in my above code I am hard coding it to only apply to the "second" module, to prevent needing to build druntime.

After doing some more work on my projects I ended up getting a very interesting error message with ldc:

sidero_image-test-unittest.obj : error LNK2019: unresolved external symbol __imp__D6sidero4base4hash5utils12__ModuleInfoZ referenced in function ldc.dllimport_relocation
sidero_image-test-unittest.obj : error LNK2019: unresolved external symbol __imp__D6sidero4base4hash3fnv12__ModuleInfoZ referenced in function ldc.dllimport_relocatio

What is interesting about this little error is that it is referencing the DllImport symbols from a ldc function. Generated from [0]. It's doing additional patching on top of the OS linker which is effectively dereference and set at start of runtime. This kinda rules out that it is simply a limitation of dmd and instead is a conceptual problem at the system linker & codegen level.

So what does this mean for dmd? Well, either we copy the solution from ldc or we do the patching as needed. I think patching as needed may be the best bet, but that means changing druntime in two places with an additional memory allocation when calling importedModules.

[0] https://github.com/ldc-developers/ldc/blob/03e35c5ce57e665e89f5ee2efeaffe958ba815d4/gen/passes/DLLImportRelocation.cpp#L183

Related bug (that I of course encountered that fixing this would enable fixing) https://issues.dlang.org/show_bug.cgi?id=6019