At 02:32 AM 11/1/2005, Molle Bestefich wrote:
Rob D wrote:
Solaris is like the red-headed step child of the Wine world.
What an odd remark.. What does that mean?
After perusing Robert Lunnons patchkit for hints to resolve build issues, it would appear that most of the issues that keep Wine from building on Solaris are known, but for whatever reason, do not get accepted into the main stream source.
I know that Solaris does several things quite different than most *nix implementations, but perhaps due to the limited use of Solaris, the powers that be resist putting in extra tests to support a small set of users.
That is just my quickly arrived at opinion based on a very short exposure to the environment, Sorry if I am misunderstanding the issues.
Rob Done
Rob D rddone@att.net writes:
After perusing Robert Lunnons patchkit for hints to resolve build issues, it would appear that most of the issues that keep Wine from building on Solaris are known, but for whatever reason, do not get accepted into the main stream source.
Any fix that is done cleanly is accepted. Ugly hacks and workarounds aren't, no matter whether they are for Solaris, FreeBSD or Linux.
I know that Solaris does several things quite different than most *nix implementations, but perhaps due to the limited use of Solaris, the powers that be resist putting in extra tests to support a small set of users.
Certainly not. I'd love to have better Solaris support, but the fact is that some of the issues like threading or ptrace are hard to solve properly. It has taken months of work to implement them on Linux, and it will probably take about the same amount of time for Solaris. So it's mostly an issue of lack of manpower on the Solaris side. Robert Lunnon is doing a lot of great work, but there is only so much a single person can do.
On Wednesday 02 November 2005 00:10, Alexandre Julliard wrote:
Rob D rddone@att.net writes:
After perusing Robert Lunnons patchkit for hints to resolve build issues, it would appear that most of the issues that keep Wine from building on Solaris are known, but for whatever reason, do not get accepted into the main stream source.
Any fix that is done cleanly is accepted. Ugly hacks and workarounds aren't, no matter whether they are for Solaris, FreeBSD or Linux.
I'd disagree, if there was an issue with linux that required an "Ugly hack or workaround" to make it work then it would get in. A great example is the current ugly workaround for ensuring memory is allocated below 0x80000000. I contend that ugly hacks for core functionality under Linux are allowed that are not allowed for other OSes
There are several things that were rejected simply because the design decisions I took were not considered acceptable. It is really not fair to characterise these as ugly hacks and workarounds.
Of the hundred or so patches I have developed and had under maintenance over he last couple of years there are only about 25 outstanding ones. The majority of these are in-development patches or deltas to the tools which allow me to customise the build process for my purposes. Only three patches (4 or 6 of the 25 diffs) are being maintained outside the Wine project because they were refused, it's just a pity they are so central to making Wine run under Solaris.
I know that Solaris does several things quite different than most *nix implementations, but perhaps due to the limited use of Solaris, the powers that be resist putting in extra tests to support a small set of users.
Certainly not. I'd love to have better Solaris support, but the fact is that some of the issues like threading or ptrace are hard to solve properly.
You better believe it, though the threading is a done deal and works perfectly on Solaris 10 and up. (ptrace is an absolute nightmare - I worked for a month and failed to get winedbg working due to a very obscure deadlock). Fortunately the solaris debugger (mdb) is very good at digging out Wine bugs. winedbg would be good to allow me to participate in application debugging, but it's not essential since I can use linux for that.
It has taken months of work to implement them on Linux, and it will probably take about the same amount of time for Solaris. So it's mostly an issue of lack of manpower on the Solaris side. Robert Lunnon is doing a lot of great work, but there is only so much a single person can do.
Thank you, I agree, I can't work full-time on it, so It gets attention sparodically when I generate a new package, and only as far as to get my two or three test applications working. If someone wants to pay me a salary to work full-time, I'd be happy to consider it. Solaris Wine needs lots of stuff done.
Robert Lunnon bobl@optushome.com.au writes:
I'd disagree, if there was an issue with linux that required an "Ugly hack or workaround" to make it work then it would get in. A great example is the current ugly workaround for ensuring memory is allocated below 0x80000000. I contend that ugly hacks for core functionality under Linux are allowed that are not allowed for other OSes
That's certainly not true. For instance we have the mmap_fixed hack for Solaris and BSD, that is surely a lot uglier than the Linux memory reservation thing, yet it got in.
Yes, sometimes there is no choice but to do things the ugly way, and in that case ugly stuff can get in. All you need to do is to convince me that there is no better solution. Whether it's on Solaris or Linux doesn't make any difference; there are tons of ugly hacks that have been rejected on Linux too.
"Rob D" rddone@att.net wrote:
After perusing Robert Lunnons patchkit for hints to resolve build issues, it would appear that most of the issues that keep Wine from building on Solaris are known, but for whatever reason, do not get accepted into the main stream source.
That patchset is mostly hacks which are not acceptable in its current form, and Robert is aware of it.
-
Alexandre Julliard -
Dmitry Timoshkov -
Rob D -
Robert Lunnon