Mac OS X beta packages!
michael at fds-team.de
Thu Dec 31 19:54:48 CST 2015
we are happy to announce an initial version of our Mac OS X >= 10.8
builds. So far the packages have not yet received that much testing, so
please give them a try, and report any issues you encounter.
The packages are available at: https://dl.winehq.org/wine-builds/macosx
(Some mirrors don't show all files yet, just append random arguments to
the url like ?whereismypackage to trick the cache)
For unexperienced users, it is recommended to install Wine using the
*.pkg files. Just double-click on the package, and the usual Mac OS X
installer wizard should open. As pointed out by Austin, I am not a
registered Apple Developer and therefore the packages aren't signed.
This will result in an error if you configured gate keeper to block
unsigned packages. The installation itself should be self-explaining, so
I will not go into too much detail here. It is possible to install the
package either for all users (needs administrator privileges), or just
for your current user. If you haven't installed XQuartz >= 2.7.7 yet
(our package supports the x11drv as well as the macdrv), the installer
will complain. Just install the missing dependency, and restart the
installation, if this is the case.
After the installation is finished, you should find an entry "Wine
Staging" or "Wine Devel" in your Launchpad. By clicking on it, a new
Terminal window opens with a short introduction into some important wine
commands. You can now directly start wine/winecfg/... from the Terminal,
as the PATH variable is set correctly. For user convenience, the package
also associates itself with all *.exe files, which means you can run
windows executables just by double-clicking on them. This might not work
for all executables though, since OS X doesn't seem to pass the current
working directory to the "Open With" handler.
Some experienced users on the other hand might prefer a raw wine version
without those gimmicks, so we also provide tarball archives. They
basically contain the same files (except packaging related stuff), and
can be unpacked in any directory. There is no need to set DYLD_*
environment variables, all paths are relative, so it should work as long
as the directory structure is preserved (you can skip the /usr prefix
though using --strip-components 1). Also make sure to install XQuartz >=
2.7.7 in this case.
For those who are wondering, here a couple more technical aspects:
-------- Dependencies --------
The following dependencies are shipped as precompiled *.dylib-libraries
directly with Wine:
This is the patent free implementation of dxtn as used by many
linux distros. Only included in Wine Staging.
-------- Scripts --------
You can find all scripts and build files at
Those files allow you to build the packages on Debian Jessie as host
system, starting from a patched clang compiler (to support
ms_hook_prologue), tools necessary to create OS X packages, cross
compilation of the Wine build dependencies and finally cross compiles
Wine itself. You only have to provide MacOSX10.8.sdk.tar.xz and
xquartz-2.7.7.tar.xz, everything else is built from source. However, the
generated scripts are meant to be run inside our build VMs, so
realistically speaking it requires some effort to setup such a system
and is not suitable for an average user.
There are also some features I am planning to implement in the future
(depending on how much time I have):
-------- Auto updater --------
There is no common system to provide automatic updates for packages
besides the Store, so I think it would be good to come up with some
solution for this problem. Especially if the user installed the package
into his home directory, he could easily update it without entering a
password. I don't have much knowledge about objective-c or cocoa, so if
someone else wants to implement this, I am more then glad to add it as
an optional feature to the installer.
-------- Desktop integration --------
So far Wine does not create desktop entries that are shown in Launchpad,
but instead creates useless entries at ~/.local/share/applications/. I
think it shouldn't be too hard to dynamically create a proper entry at
~/Applications/ using a wrapper like I did for the main wine executable.
-------- Package signing? --------
This is basically something I could fix in 5 minutes, but I don't feel
like paying 99$/year if I basically don't use Mac OS X myself.
Happy new year and happy testing! :)
More information about the wine-devel