Wine on Solaris?

[Robert Lunnon]

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