When compiling DWT apps with dmd 1.004 and 1.005, I get an error.  There is no problem with dmd 1.0 and earlier.  The problem is seen with the test_rowlayout.d example that comes with dwt.

This is the command line used:
dmd test_rowlayout.d -release -O -L/subsystem:windows:5 dwt.lib advapi32.lib comctl32.lib gdi32.lib shell32.lib comdlg32.lib ole32.lib phobos.lib user32_dwt.lib imm32_dwt.lib shell32_dwt.lib msimg32_dwt.lib usp10_dwt.lib gdi32_dwt.lib kernel32_dwt.lib olepro32_dwt.lib oleaut32_dwt.lib oleacc_dwt.lib uuid.lib -version=OLE_COM

This is the error:
Error 42: Symbol Undefined _D44TypeInfo_AC3dwt8graphics9rectangle9Rectangle6__initZ

The same error results if you compile with this command line:
build test_rowlayout.d -gui -clean -release -O -Xdwt -version=OLE_COM

The trick is to remove -Xdwt from the command line, which makes build recompile dwt itself.  But doing this every time you compile your app is slow.  It makes the executable bigger, too.

Is this a compiler bug, dwt bug, or just some unfortunate incompatibility?

On Sat, 10 Feb 2007 04:08:08 +0100, torhu wrote:

> When compiling DWT apps with dmd 1.004 and 1.005, I get an error.  There is no problem with dmd 1.0 and earlier.  The problem is seen with the test_rowlayout.d example that comes with dwt.
> 
> This is the command line used:
> dmd test_rowlayout.d -release -O -L/subsystem:windows:5 dwt.lib
> advapi32.lib comctl32.lib gdi32.lib shell32.lib comdlg32.lib ole32.lib
> phobos.lib user32_dwt.lib imm32_dwt.lib shell32_dwt.lib msimg32_dwt.lib
> usp10_dwt.lib gdi32_dwt.lib kernel32_dwt.lib olepro32_dwt.lib
> oleaut32_dwt.lib oleacc_dwt.lib uuid.lib -version=OLE_COM
> 
> This is the error:
> Error 42: Symbol Undefined
> _D44TypeInfo_AC3dwt8graphics9rectangle9Rectangle6__initZ

It could be caused by the fact that the linker only does a single pass on any given library or object file, so if a symbol is referenced prior to the library that contains the symbol has been processed, maybe the linker decides that it's an error and not wait until in might be resolved by the end of the linkage process.

By doing a full compile of DWT again, I think the linker is processing the object files and the libraries so it catches the early reference.

Try placing the another reference to the library that contains the item, earlier in the command line, so the library is actually used twice on the command line.


-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell

Derek Parnell wrote:
> It could be caused by the fact that the linker only does a single pass on
> any given library or object file, so if a symbol is referenced prior to the
> library that contains the symbol has been processed, maybe the linker
> decides that it's an error and not wait until in might be resolved by the
> end of the linkage process.
> By doing a full compile of DWT again, I think the linker is processing the
> object files and the libraries so it catches the early reference.

But the linker hasn't changed, so it has to be dmd that has changed.


> Try placing the another reference to the library that contains the item,
> earlier in the command line, so the library is actually used twice on the
> command line.

I tried this, but it doesn't make a difference.  Tried both bud 2.10, and 3.04.  Still dmd 1.005.

build dwt.lib test_rowlayout.d -gui -clean -release -O -Xdwt -version=OLE_COM

I've found that downgrading to DMD 0.177 solves issues. This is the version I've stuck with. I thought 1.0 was supposed to be better, oh well.

Most of the 1.0 series have had code generation issues, and now with 1.005 I guess fixed them but introduces non-1.0 features, but still includes an older issue (the one mentioned in this thread).

I have no idea what is the best version to use. None of them. I'm actually getting quite annoyed with D/DMD recently.

It is a pain in the ass trying to release code for others to use (libraries) because of all these issues, and I have a lot of libraries released, which cause me to have to support all these compiler bugs.

- Chris

torhu wrote:
> This is the error:
> Error 42: Symbol Undefined _D44TypeInfo_AC3dwt8graphics9rectangle9Rectangle6__initZ
> 
> The same error results if you compile with this command line:
> build test_rowlayout.d -gui -clean -release -O -Xdwt -version=OLE_COM
> 
> The trick is to remove -Xdwt from the command line, which makes build recompile dwt itself.  But doing this every time you compile your app is slow.  It makes the executable bigger, too.
> 
> Is this a compiler bug, dwt bug, or just some unfortunate incompatibility?

I installed dmd 1.001 and tried this again:

c:\prog\dmd\lib\dwt.lib(rowlayout)
 Error 42: Symbol Undefined _D44TypeInfo_AC3dwt8graphics9rectangle9Rectangle6__initZ

It's identical to the error 1.004 and 1.005 gave, so it would appear that this problem is caused by a change that happened in 1.001.

I tried to create a minimal example that would show this bug, but reducing test_rowlayout.d and dwt/widgets/display.d to a couple of lines each isn't enough.  It changes the error to this:

test_rowlayout.obj(test_rowlayout)
 Error 42: Symbol Undefined _D3dwt7widgets7display7Display7__ClassZ

Somewhere along the way, I got this error too:

c:\prog\dmd\lib\dwt.lib(imagelist)
 Error 42: Symbol Undefined _D40TypeInfo_PS3std1c7windows7windows6BITMAP6__initZ

More than these two files have to be involved for this to happen, it's not triggered if display.d isn't imported by other dwt modules.  That's expected, I guess.  So more work is needed to show exactly why this happens.

torhu wrote:
> torhu wrote:
>> This is the error:
>> Error 42: Symbol Undefined _D44TypeInfo_AC3dwt8graphics9rectangle9Rectangle6__initZ

These errors seems to be fixed by dmd 1.007. :D

My own dwt app increased in size by about 50k, it's now about 1MB.  Not a huge deal for my project.