Thread overview
Attempt to export ModuleInfo on Windows
November 15


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);
                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.

November 18

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.


November 25

Related bug (that I of course encountered that fixing this would enable fixing)