Please consider packaging: Wine builds, runs with minor fixes

[allquixotic]

wine 1.9.11 (latest devel release) builds fine on SmartOS joyent zone, 32-bit, and here is proof (cmd.exe is a 32-bit Windows program running at the end there).

Build notes:

• Dependencies: (NOTE: this does not satisfy ALL wine optional dependencies, but should cover a vast number of both graphical and non-graphical use cases. It should technically build just with gettext pkg-config gmake gcc49 flex bison, but non-interactive programs that use the Win32 subsystem require X11 support to be enabled; I'd say the majority of Win32 executables are built for the Win32 subsystem whether they use a GUI or not.) --- modular-xorg-libs modular-xorg-protos gettext pkg-config gmake gcc49 flex bison libtool libjpeg-turbo tiff
• d3d9_36/tests/effects.c complains about a lack of the constant INFINITY. I just added to the top of the file as a quick hack:

#ifndef INFINITY
  #define INFINITY (1.0/0.0)
#endif

• ntdll/signal_i386.c: signal_i386.c needs to know the system's macros for the 32-bit registers. For us it's in /usr/include/sys/regset.h. There's an #ifdef _SCO_DS block that includes <sys/regset.h>, but it also does #define gregs regs, which we don't want (breaks the compile). Would be nice if we could add an #ifdef __sun block to only #include <sys/regset.h> but not #define gregs regs, unlike __SCO_DS.

These two changes are minor enough that upstream might be willing to accept some form of fix for them, though probably not the hackjob fixes I cooked up in 5 minutes after diagnosing the problems.

Caveats/challenges:

• To run 32-bit Windows binaries (Win32 / WoW64), you need a complete set of 32-bit system libraries and the ability to compile to 32-bit x86 code. We can run gcc -m32 on a 64-bit zone just fine, but I don't think we have the 32-bit system libraries in the 64-bit package set, do we?
• To run 64-bit Windows binaries (Win64), you need a complete set of 64-bit system libraries and pass the --enable-win64 flag to ./configure or ./autogen.sh. However, it is potentially desirable to enable running 32-bit binaries within a 64-bit instance of SmartOS. Ubuntu, Fedora, et al. solve this problem by having multiple architectures library support and have, e.g., 32-bit libs in /usr/lib and 64-bit libs in /usr/lib64. SmartOS would have to do something similar to be able to ship 32-bit Wine on 64-bit SmartOS instances, unless we were able to compile it statically and just ship the wine binaries including all the 32-bit dependencies in the final linked binaries.

Also, on Ubuntu and Fedora, somehow they have a multi-arch wine command that I think can run both 32-bit and 64-bit Windows binaries (that is, both Win32 and Win64) in a single binary. I'm not sure how this works (wrapper script, perhaps?) but I know it does require the dual 32-bit/64-bit libraries, so that would be a prerequisite at least (unless, again, we want to statically link the world and ship that).

Purpose

The purpose of getting wine running on SmartOS:

• Eliminate the reliance on LX branded zones running wine, or virtual machines, for running certain workloads that are only available as Windows binaries
• Empower SmartOS to natively do this without leaning on third-party ecosystems. While it's great that wine runs well on Ubuntu in an LX zone (or more slowly still on top of KVM), this allows us to start pulling people closer into using the SmartOS native platform more comprehensively for their workloads, instead of just using SmartOS's superior kernel and filesystem as a launching-off point for running other environments (like LX brands) to get actual work done.
• Due to the absence of a hypervisor, and the optimizations Wine has been working on for about a decade, performance is actually pretty good in a lot of scenarios. One possible use case for this monster is to run a proprietary, Windows-only dedicated server software on SmartOS, without having a Windows license and without having to go to LX->Wine or KVM->Linux->Wine.
• My totally unscientific claim is that native SmartOS->Wine would be faster than the alternatives, all except running it natively on Windows on bare metal... but many people might not need that last ounce of performance and would happily trade it for license freedom in the OS.

[mamash]

pkgsrc does have the previous Wine stable (1.6.2) and turns out I can make it build 32bit on SmartOS with just two minor modifications and run 'wine cmd' properly. I'll do that for the starters.

The next step would be to update it to the current 1.8 stable, where more work will likely be involved (must be a reason why nobody has cared to updated it in the past 2.5 years).