Matthew Bloch <matthew(a)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.
--
Alexandre Julliard
julliard(a)winehq.com