Wine is not an emulator, but it is awesome

Posted: | Updated:

UPDATE 2, 2019-11-09:Since I initially posted this, Valve has released Proton and a whole lot has changed!

UPDATE 2015-09-25: It looks like wine-staging will soon be integrated into the main wine codebase!

Wine sometimes seems to get a bad wrap, but it really is an amazing project. With it, GNU/Linux users (and Mac users, too!) can run Windows applications - many of them nearly flawlessly. One thing I've found that's helped me get the most out of wine is to use the latest development versions. Debian and friends usually only keep stable releases in their repositories, so you can easily miss out on a lot.

If you aren't using a rolling-release distribution it can be hard to find up-to-date packages for your package manager. Or maybe it isn't exactly hard to find them, but I personally don't love adding 3rd party repositories (especially just for one package.)

But hey, this is free/open source software we're talking about, so why not just build and package it ourselves?! In the spirit of DIY, I'll go over installing the wine-staging patchset, compiling wine, and then finally, package it up into a deb. Get your compilers ready kids!

Getting ready

I'm working on a 32-bit Linux Mint Debian Edition system; your mileage may vary if this isn't what you use, but it should be fine as a guide for other distributions. I personally prefer to build on a VM, but that isn't necessary. Commands that start with a # mean they need to be ran as a superuser or with superuser privileges, commands starting with $ need to be ran as a regular non-privileged user. The version of wine I'll be building is 1.7.51.

You first need to make sure that source packages are enabled in your sources.list or similar. Here's what mine looks like:

deb betsy main upstream import
deb-src betsy main upstream import

deb jessie main contrib non-free
deb-src jessie main contrib non-free
deb jessie-updates main contrib non-free
deb-src jessie-updates main contrib non-free
deb jessie/updates main contrib non-free

deb jessie main non-free
deb-src jessie main non-free

deb betsy main
deb-src betsy main

Those are the lines starting with deb-src. Then, update:

# apt-get update

Next, install the required packages for building wine:

# apt-get build-dep wine
# apt install libcapi20-dev libgtk-3-dev libsane-dev ocl-icd-opencl-dev git libva-dev

This will get you everything you need to build a fully functioning wine. Now, we'll get the rest of the things we need to wrap everything up.

Build tools

It is with the aid of many build tools that this endeavor is even possible. We'll be using standard build tools along with some more specialized ones that will make creating the final .deb package a breeze.

Install the system package requirements:

# apt-get install build-essential git ruby

Then, use gem to install the ruby dependencies:

# gem install fpm lolcat

Note that lolcat isn't mandatory, but they make the experience better. You can also use something like rbenv instead of installing a system ruby, and that's totally cool too.

Get the code

Now's when you'll want to download the wine sources as well as the staging patchset. Make sure you're in the place you want to keep the sources in, if that matters to you, and also that you're not a superuser anymore:

$ cd ~
$ git clone git://
$ git clone

Then, check out the appropriate versions:

$ cd ~
$ cd ~/wine
$ git checkout wine-1.7.51
$ cd ~/wine-staging
$ git checkout v1.7.51

Now, we're ready to patch wine and build.

Patch and build!

And now, the action begins. First we need to apply the patches from wine-staging:

$ cd ~/wine-staging/patches
$ ./ --all DESTDIR=~/wine

With that we are ready to begin building wine, follow along:

$ mkdir wine1751
$ cd ~/wine
$ ./configure --prefix=${INSTALL_PREFIX}
$ let "j=$(cat /proc/cpuinfo | grep pro | wc -l) + 1"
$ make -j${j}
$ make install DESTDIR=${HOME}/wine1751

Here I'm programatically telling make to use all of your CPUs plus one, so if that's not what you want please feel free to omit the -j${j} bit from the above snippet. It will make the build go by more quickly, but at the expense of using all of your CPU.

And finally, we create our .deb package (this one's a doozy):

$ fpm -m -s dir -t deb -n "wine" -v 1.7.51 \
    -C ${HOME}/wine1751 -p ~/wine-full_VERSION-ITERATION_ARCH.deb \
    --category otherosfs --depends libasound2-plugins --depends libc6 \
    --depends libgstreamer-plugins-base0.10-0 --depends libfreetype6 \
    --depends libldap-2.4-2 --depends libmpg123-0 --depends libncurses5 \
    --depends libpng12-0 --depends x11-utils --description "${DESCRIPTION}" \
    --iteration 1 --provides libwine --provides libwine-capi \
    --provides libwine-gl --provides libwine-ldap --provides libwine-openal \
    --provides libwine-print --provides libwine-sane --provides wine32 \
    --provides wine-bin --provides wine-doc --provides wine-utils \
    --replaces libwine --replaces libwine-capi --replaces libwine-gl \
    --replaces libwine-ldap --replaces libwine-openal --replaces libwine-print \
    --replaces libwine-sane --replaces wine32 --replaces wine-bin \
    --replaces wine-doc --replaces wine-utils usr

To sum up what I'm doing here: we're telling fpm to make a package with the sources I just compiled, and I'm setting several flags to indicate which packages this .deb will depend on, provide, and replace. This allows for not only easy updating, but it will fully replace the "stock" wine from the repositories if you have that installed already. These will of course be different if you are using a different distribution (even Ubuntu may have different package names/versions, so beware!)

Note that I've omitted the $DESCRIPTION variable for brevity, but it is linked to below if you are curious.

Wrapping up

By now you should have a .deb file ready for installing. This process is repeatable, too, so when wine 1.7.52 comes out you'll be ready to package that as well!

One might argue that using fpm is "cheating", and perhaps if the goal was to build a package for submission into the official Debian repositories it might well be. At the very least it'd be doing it wrong. But for my purposes, and probably yours too (that is personal usage), fpm is not only just fine - it kicks ass!

The process outlined above is summarized in this shell script, which is essentially exactly what I run to get my new wine builds. I do a few things not described here, such as using rbenv to install ruby, but that's just a personal preference; the system ruby will be just fine for this purpose.

Of course, run it at your own risk! I've ran this several times and consider the process to be quite hardened, but nonetheless always exercise caution when running scripts posted online by others. Ah yes, that is another post for another day I guess. Or maybe for another blog? Who knows.

Thanks for reading!

This page was last modified on: 2019-11-09