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.