My fault! and the reason is worth understanding in a slightly
wider context.
I'm importing into the new memory management related D source
files a D interface file obtained via htod and some tweaking from
the C header files associated with the C source I am modifying.
And that interface file, while perfectly correct and containing
nothing that shouldn't be in a C header file (specifically, no
function definitions) nevertheless needed to be compiled into an
object and added to the eventual link. Doing so eliminated the
problem entirely.
"Symbol Undefined _D2rt12__ModuleInfoZ" which I couldn't
unmangle, meant that there was a missing module called rt.
Presumably dmd put that symbol in the import section of the
object that was made with 'import rt' in its source to bring in
my interface file. Obvious from the symbol after the fact.
I was able to demangle the symbol in the following part of the
error message,
"Symbol Undefined
_D2rt6b_real11__xopEqualsUKxS2rt6b_realKxS2rt6b_realZb". It's the
mangled version of the following.
extern (C) bool rt.b_real.__xopEquals(ref const(rt.b_real), ref
const(rt.b_real))
This lead me to understand that the message
"Symbol Undefined _D2rt6b_real6__initZ" appears to be about an
initializer for the struct b_real that doesn't exist either.
Why optlink chose these particular missing symbols is somewhat
puzzling, as there are perhaps 50 or so structs in rt. And I do
not use an equality test with b_real in any way. I'd be curious
to know, as it would be nice to have a better handle on
decrypting the implications of error messages produced when
linking a 32 bit windows program built with dmd fails.
