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 matthew@bytemark.co.uk writes:
$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
display and dispdib are 16-bit dlls, you shouldn't import them.
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?
That's because of differences between the ELF and PE binary formats. For instance, each Windows dll is in its own namespace, while ELF dlls share a single namespace; so we need to do linker tricks to simulate the PE behavior.
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?
There are basically no efficiency gains, there is no overhead in running a PE exe compared to a native one.
On Thursday 31 October 2002 01:14, you wrote:
Matthew Bloch matthew@bytemark.co.uk writes:
$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
display and dispdib are 16-bit dlls, you shouldn't import them.
Still does the same thing whether I include then on the winebuild cmd line or not. Could you explain what the error message "loaded .so but dll ... not found" means? What does display.dll do?
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?
There are basically no efficiency gains, there is no overhead in running a PE exe compared to a native one.
Okay, but presumably it's easier (as in not impossible!) for me to debug a program with GDB if I'm using a elf binary as opposed to a PE binary, which is mostly my object here.
thanks,
Matthew Bloch matthew@bytemark.co.uk writes:
Still does the same thing whether I include then on the winebuild cmd line or not. Could you explain what the error message "loaded .so but dll ... not found" means? What does display.dll do?
The message means that Wine is trying to load a 32-bit display.dll but doesn't find one (since display.dll.so is a 16-bit dll). I don't see how you could get that message if you don't import display; are you sure you cleaned/recompiled all the relevant files?
display.dll is the 16-bit display driver interface that some 16-bit apps expect to find loaded; you shouldn't need it at all.
Okay, but presumably it's easier (as in not impossible!) for me to debug a program with GDB if I'm using a elf binary as opposed to a PE binary, which is mostly my object here.
Yes of course, this is a good reason for using ELF (though the wine debugger should be able to debug the PE binary, especially if you have the symbols for it).
On Thu, 31 Oct 2002, Matthew Bloch wrote: [...]
There are basically no efficiency gains, there is no overhead in running a PE exe compared to a native one.
Okay, but presumably it's easier (as in not impossible!) for me to debug a program with GDB if I'm using a elf binary as opposed to a PE binary, which is mostly my object here.
But if you compile Winelib dlls as regular ELF libraries the application won't run so there is not much point. Besides, if you are using threads you cannot use gdb either because the Win32 threading is incompatible with gdb.
So you are stuck with winebuild and winedbg.
On Thursday 31 October 2002 1:53 am, Matthew Bloch wrote:
Okay, but presumably it's easier (as in not impossible!) for me to debug a program with GDB if I'm using a elf binary as opposed to a PE binary, which is mostly my object here.
gdb does have support for PEs (since there are Windows versions of gdb). Unix builds don't usually have it compiled in, though you only need to change one line of the gdb souce to enable it, see: http://groups.google.com/groups?hl=en&lr=&selm=6xUt8.14322%24sL6.203...
gdb doesn't support any of the debugging formats used by MS tools, but you can instead compile your program with a version of gcc that targets Win32 (some GNU/LInux distros have mingw32 as a package).
I made some notes about debugging threads this way here: http://www.winehq.com/hypermail/wine-devel/2002/06/0051.html
Alternatively, Eric Pouech made a gdb remote stub out of winedbg, see: http://www.winehq.com/hypermail/wine-patches/2002/07/0080.html http://www.winehq.com/hypermail/wine-patches/2002/07/0081.html
That's because of differences between the ELF and PE binary formats. For instance, each Windows dll is in its own namespace, while ELF dlls share a single namespace; so we need to do linker tricks to simulate the PE behavior.
Did anyone consider writing a different elf interpreter (normally ld.elf_so) so that a different method of handling the namespaces could be used?
I certainly found that (on netbsd) part of the reason for the slow start of programs like mozilla was the continual searching for symbols in all of the shared libraries that make up the program body (because they are searched for EVERY symbol).
David
-
Alexandre Julliard -
David Laight -
Francois Gouget -
Matthew Bloch -
Michael Wetherell