Debugging advice
Matthew Bloch
matthew at bytemark.co.uk
Wed Oct 30 18:53:00 CST 2002
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
More information about the wine-devel
mailing list