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