Debugging advice

[Alexandre Julliard]

Matthew Bloch <matthew at 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 at winehq.com