Tim Teulings wrote:
Hello!
I'm writing on a software that supports different (GUI) drivers for different OSs. "Driver" refferes to my software (GUI library) having different plugins (by implementing a subclass of an abstract base class) for different OSs. I have an X11 plugin for doing X11 calls on X11, one for Mac OS X, one for Curses and one for Windows. I now would like to compile the Windows specific classes of my library under Linux using Wine. The Windows version does use low level 2D graphics calls (WIN32). This works fine if using f.e. Cygwin as compiler environment under Windows (rest of the software is a little bit unix centric).
I now would like to use the Windows driver under Linux but I have a problem finding the correct linker call. This is more difficult, since I do not use C/C++ directly but another compiler that generates C code wich in turn gets compiled using gcc. So I cannot use winemaker, for which I found some documentation.
The Windows Version links explictely against kernel32, user32 and gdi32 DLLs. If I under Linux just leave them away and link only against wine (-lwine) I got unresolved symbols during linking for the Win32 API calls.
After that I tried to link against the <windowsdllname>.dll.so files I found (under /usr/libwine, using the Debian testing packages), too, since I assume that these contain the functions I use. But I cannot get the linker to find them. strace shows that it is always searching for lib<windowsdllname>.dll.so. For example it searches for libuser32.dll.so while I only have a user32.dll.so.
Is it correct, that I have to link explictely against this libraries? If yes, how can I get the linker to search for the correct names? If no, how to get my stuff to link?
Hi Tim,
I'm afraid I have some bad news for you. What you are trying to do is not as trivial as you took it to be.
The problem has to do with the fact that a winelib application (i.e. - an application that uses the Win32 API using Wine, compiled natively) requires much more than the static libraries. It requires a different loader, supporting services (such as registry and wineserver), etc. This means that wine will have to be installed for the win32 APIs to work, even if they were compiled into your app.
The other part of the problem is that we have been, as of yet, unable to make the entire construct work as a normal ELF executable. Instead, you have to load such an application (a winelib app) through a wrapper. When you use the wine build tools (winebuild, winemaker, winegcc), such a wrapper is automatically created for you. However, this means that your entire application must now be a winelib app. I'll leave it to the winelib masters to fill you in on the details of how one goes about doing that.
Shachar