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?
