Wine on Solaris?
Greetings. I'm new to this forum, so bear with me... I'm trying o build 0.9 on Solaris 11 (nevada) and I'm running into some problems. The background is that I'm trying to run ComSoft, a win application to control the heatpump in my house. It uses serial comm, just plain 9600 bps, even parity. I tried to use the 20041104 version available on the Solaris 10 companion CD, but serial comm seems seriosuly broken on it, and I thought I'd better start with something more recent. I have added some missing sun-specific pieces from the 20041104 version as it was built by someone at Sun, and I have been able to build it, sort of. I'm running into problems when I try to start wine, where I get complaints about unresolved symbols, all of which are defined in the dll shared libraries. I'm puzzled by the naming of the shared libraries and I don't understand how they are spposed to be named and used. Take the kernel32 dll for instance. It is named /opt/sfw/lib/kernel32.dll.so, but during linking it is used as "-lkernel32", and at runtime no symbols are found. I'm trying to get in contact with the engineer at sun who built the version on the companion CD, but perhaps someone here can explain how it is supposed to work? Cheers, Thomas
Solaris is like the red-headed step child of the Wine world. There are several parts that dont build correctly on Solaris 8,9, or 10. Im pretty sure Solaris 11 is the same. Fortunately, Robert Lunnon has a website http://www.blastwave.org/wine/, that has several fixes for building Wine on Solaris 9 and 10. While you may not be able to use the patchkit for 10 directly, you may be able to use parts of it to deduce what needs to change to get it to compile. Thats what I had to do for 8. It worked fine for 9. The Wine for 10, (on the companion CD) worked fine for me on 10, with the exception of the RTLD_FIRST issue, but running the binary on 11 may present problems. At 01:52 PM 10/31/2005, you wrote:
Greetings.
I'm new to this forum, so bear with me...
I'm trying o build 0.9 on Solaris 11 (nevada) and I'm running into some problems.
The background is that I'm trying to run ComSoft, a win application to control the heatpump in my house. It uses serial comm, just plain 9600 bps, even parity. I tried to use the 20041104 version available on the Solaris 10 companion CD, but serial comm seems seriosuly broken on it, and I thought I'd better start with something more recent.
I have added some missing sun-specific pieces from the 20041104 version as it was built by someone at Sun, and I have been able to build it, sort of.
I'm running into problems when I try to start wine, where I get complaints about unresolved symbols, all of which are defined in the dll shared libraries.
I'm puzzled by the naming of the shared libraries and I don't understand how they are spposed to be named and used.
Take the kernel32 dll for instance. It is named /opt/sfw/lib/kernel32.dll.so, but during linking it is used as "-lkernel32", and at runtime no symbols are found.
I'm trying to get in contact with the engineer at sun who built the version on the companion CD, but perhaps someone here can explain how it is supposed to work?
Cheers, Thomas
Its me again. Ive been trying to figure how to get a (single) Wine application to be able to display dialogs on each of 3 monitors in a non xinerama setup (DISPLAY :0.0, :0.1, and :0.2). I am well aware that xinerama mode would allow this quite easily, but xinerama is not an option, partly since CDE on Solaris will not work in xinerama mode, and a little thing called Software Requirements Specification. I am also aware this isnt specifically a wine issue, but in researching what could be done about over the past week, I found several references to gdi_display, x11drv_thread_data, and various other constructs and class members in Wine that describe which display to use. This leads me to believe there is some method to allow Wine to enable the desired functionality. Whether the method to support this functionality is built in or needs to be coded, I have not yet determined, since nearly every file in dlls/x11drv directory uses these members and constructs. If someone has any insight on how to implement this or where I should focus my efforts, it would be very helpful. TIA Rob Done
On Mon, Oct 31, 2005 at 08:37:44PM -0700, Rob D wrote:
Its me again.
Ive been trying to figure how to get a (single) Wine application to be able to display dialogs on each of 3 monitors in a non xinerama setup (DISPLAY :0.0, :0.1, and :0.2).
I am well aware that xinerama mode would allow this quite easily, but xinerama is not an option, partly since CDE on Solaris will not work in xinerama mode, and a little thing called Software Requirements Specification.
I am also aware this isnt specifically a wine issue, but in researching what could be done about over the past week, I found several references to gdi_display, x11drv_thread_data, and various other constructs and class members in Wine that describe which display to use. This leads me to believe there is some method to allow Wine to enable the desired functionality.
The .x DISPLAY component is "Screen" in X11 speak. So far we have no special X11 Screen handling in our code as far as I know. I would also not know how to map the Windows API to X11 Screens :/ There are "WindowStations" Ciao, Marcus
At 02:39 AM 11/1/2005, Marcus Meissner wrote:
On Mon, Oct 31, 2005 at 08:37:44PM -0700, Rob D wrote:
Its me again.
Ive been trying to figure how to get a (single) Wine application to be
able
to display dialogs on each of 3 monitors in a non xinerama setup (DISPLAY :0.0, :0.1, and :0.2).
I am well aware that xinerama mode would allow this quite easily, but xinerama is not an option, partly since CDE on Solaris will not work in xinerama mode, and a little thing called Software Requirements Specification.
I am also aware this isnt specifically a wine issue, but in researching what could be done about over the past week, I found several references to gdi_display, x11drv_thread_data, and various other constructs and class members in Wine that describe which display to use. This leads me to believe there is some method to allow Wine to enable the desired functionality.
The .x DISPLAY component is "Screen" in X11 speak.
So far we have no special X11 Screen handling in our code as far as I know.
I would also not know how to map the Windows API to X11 Screens :/ There are "WindowStations"
Ciao, Marcus
Since alot of the Wine code refers to "thread_display" attributes, I spose I could try to create a separate helper thread for each display, each somehow kludged to link to a separate display at startup, and marshal display requests for each, but it seems that there could be an easier way. Rob Done
On Tuesday 01 November 2005 06:52, Thomas Tornblom wrote:
Greetings.
I'm new to this forum, so bear with me...
I'm trying o build 0.9 on Solaris 11 (nevada) and I'm running into some problems.
The background is that I'm trying to run ComSoft, a win application to control the heatpump in my house. It uses serial comm, just plain 9600 bps, even parity. I tried to use the 20041104 version available on the Solaris 10 companion CD, but serial comm seems seriosuly broken on it, and I thought I'd better start with something more recent.
I have added some missing sun-specific pieces from the 20041104 version as it was built by someone at Sun, and I have been able to build it, sort of.
I'm running into problems when I try to start wine, where I get complaints about unresolved symbols, all of which are defined in the dll shared libraries.
I'm puzzled by the naming of the shared libraries and I don't understand how they are spposed to be named and used.
Take the kernel32 dll for instance. It is named /opt/sfw/lib/kernel32.dll.so, but during linking it is used as "-lkernel32", and at runtime no symbols are found.
I'm trying to get in contact with the engineer at sun who built the version on the companion CD, but perhaps someone here can explain how it is supposed to work?
Cheers, Thomas
Actually, Sun used my kit for the companion CD. I spent a month or so working on it solving some X11 issues before it could be bundled. So the Sun engineers probably don't know a lot about it. Things have changed pretty radically since then and many of those changes will no longer apply or are already put back into the wine codebase. Despite being old and suffering the RTLD_FIRST and link traversal bugs which plague mostly rundll32 , that generation of Wine is probably one of the most robust available. Late versions of wine don't run some of my test programs that that version did. I hope to revisit these issues in an effort to equally stabilise 0.9 for Solaris. Anyway, the problem you describe is due to the Sun linker wanting to link main() from libwinecrt.a, It's a long story, but the patchkit now has a workaround that delivers two runtime startoffs, one for dlls, and one for exes that avoids binding with the main() in libwinecrt0.a which is where the unresolved symbols are. This will be maintained until I find a better solution. As you have already been advised (by others) you can get more up to date builds and the source patchkit from http://www.blastwave.org/wine. Bob
participants (5)
-
Marcus Meissner -
Molle Bestefich -
Rob D -
Robert Lunnon -
Thomas Tornblom