Solaris
From Wine-Wiki
Contents |
[edit] Solaris
Recently [Nov 08] Dan Kegel asked for help with patchwatcher, a script that checks patches by running the wine tests before they get into wine. If someone wants it checking patches for breakages on your favorite system, they should contact him.
Note: These comments are contain snippets from the mailing lists and are incomplete. This information should only viewed as a starting point for further research. Links are provide for those who wish to investigate further.
In Bug 15019 Aug 08: The old [Official] link to the Solaris binary is 404. There is a new link that should be used instead http://www.sunfreepacks.com/ And, [..] I would mention that Wine v. 1.1.3 actually works on Solaris 10. Earlier versions, although compiling and installing, seemed to work on OpenSolaris variants only and Solaris 10 was out-of-luck. Three or more recent fixes in 1.1.3 get Wine working on Solaris 10 as well as OpenSolaris
R. Lunnon: for [Wine 0.9] I have posted most of the patches that are likely to be essential to build a working Wine package (other than those previously rejected) regardless of the shape the code is in. Some of it is very ugly and lacks integration for other OSen, I have noted these. Since this code is maintained as a delta from CVS wine specific to Solaris and only used for binary packages, it's not necessary to start out with the niceties all there (This particularly happens when I get deep into week long debugging sessions).
Patches not sent are listed hereunder long with the reasons...
- Possibly essential (Show stoppers)
- ptrace stub patch - Disable debugger by returning error for all ptrace calls, add ptrace stubs (framework) to allow work on ptrace emulation layer for wine. -Previously rejected
- 33linking patch - since libwinecrt0.a was added wine has been broken due to the linker wanting to import main() in dlls, this results in unresolved symbols. I have temporarily worked around this and can build wine with a change to winegcc that links another archive (I call winedllcrt0.a) which omits the main() definitions in the case where -shared is passed to winegcc. Alexandre has asked that I keep looking for a way to make the Solaris linker successfully link an archive containing main() to dlls without the need to have two runtime startoff libraries. Patch won't be submitted until a final solution is found.
- Recommended functionality patches
- cpuid patch - CPUID detection using x86 cpuid instruction - previously rejected
- wineconsole/curses.c - Patch non-essential and FAR too hacky at this point - just removes all mouse code.
- Other Patches
- tools - automation patches to allow unattended build No interest to Wine project
- Debugger - work in progress, not working
A complete set of patches (even the gross ones) are maintained at http://www.blastwave.org/wine
The Sun Companion CD for Solaris 10 GA x86 has the 20041019 version of wine
R. Lunnon: [...] Things have changed pretty radically since Sun used [...] kit for the companion CD 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 [posted to the list] 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.
A Programmer asked: 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?
A. Julliard: 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.wine archive
R. Lunnon[May 05]: Wine doesn't build out of the box. 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.
He then said he would look into an idea about the autoconf test for gas support 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. Wine Archives
[edit] Solaris Troubleshooting
[edit] Sound
Johann Oskarsson [Jun 09] As of Build 115 of OpenSolaris, sound works with OSS. Tested with Wine 1.1.24.
R. Colenbrander [Jan 09] A couple of weeks ago there was a discussion in #winehackers about (open)solaris audio support. The discussion was started by two people who at the time were interested in updating wine's (open)solaris drivers. From what I remember it looked like the current wineaudioio driver is highly outdated and I believe the API has changed drastically. Those two guys said that Sun is working together with 4Front (from the commercial OSS) on some new audio system called 'Boomer' and which is also OSS compatible. I believe that our wineoss driver works fine. This page contains some more info and more links http://opensolaris.org/os/project/opensound/.
A. English: At least on OpenSolaris, audio is broken, last I checked (couple months ago). I had to install a manually compiled Esound (iirc) to get sound to work. Though it would still fail unless the sound server was started manually first...
[edit] Solaris Breakages Compiling Wine
B. Taylor wrote [Oct 07]: haven't built wine in a while, and ran into this on Solaris 10 J. Caben: Does the attached patch help? and the reply was: Yes. That works.
Mar 06 -- 06:59, 6 March 2006 (PST) Ashish Banerjee] We are compiling WineLib 0.9.9 on Solaris 10 (u name -a : SunOS unknown 5.10 Generic_118844-26 i86pc i386 i86pc) A dirty hack works, we neded had to redefine _FILE_OFFSET_BITS to 32 in file include/wine/port.h and also we had to change include/config.h (note: modify this file generated by ./c onfigure command, but before running the ma ke depend command) replace : #de fine HAVE_X11_EXTENSIONS_SHAPE_H 1 with #und ef HAVE_X11_EXTENSIONS_SHAPE_H and #de fine HAVE_ASCTIME_R 1
with
#und ef HAVE_ASCTIME_R Also define
#de fine MTSETBSIZ 256
In dlls/ntdll/directory.c we added:
#ifnd ef PATH_MAX
#defin e PATH_MAX 260
#e ndif
As of WineLib 0.9.9 the bug PT_GETREGS undeclared is not fixed. A code needs to be patched, this code is given there. Basically server/ptrace.c and server/context_i386.c are patched.
Nov 05 I'm on OpenSolaris B27, on an AMD 64 system, I'm getting these errors from the build. wine archive
l d: fatal: symbol `_environ' is multiply-defined: (file /usr/lib/crt1.o type=OBJT; file data.o type=OBJT); l d: fatal: File processing errors. No output written to msvcrt.dll.so
M. McCormack: There's probably an _environ defined in msvcrt and your libc. Have a look through the msvcrt code for the _environ symbol, and try change it to something like MSVCRT_environ. We do that for other symbols in msvcrt that conflict with glibc, so you should be able to find an example to copy.
R. Lunnon pointed out: [solaris] patches [are available] from http://www.blastwave.org/wine
April 05 OS: Solaris 10 3/05 release on x86
wine --version fixme:file:get_default_drive_device auto detection of DOS devices not supported on this platform Warning: the specified Windows directory L"c:\\windows" is not accessible. Warning: the specified System directory L"c:\\windows\\system" is not accessible... Wine 20041019
Note: This is an older version of Wine.
J.vonThadden:It is just complaining that it can not find a valid drive mapping for your home directory.
He then added: Use Winetools to do a proper setup. Note that it is not tested with solaris and may fail. You will need xdialog to use it (unless Solaris can execute Linux binaries, but you can get it for your platform also).Wine Archive Link
[edit] Compliling and SPARC
Dec 08 wine user a user reported a build failure with sparc and provided the errors:A. English replied: The sparc port is really out of date. You do realize wine for your OS is only useful for winelib, not to run any windows applications
Entering directory `/tmp/wine-1.1.11/libs/wine' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -DWINE_UNICODE_API fter-statement -Wwrite-strings - Wpointer-arith -g -O2 -o port.o port.c port.c:203:2: #error You must implement wine_switch_to_stack for your platform
A. English: If you want to get wine for Solaris/Sparc, you need to implement wine_switch_to_stack.
A. Sornes:Wine seems to be lacking some functionality required to deal with your processor. Have a look at libs/wine/port.c if you would like to implement it.
T. Rollo [Dec 05] reported an issue with NT headers: winegcc from the current WineHQ produces assembly output for SPARC systems that cannot be processed by the assembler.
- . "operation combines symbols in different segments" error.
- This problem arises because the imports code attempts to generate a relocation involving symbols in different segments (one in the text segment and one in the data segment). SPARC assemblers (including gas on a SPARC) cannot deal with relocations involving symbols in different segments. This only affects position independent code and can be avoided by changing the assembly code output in imports.c to something simpler.
- "can't resolve `_end' {*UND* section} - `.L__wine_spec_rva_base' {.data section}"
- This problem is more sinister. It arises from the same limitation as the first problem, but is not susceptible to being worked around. The offending code is the code that attempts to generate the NT header of the executable - specifically the SizeOfImage element.
A discussion ensued about several methods and ideas. E. Frias posted: I've attached the patches we're using for winebuild on SPARC. This fixes both of the problems you're encountering. I'm not sure if the fix is the right one, but it works quite nicely :-) We use gcc/gas. wine archive
[edit] gas
R Lunnon [July 05]:I Get assembly errors with the latest cvs, even with the very latest gas (2.16.1)
A. Julliard: winebuild is no longer using autoconf checks now that the platform can be set at run-time. You need to adapt the functions at the end of winebuild/utils.c, I put in some rough guesses but they are probably wrong for Solaris.
R. Lunnon: They probably will. There are two cases that need to be catered for on a runtime Solaris / OpenSolariss system, gcc linked with solaris as (Sunfreeware / GCC Default config ) and gcc linked with gnu as (which is now being supplied on the companion CD by Sun) such as is required to actually build wine. At runtime we cannot necessarily expect to get the same compiler wine was built with. For the moment its probably easier to require the config that is needed to build wine in the first place since most code will be written to this (AT&T vs Intel assembly also reverses the operand order of the assembler, swapping source and destination regs, I'm not sure gcc handles this in asm sections). This would make things the same as linux I think.
A. Julliard: The ideal case would be to have a #ifdef for which assembler is used so that the same generated code could compile on both, but I'm guessing gcc doesn't export anything of the kind right?
R. Lunnon: I could use a registry variable to decide so at least it could be setup at runtime. It's not hard to actually determine GCCs build and which as is used (I already did this for wines configure.ac) so this could be done on first run (like building the font metrics). I also dug in a bit more, the variations in util.c are not differences between Solaris as and gas but rather are differences between the x86 gas and the SPARC gas. GNU as for SPARC these days supports .string and .short so it's safe to use those for both x86 and SPARC. This is how I have handled this for the moment. I would still like to make winebuild as independent if I could. But this would mean more work, because Solaris AS doesn't support .short its .2byte instead. Wine Archive
C. Hall [May 05]: Wine currently does not seem to compile, at least on SPARC machines, with the Solaris version.
I have attached a small patch that allows me to get throught the 'make depend' section of the compile. [...] 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.
D. Clark: 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...
E. Frias: 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. [He then posted a patch that he used]
E. Frias also pointed to Wines' README: 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.
C. Hall: 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. Wine Archives
E. Frias: 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. 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.
After trying to get the current wine running in the afternoon he then posted: 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.Wine Archives
C. Hall identified a problem with lwp.h: Looking a bit deeper I found that the lwp.h for Solaris 9 is different from the one in Solaris 10 (which is what I am using). Based on this and something I read awhile ago, I belive that Sun is attempting to phase out the lwp stuff on Solaris.
E. Frias: I guess the correct thing to do here is just use the pthread model. It's probably safer to make pthread the default model on Solaris. I had it working well with my 6-month-old version of wine, so it shouldn't be too difficult to get it working with the current one. You'll need to add a section to configure.ac to tell it to build wine-pthread instead of wine-kthread [He then posted a quick example to the mailing list] Wine Archives
[ed. update. wine announcement approx may 09 notes - Get rid of the no longer supported wine-kthread. http://www.winehq.org/announce/1.1.17 ]
[edit] Missing String.h
A user reported: When I run the make command, the compiler gives me errors with the .rc files.
/opt/cfw/wine/programs/notepad2/dialog.c:380: undefined reference to `strcpy' /opt/cfw/wine/programs/notepad2/dialog.c:381: undefined reference to `strlen' [...] est -f notepad2 || install wineapploader notepad2 find: no es posible abrir notepad2: No existe tal archivo o directorio find: no es posible seguir enlace simb=F3lico /etc/wtmpx: No existe tal archivo o directorio install: wineapploader was not found anywhere! make: *** [notepad2.exe.so] Error 2
This error appears because I have not the include <string.h> line. Won't winelib link with this file when I compile? Im using this version of Wine: Wine-20030618.tar.gz in a Solaris 8 (SPARC). How can I know if winelib is correctly installed?
C. Hall: Did you install the development libaries when Solaris was installed? If you did not that would explain why you are not linking string.h. One other thing that might help is to try using the current release or CVS. Based on the date of the wine you are attempting to use, it has been almost 2 years, many changes have been done in that time. Winelib will not be installed if the make failed.
