Greetings,
I have heard that people are using Wine on Solaris. I would like to know if they are using Wine on the SPARC version or the x86 version of Solaris?
There does seem to be code within Wine to have it run on SPARC machines, but it currently does not seem to compile, at least on the Solaris version.
I have attached a small patch that allows me to get throught the 'make depend' section of the compile. Since it is my first patch, please look at and let me know what I did wrong :)
Have Fun! Chuck Hall
Chuck Hall wrote:
I have heard that people are using Wine on Solaris. I would like to know if they are using Wine on the SPARC version or the x86 version of Solaris?
I'm using it on the Sparc version, with Solaris 7 and 8. Winelib only, of course, none of the emulation stuff is going to work on Sparc.
There does seem to be code within Wine to have it run on SPARC machines, but it currently does not seem to compile, at least on the Solaris version.
Right now I'm using an old version of wine circa November 2004, and it needed a few minor fixes to work correctly. I'm in the process of upgrading to the latest & greatest, and unless there are major problems I plan on getting it working sometime this week. In the past, upgrades haven't been too much of a problem. When I get it working, I'll try to get my patches back to the wine-patches list promptly.
I posted my last batch of patches to wine-patches back on 2004-11-17, and I know some of them didn't make it into CVS. I also saw some patches posted to one of the wine lists around 2005-05-07 by Robert Lunnon with titles like "Solaris Compatibility" that you might want to look at. I don't know if his patches were for Sparc or x86, or if they've been accepted.
I have attached a small patch that allows me to get throught the 'make depend' section of the compile. Since it is my first patch, please look at and let me know what I did wrong :) [...] -#if defined(__GNUC__) && !defined(__MINGW32__) && !defined(__CYGWIN__) && !defined(__APPLE__) +#if defined(__GNUC__) && !defined(__MINGW32__) && !defined(__CYGWIN__) && !defined(__APPLE__) && !defined(__sparc__)
I haven't tried this with the current code, but in my working version of wine, I didn't make the same change. My port.h contains: === /* Macros to define assembler functions somewhat portably */
#if defined(__GNUC__) && !defined(__MINGW32__) && !defined(__CYGWIN__) && !defined(__APPLE__) # define __ASM_GLOBAL_FUNC(name,code) \ __asm__( ".text\n\t" \ ".align 4\n\t" \ ".globl " __ASM_NAME(#name) "\n\t" \ __ASM_FUNC(#name) "\n" \ __ASM_NAME(#name) ":\n\t" \ code \ "\n\t.previous" ); #else /* defined(__GNUC__) && !defined(__MINGW32__) && !defined(__APPLE__) */ === I'm not sure how to explain why this isn't working for you. I know we compile with a version of gcc that is configured to use the GNU assembler and GNU linker from binutils. Perhaps yours is using the native Solaris assembler, and it doesn't understand .previous? The assembly portions might only compile correctly with the GNU assembler.
Eric
On Mon, 23 May 2005, Eric Frias wrote:
Chuck Hall wrote:
I have heard that people are using Wine on Solaris. I would like to know if they are using Wine on the SPARC version or the x86 version of Solaris?
I'm using it on the Sparc version, with Solaris 7 and 8. Winelib only, of course, none of the emulation stuff is going to work on Sparc.
There does seem to be code within Wine to have it run on SPARC machines, but it currently does not seem to compile, at least on the Solaris version.
Right now I'm using an old version of wine circa November 2004, and it needed a few minor fixes to work correctly. I'm in the process of upgrading to the latest & greatest, and unless there are major problems I plan on getting it working sometime this week. In the past, upgrades haven't been too much of a problem. When I get it working, I'll try to get my patches back to the wine-patches list promptly.
I posted my last batch of patches to wine-patches back on 2004-11-17, and I know some of them didn't make it into CVS. I also saw some patches posted to one of the wine lists around 2005-05-07 by Robert Lunnon with titles like "Solaris Compatibility" that you might want to look at. I don't know if his patches were for Sparc or x86, or if they've been accepted.
From what I have read on the mailing list it does sounds as though he is
using Solaris on x86, but I did not find if he every did say that.
I have attached a small patch that allows me to get throught the 'make depend' section of the compile. Since it is my first patch, please look at and let me know what I did wrong :) [...] -#if defined(__GNUC__) && !defined(__MINGW32__) && !defined(__CYGWIN__) && !defined(__APPLE__) +#if defined(__GNUC__) && !defined(__MINGW32__) && !defined(__CYGWIN__) && !defined(__APPLE__) && !defined(__sparc__)
I haven't tried this with the current code, but in my working version of wine, I didn't make the same change. My port.h contains: === /* Macros to define assembler functions somewhat portably */
#if defined(__GNUC__) && !defined(__MINGW32__) && !defined(__CYGWIN__) && !defined(__APPLE__) # define __ASM_GLOBAL_FUNC(name,code) \ __asm__( ".text\n\t" \ ".align 4\n\t" \ ".globl " __ASM_NAME(#name) "\n\t" \ __ASM_FUNC(#name) "\n" \ __ASM_NAME(#name) ":\n\t" \ code \ "\n\t.previous" ); #else /* defined(__GNUC__) && !defined(__MINGW32__) && !defined(__APPLE__) */ === I'm not sure how to explain why this isn't working for you. I know we compile with a version of gcc that is configured to use the GNU assembler and GNU linker from binutils. Perhaps yours is using the native Solaris assembler, and it doesn't understand .previous? The assembly portions might only compile correctly with the GNU assembler.
I should have mentioned what tools I'm using and the why I sent the patch. I am using the native Sun assembler and linker. The Sun assembler does not understand the .previous so that is the reason for the patch.
Using the binutils from www.blastwave.org I managed to get only the first 5 files of 'make depend' to compile before it had problems with assembler. Seems to be easier to use the native version.
Chuck Hall wrote:
I should have mentioned what tools I'm using and the why I sent the patch. I am using the native Sun assembler and linker. The Sun assembler does not understand the .previous so that is the reason for the patch.
Makes sense. If you get the Sun assembler to work, we should probably make an autoconf test to check which assembler gcc is using. Heck, if you find that Sun's assembler doesn't work, it would be nice to have an autoconf check to put up an error. I don't know of a good way to do this check (aside from testing whether it understands .previous).
Using the binutils from www.blastwave.org I managed to get only the first 5 files of 'make depend' to compile before it had problems with assembler. Seems to be easier to use the native version.
Wine's README says: === Solaris info: You will most likely need to build Wine with the GNU toolchain (gcc, gas, etc.). Warning : installing gas does *not* ensure that it will be used by gcc. Recompiling gcc after installing gas or symlinking cc, as and ld to the gnu tools is said to be necessary. === If you want to compile with the native assembler, you may be in uncharted territory. I've had success with the combination of binutils-2.14 and gcc-3.4.2.
Eric
On Mon, 23 May 2005, Eric Frias wrote:
Chuck Hall wrote:
I should have mentioned what tools I'm using and the why I sent the patch. I am using the native Sun assembler and linker. The Sun assembler does not understand the .previous so that is the reason for the patch.
Makes sense. If you get the Sun assembler to work, we should probably make an autoconf test to check which assembler gcc is using. Heck, if you find that Sun's assembler doesn't work, it would be nice to have an autoconf check to put up an error. I don't know of a good way to do this check (aside from testing whether it understands .previous).
Guess that means I need to learn autoconf and related stuff.
Using the binutils from www.blastwave.org I managed to get only the first 5 files of 'make depend' to compile before it had problems with assembler. Seems to be easier to use the native version.
Wine's README says:
Solaris info: You will most likely need to build Wine with the GNU toolchain (gcc, gas, etc.). Warning : installing gas does *not* ensure that it will be used by gcc. Recompiling gcc after installing gas or symlinking cc, as and ld to the gnu tools is said to be necessary. === If you want to compile with the native assembler, you may be in uncharted territory. I've had success with the combination of binutils-2.14 and gcc-3.4.2.
When was the last time the Wine README was updated? Using the GNU toolchain I get a few more warning messages during 'make depend' but it does work. Gcc, gas, and gld need to be from the GNU toolchain, the rest seems to work as Solaris native.
You mentioned that you had patches for Wine on SPARC, would you mind sharing them or should I do a google search for them?
Chuck Hall wrote:
Guess that means I need to learn autoconf and related stuff.
I just want to make sure you understood that when Eric Frias wrote:
... Winelib only, of course, none of the emulation stuff is going to work on Sparc.
What that means is that you won't be able to run Windows programs on your Sparc, unless of course you have the source code and recompile them. As long as you do realize that, then have fun...
Chuck Hall wrote:
When was the last time the Wine README was updated?
It looks like this recommendation hasn't really changed since it was added in 2001. I'm guessing it still applies, though. For me, at least, it's was a lot easier to build a new compiler than to re-write the assembly sections.
Using the GNU toolchain I get a few more warning messages during 'make depend' but it does work.
Good. If that worked, you'll probably get through about 95% of the rest of the code without errors.
I do cheat when I'm building it, hacking the makefiles to avoid compiling oleaut32 and dllhelp; I think these had x86-specific code in them and I didn't need those libraries anyway.
Gcc, gas, and gld need to be from the GNU toolchain, the rest seems to work as Solaris native.
This is how I do things (with gld). From what I've gathered on the gcc mailing list, using gcc and gas with the native linker seems to be the preferred configuration. I've been meaning to try building with the native linker sometime, but I haven't gotten around to it since gnu's linker seems to work so well.
You mentioned that you had patches for Wine on SPARC, would you mind sharing them or should I do a google search for them?
I don't have an easy way to make a suitable patch -- it always takes a bit of work to separate the experimental changes I've made that others wouldn't be interested in from the important changes fixing real bugs.
For now, I'd suggest getting them from: http://www.winehq.org/hypermail/wine-patches/2004/11/author.html under 'Eric Frias'. There aren't too many.
That said, I'm not convinced those patches will be enough to get it working. I've been working on merging in all of my patches to the latest wine here, and there were a few conflicts. Some of those patches have already been applied, and one of the patches to winebuild I'm kind of worried about doesn't make sense anymore -- looks like the DLL import stuff moved from the data segment to the text segment. I don't know if that is going to cause problems on sparc or not...
I'll be trying to get the current wine running this afternoon; I'll post something when it's working.
Eric
On Wed, 25 May 2005, Eric Frias wrote:
Gcc, gas, and gld need to be from the GNU toolchain, the rest seems to work as Solaris native.
This is how I do things (with gld). From what I've gathered on the gcc mailing list, using gcc and gas with the native linker seems to be the preferred configuration. I've been meaning to try building with the native linker sometime, but I haven't gotten around to it since gnu's linker seems to work so well.
I will try it using the native ld and see what happens.
You mentioned that you had patches for Wine on SPARC, would you mind sharing them or should I do a google search for them?
I don't have an easy way to make a suitable patch -- it always takes a bit of work to separate the experimental changes I've made that others wouldn't be interested in from the important changes fixing real bugs.
For now, I'd suggest getting them from: http://www.winehq.org/hypermail/wine-patches/2004/11/author.html under 'Eric Frias'. There aren't too many.
That said, I'm not convinced those patches will be enough to get it working. I've been working on merging in all of my patches to the latest wine here, and there were a few conflicts. Some of those patches have already been applied, and one of the patches to winebuild I'm kind of worried about doesn't make sense anymore -- looks like the DLL import stuff moved from the data segment to the text segment. I don't know if that is going to cause problems on sparc or not...
I'll be trying to get the current wine running this afternoon; I'll post something when it's working.
I look forward to hearing how this turns out.
Chuck Hall wrote:
On Wed, 25 May 2005, Eric Frias wrote:
I'll be trying to get the current wine running this afternoon; I'll post something when it's working.
I look forward to hearing how this turns out.
It actually went more smoothly than I expected. I've attached a patch with the minimal changes I needed to get 'notepad' running. As you can see, I disabled winedbg, oleaut32, and dbghelp because they are missing some assembly bits, and they aren't strictly necessary for most winelib applications. I haven't tried compiling or running anything big with this, so it may be missing a few patches... but it's a start.
Eric
Index: programs/Makefile.in =================================================================== --- programs/Makefile.in (revision 30735) +++ programs/Makefile.in (working copy) @@ -27,7 +27,6 @@ winebrowser \ winecfg \ wineconsole \ - winedbg \ winefile \ winemenubuilder \ winemine \ @@ -58,7 +57,6 @@ winebrowser \ winecfg \ wineconsole \ - winedbg \ winefile \ winemenubuilder \ winemine \ @@ -81,7 +79,6 @@ winebrowser \ winecfg \ wineconsole \ - winedbg \ winefile \ winemine \ winepath \ @@ -112,7 +109,6 @@ winebrowser.exe$(DLLEXT) \ winecfg.exe$(DLLEXT) \ wineconsole.exe$(DLLEXT) \ - winedbg.exe$(DLLEXT) \ winefile.exe$(DLLEXT) \ winemenubuilder.exe$(DLLEXT) \ winemine.exe$(DLLEXT) \ Index: programs/winetest/Makefile.in =================================================================== --- programs/winetest/Makefile.in (revision 30735) +++ programs/winetest/Makefile.in (working copy) @@ -39,7 +39,6 @@ netapi32_test.exe$(DLLEXT) \ ntdll_test.exe$(DLLEXT) \ ole32_test.exe$(DLLEXT) \ - oleaut32_test.exe$(DLLEXT) \ psapi_test.exe$(DLLEXT) \ quartz_test.exe$(DLLEXT) \ rpcrt4_test.exe$(DLLEXT) \ Index: dlls/ntdll/signal_sparc.c =================================================================== --- dlls/ntdll/signal_sparc.c (revision 30735) +++ dlls/ntdll/signal_sparc.c (working copy) @@ -388,7 +388,7 @@
/* wait with 0 timeout, will only return once the thread is no longer suspended */ timeout.QuadPart = 0; - NTDLL_wait_for_multiple_objects( 0, NULL, 0, &timeout ); + NTDLL_wait_for_multiple_objects( 0, NULL, 0, &timeout, 0 ); }
Index: dlls/ole32/storage32.c =================================================================== --- dlls/ole32/storage32.c (revision 30735) +++ dlls/ole32/storage32.c (working copy) @@ -4130,8 +4130,8 @@ ULARGE_INTEGER tmp;
memcpy(&tmp, buffer + offset, sizeof(ULARGE_INTEGER)); - value->LowPart = htole32(tmp.HighPart); - value->HighPart = htole32(tmp.LowPart); + value->u.LowPart = htole32(tmp.u.HighPart); + value->u.HighPart = htole32(tmp.u.LowPart); #else memcpy(value, buffer + offset, sizeof(ULARGE_INTEGER)); #endif @@ -4143,8 +4143,8 @@ #ifdef WORDS_BIGENDIAN ULARGE_INTEGER tmp;
- tmp.LowPart = htole32(value->HighPart); - tmp.HighPart = htole32(value->LowPart); + tmp.u.LowPart = htole32(value->u.HighPart); + tmp.u.HighPart = htole32(value->u.LowPart); memcpy(buffer + offset, &tmp, sizeof(ULARGE_INTEGER)); #else memcpy(buffer + offset, value, sizeof(ULARGE_INTEGER)); Index: dlls/Makefile.in =================================================================== --- dlls/Makefile.in (revision 30735) +++ dlls/Makefile.in (working copy) @@ -36,7 +36,6 @@ d3dim \ d3drm \ d3dxof \ - dbghelp \ dciman32 \ devenum \ dinput \ @@ -100,7 +99,6 @@ odbccp32 \ ole32 \ oleacc \ - oleaut32 \ olecli \ oledlg \ olepro32 \ @@ -270,7 +268,6 @@ d3dim.dll.so \ d3drm.dll.so \ d3dxof.dll.so \ - dbghelp.dll.so \ dciman32.dll.so \ devenum.dll.so \ dinput.dll.so \ @@ -346,7 +343,6 @@ odbccp32.dll.so \ ole32.dll.so \ oleacc.dll.so \ - oleaut32.dll.so \ olecli32.dll.so \ oledlg.dll.so \ olepro32.dll.so \ Index: tools/winebuild/import.c =================================================================== --- tools/winebuild/import.c (revision 30735) +++ tools/winebuild/import.c (working copy) @@ -753,7 +753,11 @@ fprintf( outfile, "#ifndef __GNUC__\nstatic void __asm__dummy_import(void) {\n#endif\n\n" ); pos = (sizeof(void *) + 2*sizeof(unsigned int) + sizeof(const char *) + sizeof(void *)) * (nb_imm + 1); /* offset of imports.data from start of imports */ +#if defined(__sun) && defined(__sparc) + fprintf( outfile, "asm(".section\t\".data.rel.local\"\n\t.align %d\n"\n", get_alignment(8) ); +#else fprintf( outfile, "asm(".text\n\t.align %d\n"\n", get_alignment(8) ); +#endif fprintf( outfile, " "" __ASM_NAME("%s") ":\n"\n", import_thunks);
for (i = 0; i < nb_imports; i++) @@ -1057,7 +1061,11 @@ } output_function_size( outfile, delayed_import_loaders );
+#if defined(__sun) && defined(__sparc) + fprintf( outfile, "\n ".section\t\".data.rel\"\n\t.align %d\n"\n", get_alignment(8) ); +#else fprintf( outfile, "\n ".align %d\n"\n", get_alignment(8) ); +#endif fprintf( outfile, " "" __ASM_NAME("%s") ":\n"\n", delayed_import_thunks); pos = nb_delayed * 32; for (i = 0; i < nb_imports; i++)
As an end-user, I'd find any screenshots of notepad running amazing. :) Got any?
Hiji
--- Eric Frias efrias@syncad.com wrote:
Chuck Hall wrote:
On Wed, 25 May 2005, Eric Frias wrote:
I'll be trying to get the current wine running
this afternoon; I'll post
something when it's working.
I look forward to hearing how this turns out.
It actually went more smoothly than I expected. I've attached a patch with the minimal changes I needed to get 'notepad' running. As you can see, I disabled winedbg, oleaut32, and dbghelp because they are missing some assembly bits, and they aren't strictly necessary for most winelib applications. I haven't tried compiling or running anything big with this, so it may be missing a few patches... but it's a start.
Eric
Index: programs/Makefile.in
===================================================================
--- programs/Makefile.in (revision 30735) +++ programs/Makefile.in (working copy) @@ -27,7 +27,6 @@ winebrowser \ winecfg \ wineconsole \
- winedbg \ winefile \ winemenubuilder \ winemine \
@@ -58,7 +57,6 @@ winebrowser \ winecfg \ wineconsole \
- winedbg \ winefile \ winemenubuilder \ winemine \
@@ -81,7 +79,6 @@ winebrowser \ winecfg \ wineconsole \
- winedbg \ winefile \ winemine \ winepath \
@@ -112,7 +109,6 @@ winebrowser.exe$(DLLEXT) \ winecfg.exe$(DLLEXT) \ wineconsole.exe$(DLLEXT) \
- winedbg.exe$(DLLEXT) \ winefile.exe$(DLLEXT) \ winemenubuilder.exe$(DLLEXT) \ winemine.exe$(DLLEXT) \
Index: programs/winetest/Makefile.in
===================================================================
--- programs/winetest/Makefile.in (revision 30735) +++ programs/winetest/Makefile.in (working copy) @@ -39,7 +39,6 @@ netapi32_test.exe$(DLLEXT) \ ntdll_test.exe$(DLLEXT) \ ole32_test.exe$(DLLEXT) \
- oleaut32_test.exe$(DLLEXT) \ psapi_test.exe$(DLLEXT) \ quartz_test.exe$(DLLEXT) \ rpcrt4_test.exe$(DLLEXT) \
Index: dlls/ntdll/signal_sparc.c
===================================================================
--- dlls/ntdll/signal_sparc.c (revision 30735) +++ dlls/ntdll/signal_sparc.c (working copy) @@ -388,7 +388,7 @@
/* wait with 0 timeout, will only return oncethe thread is no longer suspended */ timeout.QuadPart = 0;
- NTDLL_wait_for_multiple_objects( 0, NULL, 0,
&timeout );
- NTDLL_wait_for_multiple_objects( 0, NULL, 0,
&timeout, 0 ); }
Index: dlls/ole32/storage32.c
===================================================================
--- dlls/ole32/storage32.c (revision 30735) +++ dlls/ole32/storage32.c (working copy) @@ -4130,8 +4130,8 @@ ULARGE_INTEGER tmp;
memcpy(&tmp, buffer + offset,sizeof(ULARGE_INTEGER));
- value->LowPart = htole32(tmp.HighPart);
- value->HighPart = htole32(tmp.LowPart);
- value->u.LowPart = htole32(tmp.u.HighPart);
- value->u.HighPart = htole32(tmp.u.LowPart);
#else memcpy(value, buffer + offset, sizeof(ULARGE_INTEGER)); #endif @@ -4143,8 +4143,8 @@ #ifdef WORDS_BIGENDIAN ULARGE_INTEGER tmp;
- tmp.LowPart = htole32(value->HighPart);
- tmp.HighPart = htole32(value->LowPart);
- tmp.u.LowPart = htole32(value->u.HighPart);
- tmp.u.HighPart = htole32(value->u.LowPart); memcpy(buffer + offset, &tmp,
sizeof(ULARGE_INTEGER)); #else memcpy(buffer + offset, value, sizeof(ULARGE_INTEGER)); Index: dlls/Makefile.in
===================================================================
--- dlls/Makefile.in (revision 30735) +++ dlls/Makefile.in (working copy) @@ -36,7 +36,6 @@ d3dim \ d3drm \ d3dxof \
- dbghelp \ dciman32 \ devenum \ dinput \
@@ -100,7 +99,6 @@ odbccp32 \ ole32 \ oleacc \
- oleaut32 \ olecli \ oledlg \ olepro32 \
@@ -270,7 +268,6 @@ d3dim.dll.so \ d3drm.dll.so \ d3dxof.dll.so \
- dbghelp.dll.so \ dciman32.dll.so \ devenum.dll.so \ dinput.dll.so \
@@ -346,7 +343,6 @@ odbccp32.dll.so \ ole32.dll.so \ oleacc.dll.so \
- oleaut32.dll.so \ olecli32.dll.so \ oledlg.dll.so \ olepro32.dll.so \
Index: tools/winebuild/import.c
===================================================================
--- tools/winebuild/import.c (revision 30735) +++ tools/winebuild/import.c (working copy) @@ -753,7 +753,11 @@ fprintf( outfile, "#ifndef __GNUC__\nstatic void __asm__dummy_import(void) {\n#endif\n\n" ); pos = (sizeof(void *) + 2*sizeof(unsigned int)
- sizeof(const char *) + sizeof(void *)) * (nb_imm + 1); /* offset of
imports.data from start of imports */ +#if defined(__sun) && defined(__sparc)
- fprintf( outfile,
"asm(".section\t\".data.rel.local\"\n\t.align
%d\n"\n", get_alignment(8) ); +#else fprintf( outfile, "asm(".text\n\t.align %d\n"\n", get_alignment(8) ); +#endif fprintf( outfile, " "" __ASM_NAME("%s") ":\n"\n", import_thunks);
for (i = 0; i < nb_imports; i++)@@ -1057,7 +1061,11 @@ } output_function_size( outfile, delayed_import_loaders );
+#if defined(__sun) && defined(__sparc)
- fprintf( outfile, "\n
".section\t\".data.rel\"\n\t.align %d\n"\n", get_alignment(8) ); +#else fprintf( outfile, "\n ".align %d\n"\n", get_alignment(8) ); +#endif fprintf( outfile, " "" __ASM_NAME("%s") ":\n"\n", delayed_import_thunks); pos = nb_delayed * 32; for (i = 0; i < nb_imports; i++)
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Tuesday 24 May 2005 05:56, Eric Frias wrote:
Chuck Hall wrote:
I should have mentioned what tools I'm using and the why I sent the patch. I am using the native Sun assembler and linker. The Sun assembler does not understand the .previous so that is the reason for the patch.
Makes sense. If you get the Sun assembler to work, we should probably make an autoconf test to check which assembler gcc is using. Heck, if you find that Sun's assembler doesn't work, it would be nice to have an autoconf check to put up an error. I don't know of a good way to do this check (aside from testing whether it understands .previous).
Using the binutils from www.blastwave.org I managed to get only the first 5 files of 'make depend' to compile before it had problems with assembler. Seems to be easier to use the native version.
Wine's README says:
Solaris info: You will most likely need to build Wine with the GNU toolchain (gcc, gas, etc.). Warning : installing gas does *not* ensure that it will be used by gcc. Recompiling gcc after installing gas or symlinking cc, as and ld to the gnu tools is said to be necessary. === If you want to compile with the native assembler, you may be in uncharted territory. I've had success with the combination of binutils-2.14 and gcc-3.4.2.
Eric
You all surmise correctly, I don't have a SPARC box so I haven't tested SPARC compatibility though the patches do handle some SPARC things. Since the API is the same all should work OK as far as syscalls go. Wine doesn't build out of the box though!, there are a couple of extra patches that you need to implement SYSV native threads on Solaris 10 or above and some stubs to make some other things work properly (like disabling the debugger and executing libs across a symlink containing a colon ). I publish a kit of patches with each binary I publish but I haven't republished the binary since the latest putback, many of them have now been rolled into CVS wine and are redundant. Some patches may never get in because Alexandre already rejected them. I think there are only one or two essential ones now. (send me an e-mail)
Good idea about the autoconf test for gas support, That's not hard to do, so I'll contribute this ASAP. Sun's as doesn't work (on x86 anyway) the operand orders are different to gas so it won't assemble as expected.
You don't need gnu ld at all, x86 Solaris ld works fine. My GCC is built to use gas + Solaris ld so I can use it to build kernel modules. Aside from libtool feeding it duplicate libraries in kde (which solaris ld doesn't like at all) I rarely have problems with that configuration. I'd recommend this gcc config.
Under x86 Solaris wine works pretty much on a Par with Linux, I even had a reported Success with Lotus Notes which was reported broken for Linux.
-
Chuck Hall -
Duane Clark -
Eric Frias -
Hiji -
Robert Lunnon