On January 8, 2004 01:22 am, Robert Lunnon wrote:
Here are a buch of Solais compatibility patches for wine (Some but not all of them). Within the enclosed tarball the diffs are structured according to the wine cvs tree. There is a readme file accompanying each diff to explain what the change is.
Please break the archive into one patch per message, not compressed (preferably inlined). Here are a few pointers on how to send patches: http://www.winehq.org/site/sending_patches
BTW, what's the status of building Wine under Solaris? What architecture (i386, etc) are you using?
On Thursday 08 January 2004 17:51, Dimitrie O. Paun wrote:
On January 8, 2004 01:22 am, Robert Lunnon wrote:
Here are a buch of Solais compatibility patches for wine (Some but not all of them). Within the enclosed tarball the diffs are structured according to the wine cvs tree. There is a readme file accompanying each diff to explain what the change is.
Please break the archive into one patch per message, not compressed (preferably inlined). Here are a few pointers on how to send patches: http://www.winehq.org/site/sending_patches
BTW, what's the status of building Wine under Solaris? What architecture (i386, etc) are you using?
There are quite a few patches in that kit, they are organised as separate patches for each file and a description to make application easy. After extracting you could construct a single liner that would apply the entire kit.
It would be relatively easy to send a dozen or so emails though, providing you don't want me to collect up the dependencies into a single e-mail
As for status:
Wine works quite well under Solaris x86 (Possibly better than linux based on my experience with 18062003) but can't be built and run successfully without two key patches that Alexandre has elected not to accept, and one patch which is probably acceptable but I haven't sent yet (not sure if the semantics of the code are correct for the OS yet). I also distribute it with some experimental threading code which seems to work better than the CVS code. Again the project has elected not to accept this code at this time due to it's present implementation (Because it's experimental I have arranged things to be able to select the threading model at runtime through an environment variable)
Hence my port is not a stock wine. I must maintain at least the critical patches locally to be able to offer wine under solaris. As per the (L)GPL the patches are all offered to the project and the diffs are distributed as a patch kit with the binary with a pointer to winehq for the rest of the source.
Right at this point I am trying to add cdrom support which is kinda tricky because the CDROM ioctl raw reading support is broken under Solaris x86 and you need to go right down to the SCSI level for raw read operations. Unfortunately this is restricted to root. But I'm doing it anyway for when it changes (less maintenance later).
Does this answer your questions, oh and should I resubmit the patches or will the kit do.
Bob
On Wed, 14 Jan 2004, Robert Lunnon wrote:
It would be relatively easy to send a dozen or so emails though, providing you don't want me to collect up the dependencies into a single e-mail
Well, a patch should be a logical atomic change, no matter how many files it touches. You can't for example have one patch use a new variable (say in a file.c), and another declare it (in header.h).
As for status:
Wine works quite well under Solaris x86 (Possibly better than linux based on my experience with 18062003) but can't be built and run successfully without two key patches that Alexandre has elected not to accept, and one patch which is probably acceptable but I haven't sent yet (not sure if the semantics of the code are correct for the OS yet).
The reason I'm interested in the status is that I'm trying to assemble a porting page for Wine. But that page has to refer to the stock Wine. Can you please tell me which DLLs don't build cleanly in the stock tree on Solaris?
Do you have any experience building Wine on Sparc?
Hence my port is not a stock wine. I must maintain at least the critical patches locally to be able to offer wine under solaris. As per the (L)GPL the patches are all offered to the project and the diffs are distributed as a patch kit with the binary with a pointer to winehq for the rest of the source.
Do you publish Solaris binaries regularly? If so, would you be interested in pushing them on SourceForge, with the rest of the other binary builds?
Does this answer your questions, oh and should I resubmit the patches or will the kit do.
For the purposes of getting them in the standard tree, I think you need to resubmit. I hope we can get the standard tree to build on Solaris soon.
Robert Lunnon bobl@optushome.com.au writes:
There are quite a few patches in that kit, they are organised as separate patches for each file and a description to make application easy. After extracting you could construct a single liner that would apply the entire kit.
Actually it doesn't make application easy, it's a pain to have to extract the tar, review everything, keep track of what has been applied or not, match up the changelogs, etc. The rule is one patch per mail, and there are many good reasons for that.
Does this answer your questions, oh and should I resubmit the patches or will the kit do.
Please resubmit, thanks.
-
Alexandre Julliard -
Dimitrie O. Paun -
Dimitrie O. Paun -
Robert Lunnon