www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Symbol Undefined _D2rt12__ModuleInfoZ

reply "Carl Sturtivant" <sturtivant gmail.com> writes:
I'm building a 32-bit windows executable using dmd 2.064.2, dmc 
(857 according to the file in its root directory, but when run it 
says 8.42n), and implicitly optlink. The executable is the a vm 
for an interpreted language.

The source is mainly C that I didn't write, but I successfully 
bolted a D front end on, making it a genuine windows program (not 
a console program) and got a working build that could achieve my 
main purpose: dynamically loading a DLL written in D and sync'ing 
the runtimes so there's only one GC (the one in the EXE). 
Everything builds and works perfectly at this point.

Now I've rewritten the memory management and allocation modules 
in D, and excluded the C ones from the build. And I get 
mysterious linker errors for the first time.

The command I'm using for the last step of the build and the 
reply from optlink are as follows.

=======================================
dmd -d -oficonx.exe dmain.d dmemmgt.d dalc.d   diconx.link 
iconx.def -L/map/noi

OPTLINK (R) for Win32  Release 8.00.13
Copyright (C) Digital Mars 1989-2010  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
iconx.obj(iconx)
  Error 42: Symbol Undefined _D2rt12__ModuleInfoZ
iconx.obj(iconx)
  Error 42: Symbol Undefined _D2rt6b_real6__initZ
iconx.obj(iconx)
  Error 42: Symbol Undefined 
_D2rt6b_real11__xopEqualsUKxS2rt6b_realKxS2rt6b_realZb
=======================================

diconx.link is just a list of the objects compiled earlier from 
the C source plus shell32.lib .

It seems that dmain.d , dmemmgt.d and dalc.d are being compiled 
by dmd into a single object iconx.obj . Running the Digital Mars 
librarian `lib -l iconx.obj` on that object produces iconx.lst 
which does not contain the symbols complained about above. And 
these three files contain the only D source. The rest is C.

Any advice about what's going on or what to do?
Dec 09 2013
parent reply "Carl Sturtivant" <sturtivant gmail.com> writes:
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.
Dec 09 2013
parent "Heinz" <thor587 yahoo.com> writes:
I always have the same problems (ModuleInfoZ, initZ, etc) when 
using import modules (.di files) wich i then have to include in 
the compilation process to get rid of linking errors. I do not 
know if this is the case.
Dec 10 2013