[Issue 22367] The __ModuleInfo member spuriously linked for modules compiler with -betterC

d-bugmail at puremagic.com d-bugmail at puremagic.com
Wed Nov 30 09:58:32 UTC 2022


https://issues.dlang.org/show_bug.cgi?id=22367

--- Comment #11 from Walter Bright <bugzilla at digitalmars.com> ---
mylib1.d has a static constructor in it. When does construction happen?

In C code, the C runtime takes care of it, in the order they appear to the
linker.

In D code, the D startup code takes care of it, *after* the C runtime does its
initializations, in depth-first order.

The two are different, and are irreconcilable (though most static constructors
probably don't care about the order, we can't really rely on that).

myexe.d has no way to know that it is importing a betterC module, so it can't
do the right thing with the construction.

So, I propose another solution. mylib1.d simply has to choose whether it wants
to do C construction or D construction. C construction would be:

    pragma(crt_constructor) extern (C) static this() { ... }

D construction would be:

    static this() { ... }

myexe.d, upon seeing the D static constructor, is going to expect a ModuleInfo
from mylib1.d. The compiler, when compiling mylib1.d with -betterC, and it sees
a D static constructor, can create a ModuleInfo for that static constructor.

The programmer creating a betterC library for both betterC and D programs,
would use:

    pragma(crt_constructor) extern (C) static this() { ... }

--


More information about the Digitalmars-d-bugs mailing list