What todo with stubs in Winlib
Winebuild would not recognize stubs for linking. So an app that runs under wine will not compile under winelib. ( stubbed functions are linked to but are not actually used). [Q] What should one do with all these stub functions? redefine them in a separate file? would it make any logic to tell winebuild - with a special switch - to link also to stubs? ( how hard is that hack?)
On Mon, 22 Sep 2003, Boaz Harrosh wrote:
Winebuild would not recognize stubs for linking. So an app that runs under wine will not compile under winelib. ( stubbed functions are linked to but are not actually used).
You'd have to provide manually written stubs. What functions are you missing? -- Dimi.
I must confess I am using a 2 month old wine but ... from wininet.dll: Gopher[*] InternetErrorDlg InternetSetFilePointer from rasapi32.dll RasSetEntryDialParamsA/W IsAsyncMoniker RasGetErrorStringA RasDialA RasGetConnectStatusA CreateAsyncBindCtx - this one is actually there only it is stubbed in the spec file and some others - I have MFC/ATL compiled. These and others get pulled in and I just wondered what every one is doing. and if we are at it I am using msvcrt(.dll) from wine (-isystem wine/msvcrt) - what does one do with "gethostname"? is there a WINE_ synonym for it? that I should -D for Thanks Free Life Boaz Dimitrie O. Paun wrote:
On Mon, 22 Sep 2003, Boaz Harrosh wrote:
Winebuild would not recognize stubs for linking. So an app that runs under wine will not compile under winelib. ( stubbed functions are linked to but are not actually used).
You'd have to provide manually written stubs. What functions are you missing?
On Mon, 22 Sep 2003, Boaz Harrosh wrote:
I must confess I am using a 2 month old wine but ...
from wininet.dll: Gopher[*] InternetErrorDlg InternetSetFilePointer
from rasapi32.dll RasSetEntryDialParamsA/W IsAsyncMoniker RasGetErrorStringA RasDialA RasGetConnectStatusA
Well, update to the latest wine, and write stub implementations for the ones that still need one.
CreateAsyncBindCtx - this one is actually there only it is stubbed in the spec file
Fix the spec file to point to the function.
and some others - I have MFC/ATL compiled. These and others get pulled in and I just wondered what every one is doing.
Can you share your experience compiling MFC/ATL? What did you need to change to MFC/ATL? What about Wine (hopefully nothing :))? What about the Makefile -- can you share it?
and if we are at it I am using msvcrt(.dll) from wine (-isystem wine/msvcrt) - what does one do with "gethostname"? is there a WINE_ synonym for it? that I should -D for
I know, this is a tough one -- I have run into it myself, but I haven't had the time t think about it yet. -- Dimi.
Le lun 22/09/2003 à 10:30, Boaz Harrosh a écrit :
Winebuild would not recognize stubs for linking. So an app that runs under wine will not compile under winelib. ( stubbed functions are linked to but are not actually used).
If it's a "real" stub (ie, one in the spec file), then the app won't correctly run under Wine, since when it'll call that stub it'll crash with a SIGSEGV (0xdeadbeef et al). Not sure if allowing them to link under winelib is correct here. For the other type (one labeled stub in the C files, which just print some TRACES), it's a real function, so nothing needs to be done.
[Q] What should one do with all these stub functions? redefine them in a separate file? would it make any logic to tell winebuild - with a special switch - to link also to stubs? ( how hard is that hack?)
Make a program (winebuild called) which checks for functions ld can't find, and create a corresponding stub in an additional source file. Problem is, you need the prototype for that, and since the prototypes are in the spec files, and for stubs the prototype is absent, you have a nice round problem. If implementing the real stubs to return error codes can make the app work under Wine, then you've just solved your problem. Vincent
participants (4)
-
Boaz Harrosh -
Dimitrie O. Paun -
Mike McCormack -
Vincent Béron