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?
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
Hallo!
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.
Needing wine to run the compiler software would be OK for me. I do not have Windows myself and this would be the chance to work on and fix that part of my software under Linux. I do have Wine installed (was positivly suprised!. great job, great for running a little bit older games!), so that would not eb a problem.
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.
It seems like my Debian system is already configured to implictely start Wine if I choose to start a Windows program. That would not be a problem either.
What I would be interested to know. Can I get it running using the "normal" Linux gcc and by using (more or less tricky) different compiler/linker options for the Windows/Wine specific modules or is it even more complex. Can I use "normal" Linux and fore example X11 calls in the same binary or will I have problems with that?
Is there some documentation what exactly winemaker, winegcc and Co. do make? And is it possible that the problem I have is (partly) a pacating problem since I think I have already seen some compiler call examples just using for example -luser32 and that seemed to work. Or have I just missed that they called winegcc and not gcc?
* Tim Teulings rael@edge.ping.de [2004-02-18 22:31:26 +0100]:
<snip>
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
I guess you're talking about Oberon ? ;-)
cu
Hello!
<snip>
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
I guess you're talking about Oberon ? ;-)
Yes, Oberona nd VisualOberon are the keywords. We have a working Windows port because of some kind person who did it, but I would like to at check my changes in the plattform independent version against the Windows port without buying Windows.
* Tim Teulings rael@edge.ping.de [2004-02-20 07:26:04 +0100]:
<snip>
I guess you're talking about Oberon ? ;-)
Yes, Oberona nd VisualOberon are the keywords.
Hah, I knew there was something special about you :) (we've had a talk about VisualOberon and vmOberon quite a while ago)
We have a working Windows port because of some kind person who did it, but I would like to at check my changes in the plattform independent version against the Windows port without buying Windows.
hmm, does it run directly under wine ?
btw: its also long ago since my last release of vmoberon ...
cu
-
Enrico Weigelt -
rael＠edge.ping.de -
Shachar Shemesh -
Tim Teulings