Matthew Bloch <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
