Symbol Undefined _D2rt12__ModuleInfoZ

Carl Sturtivant sturtivant at gmail.com
Mon Dec 9 17:58:29 PST 2013


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.


More information about the Digitalmars-d-learn mailing list