Debugging advice

[Matthew Bloch]

Hi there;

I feel like I'm "nearly there" with porting this game to run with winelib, a 
version checked out from winehq CVS about a week ago.  Because I wanted my 
build system to be cross-platform, and WINE only as a stop-gap, I'm using the 
Jam build system and so can't directly take advantage of winemaker.  Plus I 
would rather learn and document how the build process works manually, since I 
can't find this information anywhere else.

Anyhow I now have the 400-odd source files compiling happily against my wine 
header files once I'd excised the need for Direct3D.  I have a directory full 
of object files with external references to Win32 functions and a WinMain 
function.

So to do the final linking step I've used (based on watching the example 
winemine build process):

$WINE/tools/winebuild/winebuild \
  -fPIC -DSTRICT -D_REENTRANT \
  -exe LSNClient.exe -mgui Builds/native-debug-linux/Source/*.o \
  -L$WINE/dlls -luser32 -lgdi32 -ladvapi32 -lkernel32 -lddraw -ldsound \
  -lwinmm -ldisplay -ldispdib >Source/LSNClient.exe.c

and then compiled & linked LSNClient.exe.c to the rest of the object files 
with the -shared flag, which leaves me with a shared library.  

Sideline: am I correct in thinking that winebuild's job is to scan the 
supplied object files for Win32 dependencies and construct the necessary glue 
code to load the needed .dll.so files?  What's the reason that the linking 
process can't correspond more closely to "normal" linking, i.e. where I could 
just supply -lddraw -lwine to my program to produce a final binary?

I then run ../wine/wine LSNClient.exe to try to run the game, and get this 
error:

err:module:BUILTIN32_LoadLibraryExA loaded .so but dll display.dll still not 
found - 16-bit dll or version conflict.
err:module:PE_fixup_imports Module (file) display.dll (which is needed by 
Y:\Work\Nemesis\LSNClient.exe) not found

Any idea what might be going wrong, or how I could diagnose it?  

More generally, the natively compiled .exe runs okay (if grindingly slowly, 
and with a couple of display glitches) under the binary loader, but I assumed 
that if I could produce a native version I'd be avoiding a lot of overhead 
and make my debugging job easier since I could use familiar GNU tools to 
debug my portability code as I wrote it.  What efficiency gains will I make 
compiling a native "shared library exe" with gcc as opposed to just compiling 
with Visual C and running it under the normal WINE binary loader?  I'm 
interested in how the latter works efficiently, so any advice in this 
direction would be appreciated-- I've thought on more than one occasion that 
maybe I should skip the WINE stop-gap and port it to SDL all at once, but the 
idea of being able to gradually wean the game off Win32 is appealing.

cheers,

-- 
Matthew Bloch         Bytemark Computer Consulting Limited
                                http://www.bytemark.co.uk/
                                  tel. +44 (0) 8707 455026