Wine Regression Testing

Jump to: navigation, search
This article is part of the HOWTO series.
Installing Wine Business Games Internet Multimedia System and Utilities
Education Other

Warning: This HOWTO comes with no explicit or implicit warranty whatsoever. Use at you own risk!



If Wine stops working for you - you can help find the solution by doing Regression Testing.

Developers are continually improving Wine but because they are human, occasionally they make a mistake or even misunderstand how a aspect of Microsoft Windows is implemented. Sometimes, improvements show up an old bug which was previously hidden. However, Regression testing can identify the person who is at 'fault' and inform the developers which 'patch' caused your problem. Once that is found, almost half the work is now done, and often that means they can quickly get it working again. By catching these breakages early, their fixes are also often relatively easy. Not to be overlooked is that by identifying the developer, you can help it get fixed faster, because Developers take great pride in their work. When an error is found, they like to fix it. Regression Testing is important for the Wine project.

What is involved

Regression Testing involves downloading and compiling the code for wine, and with the help of a tool, locating when the program broke. This sounds scary for some, but is relatively easy. The developers work hard to make it easy for non technical people to run the test which will locate the offending patch. To find the patch that causes a bug, you mostly need the time to let your computer recompile wine. If in the rare case you need help, you can always get further assistance by emailing the wine-user mailing list. The tool simply says try this release of wine, and you say if it is ok or still broken. Then the tool suggests another version until we find when it broke. Too simple? Ah, but this tool is quite smart in suggesting what to try and will save you a lot of time.

The need for speed - how your efforts make a real difference

While a User who manages to locate a bug is likely to spend a few hours, this saves valuable time. Lets see an example, Keeping in mind that an experienced developer uses the same tools we use for regression testing: 20 different users find 12 bugs (We can likely expect that a few will turn out to be duplicates), with each user spending 2 hours. 2 hours each for 20 bugs? Why that is 40hours! Because we have done this, we have saved an experienced Wine developer a whole week of merely trying to identify these bugs! Because of our work, now he can wisely focus on actually fixing bugs and improving wine. And this is the reason why regression testing is requested when a breakage is found in wine. When we consider that there are [millions of computers using wine] and only a handful of developers, we can grasp the importance of trying to help the talented wine developers spend their efforts and as much as possible time of their time on actually fixing the bugs (rather than using up valuable time merely trying to locate bugs - using regression testing).

The Home Advantage

Because you know how to use your software and what it is supposed to do and look like, you can often quickly spot the problem. A developer who has never used your program will spend a lot of time merely trying to identify and replicate the bug. As one developer wrote:[jul09][..] if possible, could you verify it happens [...] (I could do that as well of course, but you know what to look for, and it would save me [..] time). [Italics added] The more time you can save a developer, the more time they can spend on identifying the solution to your bug. You will recompile and retest the application after every bisect.

Faster Checking of each Release for Bugs

For those pulling from Git, checking the almost daily updates, perhaps investigate Automated Regression Testing

Regression Testing for Wine

You will need to have an internet link and preferrably broadband. You can succeed with dialup, though a fair bit of patience is needed to download wine. If using dial up, you will likely wish to make the large download overnight. [update, since Sept 06, the official documentation now refers to using GIT for regression testing]. The first time you compile wine, takes the longest. Subsequent times are much faster, as not everything will be re compiled. How long does it take? Rayhen [ Oct 07] On modern hardware regression [testing] will took about 20-40 minutes (time depends on how big "window" of your regression test). On old hardware it will took more. If for some reason you cannot do regression test please fill bug report "as is". This is better than nothing and will take just a few minutes. However if you do regression testing, you will help yourself even more by assisting the developers who can quickly fix your problem.

Further Reading

The [ed: preferable] method is to run wine from it's source tree. This was described in Bug 1947 Aug 07: Call the wine binary out of your git directory, ie:

$ ~/wine-git/wine /path/to/app.exe

It makes git bisect easy and it's faster with not having to do "make install" first.

[Ed[ Dont worry about Fixme messages too much as these are not usually a sign of what broke. A fixme message is a note by a developer where something can be improved in the future, but as applications do not seem to rely on the behavior it will be done later.

If you do not want to use the very handy git tool called bisect, you might ask on the Wine Developer mailing list for suggestions of which dlls are likely to be involved with your regression and check those patches first, and manually regression test by date. Hiji [Jun 05]: Here's what I usually do [for manual regression testing]:

It's pretty clean and quick to reinstall previous version since it's already been compiled. Wine Archive

Further Reading

How far back can I test?

[based upon a wine post:] Testing should be done early, so that the programmer has the work fresh in his mind, and can quickly design a fix. Testing each version of Wine is Highly Recommended. It's probably not fruitful to go back more than 6 months or so - despite the developers best efforts there are some breakages in the Wine tree, and you're very likely to end up with something that doesn't work out of the box. The problems you'll encounter if you try are of course fixable, but:

If you do try to go farther back, you can

svn log <filename / dir name>


git whatchanged <filename/dir name>

to view patches relevant to any particular file or directory. Both is laborious, so if you do not have a time, going back further than 6 months is not for you.

A user tried to build an old version and in the discussion the following comments were found: S. Petreolle [May 06]: [wine] 2004xx or 2005xx are very old, and the whole configuration methods did change since it reached the 0.9.x stage.

W. Ogburn suggested when attempting to go back to very old versions: "make depend" and the "make" separately, so you know which one is the problem

J. Huizer: you should really get a known-good source (like one of the tarballs from one suggestion if you want to try more on the source you're using now - it sometimes helps to do a 'make distclean' and restart building, if you didn't clean up after the last compile error - though normally that happens at link time -- these errors are really at compile time, so I wouldn't bet on it [ users/2006-May/021458.html wine archive]

Using GIT for Regression Testing

Git is the new kid on the block. It has specialized commands that simplify regression testing. Since A. Julliard moved wine's development into git toward the end of 2005, it's popularity with wine's developers has increased. The download for git is surprisingly compact and relatively small, yet it contains wine development history. No more waiting to download each older version of wine.

M. McCormack [Nov 06]: It's much easier to use Git for regression testing. It will give you an exact commit ID which you can put in your bugzilla report.

P. Romanyszym [Nov 06 Wine user]: Using your package manager (RPM or APT) it would be difficult or impossible to set up different installed versions. So to run different versions you need to compile from source and run from the source tree of each version. Once you set up the required tool chain to compile you can do regression tests.

Finding regressions takes time to compile but that can happen in background while are using your system. Start with getting the Git tool working.

Once it is working from the wine source directory you can use the following to update your source to latest.

git-checkout -f

in the wine Source directory run ./configure --verbose It will spit out what is missing. Using that info find and install the missing libs.

Then to compile your source use:

./configure && make clean && make depend && make

[update 2010]

./configure && make

Regression Testing using GIT Bisect

Git has a tool to help regression testing called bisect

See the official link regarding regression testing using bisecting

F Delanoy: you can find a good explanation of git bisect => "man git-bisect" [open a terminal window and type it..and press enter. press q to exit the manual]

Dimesio wine user aug 08: If you got the message "0 revisions left to test" that means you have to run it one more time.

Jul 09: Say a dev submits a series of patches that rely on each other for something, such as communications. While doing git bisect, some of those patches end up on opposite sides of the bisect. This renders the program unable to communicate with the internet. What do you do in those cases?

Vitamin: First this really shouldn't happen. All patches are required to be atomic and not break any functionality within the series. Unfortunately this is not always the case and some patch series do break things if not fully applied In those cases you can [tell git to skip the patch causing the problem]:

git bisect skip

Git will pick a different commit to test. Hopefully the series that doesn't work for you is not the source of the regression.

Further Reading

Visualizing the Patches

L. Torvolds [Oct 09 git mailing list] I personally use "git bisect visualize" all the time when I bisect, but it turns out that that is not a very flexible model. Sometimes I want to do bisection based on all commits (no pathname limiting), but then visualize the current bisection tree with just a few pathnames because I _suspect_ those pathnames are involved in the problem but am not totally sure about them.

And at other times, I want to use other revision parsing logic, none of which is available with "git bisect visualize". [He then posted a patch for git] this adds "--bisect" as a revision parsing argument, and as a result it just works with all the normal logging tools. So now I can just do

gitk --bisect --simplify-by-decoration filename-here

Automating Regression Testing using Git Bisect

If you are able to test for the bug, you can automate the regression testing. You can test for the bug by writing a wine test or by using bash.

in Winehq Bugzilla entry 17917 one user automated this using a script to check for a regression which apparently introduced [] lines in the ini file. Jörg wrote [apr 09]:

This is the first time I could (partly) use git bisect run <script>, as the test was easy to automate (unlike failing apps). If anybody is interested:

#! /bin/sh
CC="ccache gcc" ./configure || exit 125
CC="ccache gcc" make depend all|| exit 125
rm -rf $HOME/.wine
./wine cmd /c echo hello || exit 125
fgrep -q '[]' $HOME/.wine/drive_c/windows/system.ini
test $? -eq 1

Another example of automating git for a broken vc2005 install was provided in Winehq Bugzilla entry 21010 [dec 09 by A. English]. He created a script called in the directory he was working it and then pasted the following:

set -x
rm -rf $HOME/.wine
./configure --without-mpg123 --disable-tests || exit 125
make -j4 || exit 125
WINE=$HOME/wine-git/wine winetricks -q -v vc2005express

Looking at this script, he removes his wine folder from his home directory, runs configure setting wine to be build without mpg123 and avoids building the tests. He has chosen make with -j4, which means he may have a two or four core processor. Then it uses winetricks to install vc2005, creating a wine directory under users' the home folder. Bash�s exit status is the exit status of the last command executed in the script.

He then started off bisect by specifying a working known version of wine to start with and running bisect using his script called

git bisect start HEAD wine-1.1.20
git bisect run ./

Testing Bisect Results

A user reported Winehq Bugzilla entry 17050 anyway, heres my result:

34aa6b7002af0155c6f0cc31a013391b17f62eea is first bad commit commit
34aa6b7002af0155c6f0cc31a013391b17f62eea Author: Michael Karcher
[redacted] Date:   Sun Aug 17 19:03:24 2008 +0200
kernel32: Fix profile cache logic and don't cache new files.

is there a way I can doublecheck if this commit is the bad one? the last four tests were good, this are my last "bad" one ...

N. Sivov: You could 'git revert' it, then build again and test.

This was done by a user in Winehq Bugzilla entry 18040

~/source/wine$ git bisect bad
014c4bfc70a4d4e60f033d579d1be13a46f65170 is first bad commit commit
014c4bfc70a4d4e60f033d579d1be13a46f65170 Author: Stefan D�singer
<redactedemail> Date:   Thu Apr 9 18:40:57 2009 +0200
wined3d: Save some memory in vertex buffers.

ok i was running regression test first time in my life[..] just testing with : git bisect start dlls/wined3d and ended up with that specific commit

A. English: That looks right. To be sure, try: (Should fail)

git reset --hard 014c4bfc70a4d4e60f033d579d1be13a46f65170 $ ./configure && make depend && make

Then try (without the patch):

git show 014c4bfc70a4d4e60f033d579d1be13a46f65170 | patch -p1 -R $ ./configure && make depend && make

and retest. If it works, then that's definitely the patch.

Playing with git

M. Finagin [Sept 06]: What I do is to follow along with things on the shortlog:;a=shortlog

Lets say you want to move your current branch to my recent patch "riched20: Rewrite of scrolling and some redrawing code." - you'd click the link "commit" to the right of it. In the page that you'll be taken to, you'll see a line like this: commit abecd9e393925e008449a80ec14682790b29042c

you can then do a "git reset --hard abecd9e393925e008449a80ec14682790b29042c"

and your git will be moved to the point in time right after that commit. If you then want to manually apply a patch, click "commitdiff" to the right of it's entry in the shortlog, followed by "plain" on the top - this will take you to a plaintext diff of the patch, which you could save to a file and apply with the patch command. ("patch -p1 < thepatch.diff" usualy works well for me)

M. McCormack [Sept 06]: There's easier ways to do the second bit.

  1. Use git cherry-pick
    git branch master-20060913
    git reset --hard abecd9e393925e00
    (#examine the log for commits)
    git log master-20060913..abecd9e39392
    (#pull in commits)
    git cherry -r 112810a480aaee4d6d8
    git cherry -r aaca30cf039c227e
  2. Use git format-patch to get all the patches in the tree before
    put them all in one file named mb)
    git format-patch --stdout abecd9e39392 > mb
    or create multiple files)
    git format-patch abecd9e393925e008
    Then reset (remember to have a clean tree!)
    git reset --hard abecd9e393925e
    Then edit "mb" and "git am" the patches you want:
    git am mb

You don't need the full SHA1 ID... just enough to make it unique in the tree. wine archive

Multiple Processors and Git

This is an advanced task - so if you are new to git, skip this part From the Git Mailing List

Q1:if you have a multiple core computer, can't you make git build new versions in the background while testing the previuos version? Alright, if you build 2 versions, one of them will never be tested, but you will perhaps save some time by letting it build in the background?

A1Yes, you can do that. If you have cloned your repository twice (or more), then you can bisect compile and test at the same time in your 3 repositories (or more if you really want).

For example if bisecting in one repo asks you to test revision X, then you can bisect and then build (and even maybe start testing) in another repo assuming revision X is good, and in yet in another one assuming revision X is bad.

(In the repo where you assume X is good you use:

"git bisect start CURRENT-BAD X"

and in the third one, where you assume X is bad, you use:

"git bisect start X CURRENT-GOOD")

A2 In fact, you have to give all the good revisions you have, not just the last one. So it should be

"git bisect start CURRENT-BAD X GOOD1 GOOD2 ..."


"git bisect start X GOOD1 GOOD2 ..."

instead of the above.

> When you know that X was good then you can kill the build or test processes and "git bisect reset" in the repository where you assumed

> wrongly X was bad. You can then assume something else with "git bisect start B G" and build and test in this repo again.

Above also you must give all the good ones, so it is:

"git bisect start B G1 G2..."

> In the repo that told you X was good, then you need only to use "git bisect good" or "git bisect bad" without building and testing to assume

> something about the revision that should be built and tested.

A3: Adding parallelism to a binary search scales very badly -- I'd say about logarithmically, but I haven't thought hard about it. If it's possible to use the extra cores to speed up the build+test cycle, that's vastly preferable.

A4: Probably logarithmically with the number of cores. But for reasonable machines, this number is relatively low, so the log is not so costly.

Applying a patch using GIT

A user asked: I add [a patch Diffed against 1d40bf0141b7f67b1188555962698f5dab631bc3] to to my local wine copy, using git ?

Krasuckus: I'd make some experimental branch or "master" or defined commit, then patch it with given diff, and commit the changes under single name. [One of the benefits of GIT is that is easily allows you to make throwaway branches]

  1. download the patch
    $ bunzip2 --keep origin_sd1.diff.bz2
  2. Use GIT
    $ git branch ntoskrnl 1d40bf0141b7f67b1188555962698f5dab631bc3
    $ git branch
    $ git checkout ntoskrnl
    $ git branch
  3. [...]instruct git to add [the] newly created files [to the throwaway branch]
    $ cat origin_sd1.diff | patch -p1 | awk '{print $3}' | xargs git-update-index --add
    $ tools/make_requests
    $ git commit -a -m "ntoskrnl: Experimental implementation."
  4. recompile Wine
    $ ./configure && make depend && make && tools/wineprefixcreate
    --use-wine-tree .
    • below goes your experiments
    $ ...
  5. and here we go back to the normal tree [Returning to the Official Wine tree]
    $ git checkout master
  6. recompile Wine
    $ ./configure && make depend && make && tools/wineprefixcreate
    • use-wine-tree and do our stuff
    $ ...

M. McCormack: If the patch is created with "git format-message" [instead of using git commit -a -m....], you can use "git am origin_sd1.diff" to add it to your tree. 'am' applies a mailbox, which is a series of patches and their commit info.

J.W. Stolk: I noticed [in these instructions] that the typical "make install" is missing. I ran ./wine-git/programs/winecfg/winecfg and it seems to work ok. I found more info about this in an old Wine newsletter: And a script to setup the correct wine variables without installing wine. General_Developer_Information#Running_Wine_from_its_source_tree wine archive

Using CVS for regression testing - no longer supported

Because Wine now uses GIT this means CVS is less recommended and is not supported since 2010. However, with some work GIT can pretend to be CVS so this is not ruled out. While you can still use what ever you feel you are comfortable with, GIT is preferred. Because CVS was so common, there may be old time users able to help with questions posted in the wine-users mailing list

For those wanting to do regression testing, it can enable to find who and what caused the breakage with wine. However, GIT is the preferred method and has more tools suitable for regression testing.

In the example below you will have a folder in your home directory called "wine" which will contain the wine tree. After using the commandline to "cd" into where you stored the Wine tree, you can then use the other cvs commands.

Further Reading

Using CVS to obtain a complete wine tree - obsolete

D. Clark: The easy way to use CVS is to: 1 Create the file ~/.cvspass ('~' refers to your home directory) containing the single line:

:pserver:[email protected]:/home/wine Ah<Z

2 Create the file ~/.cvsrc containing three lines (using your favourite editor):

cvs -z 3
update -PAd
diff -up

3 Type the command in a terminal window:

cvs checkout wine

Assuming a reasonably fast internet connection, you should have a complete wine tree in a few minutes.

Using CVS to Check Patches - obsolete

[based on advice and information for a bug report (link below) by D. Clark] CVS can go back and forward in time easily. If for example the 20050111 version is ok and the 20050419 version is broken, pick a day midway between those two, and do a CVS update:

cvs update -D "2005-02-27 CDT"

Compile that and see whether it is broken. If it is, pick a day midway between then and 20050111 (Jan 11 2005). If not, pick a day midway between that and 20050419. You should be able to narrow it down to a particular day fairly quickly. Once you have narrowed it down to a specific day, then review the patches for that particular day here and pick a patch roughly in the middle. For example, on the Jan 14 2005 it looks like the one with the time stamp of "Fri Jan 14 2005 - 10:09:34 CST" is roughly in the middle. So you could execute the command:

cvs update -D "2005-01-15 10:09:00CST"

Since the January patches use the "CST" timezone, be sure to use that when running CVS or the results will be confusing. You can then shift the time back and forth to find the exact patch that caused the problem. Once you use the commandline to "cd" into the Wine tree, you can just execute the cvs update commands.

D. Navea had difficulty with getting CVs to update backwards [Nov 05]: follownig the instructions on the regression testing page... The instructions are quoted with (aka double quote), but for my cvs to do it, it has to be ' (aka single quote). wine archive

Using your Brower to view CVS Commits

D. Calvio [Dec 05]: The wine-cvs archive mailing list linked in the documentation is This archive ends in August 2005. I think the archive linked should be

J. Hawkins [Dec 05] pointed out that the pipermail list has changed and now has the entries relevant to GIT. To check the entries for CVS :

Troubleshooting using CVS

Why does the 'cvs login' command tells me this:
cvs login: can only use `login' command with the 'pserver' method
cvs [login aborted]: CVSROOT: /home/chimi/wine

D. Clark: I think that the step you missed was that you need to "cd" into your top level Wine directory. Once you are there, the CVS commands will figure out that you want to operate on that CVS tree.

Where do I define my wine repository?
Your "repository" is the Wine tree you already downloaded via CVS

where do I define the cvs server

This was defined in ~/.cvspass. Once you cd into the Wine directory, CVS will know the correct server to use.

why does the 'cvs login' command tells me this

You don't need to do a cvs login. The ~/.cvspass does this for you. Once you cd into the Wine tree, you can just execute the cvs update commands.

How do I locate the next patch

D. Calvio [Dec 05]: the date [shown in the patches] isn't the CVS commit date. Instead, it is the Git commit date (or at least I think so). The Git to CVS gateway seems to get some time to commit the changes to the CVS. So I don't know how can I get the exact patch that caused the problem.

I'll try to explain it with my problem. When I update the CVS to "2005-12-21 21:29:02 +0100", the game runs perfectly. However, if I update the CVS to "2005-12-21 21:29:03 +0100", it crashes. However, looking in the [git] mailing list, there are no commits at "2005-12-21 21:29:03 +0100" (the previous was made at "2005-12-21 21:19:47 +0100").

M. Meissner: There is a CVS commit that has:

revision 1.24
date: 2005-12-21 21:29:03 +0100; author: julliard; state: Exp; lines: +2 -0
msvcrt: Implemented wctime(), wasctime().
Free thread data in DLL_THREAD_DETACH.

So you are looking for this:

Its likely that there is a delay between the GIT commit and the CVS integration.[...]([In this case] 1 hour before approximately)

J. Hawkins [Dec 05] pointed out that the pipermail list has changed and now has the entries for GIT. To check the entries for CVS :

M. Meissner: [to examine the] log for a file [write on the command line]:

cvs log file.c

to see diff between dates wine archive:

cvs diff -u -D "time1" -D "time2"

The command should be invoked in the directory which differences want to be seen, so to see all the differences in the CVS it should be invoked in your wine root directory. This command also outputs what directories are being checked. This information can be annoying, and can be ommited to get only the diffs with the -Q option:

cvs -Q diff -u -D "time1" -D "time2"

Once a difference between two revisions of a file is shown, you can get the associated patch information looking for the newest revision of the file in the log command for this file. And when you have the patch information, simply look for it in the git mailing list.

Cannot find module
A programmer reported during regression testing [APR 06]: [I] want to checkout for the patch submitted 05:20:20, I run the command:

[redacted]@r32_1600$ cvs -d $CVSROOT checkout wine "2005-09-21 05:20 CDT"

which ends up returning:

cvs checkout: cannot find module `2005-09-21 05:20:20 CDT' - ignored

I would like to be able to determine which patch specifically is responsible. Any help with CVS would be useful here.

S. Leichter wine archive:

export CVSROOT=:pserver:[email protected]:/home/wine cvs -d $CVSROOT checkout -D "2005-09-21 05:20 CDT" wine

How do I apply or remove a patch
If you sent a bug report and a developer asks you to test a patch, here is how:

To apply a patch, use a command like:

patch -p0 < patch.diff

To reverse a patch:

patch -p0 -R < patch.diff

The "-p0" can differ depending on how the patch was formed. For example, the patches in CVS generally require "-p1" instead of "-p0". Read the patch man page to understand what that is doing.

[Then recompile wine...]

further reading

Using Subversion

Consider Subversion if you are familiar with it, or feel like trying something different. However, because all Wine development is done using git, you will likely be better off using git.

Using Subversion to obtain a complete wine tree

M. Bestefich: I'd do it like this:

svn checkout --revision "{2005-06-06}" svn:// wine-svn
make depend
make install
svn update --revision "{}"

and go to step 3.

With 231 days in between, you will do a maximum of 8 iterations, then you'll have your bug pinpointed to a day. There's usually ~50 ? patches a day, so you'll want to list them:

svn log --quiet --revision "{2005-06-06}:{2005-06-07}"

lists patches from June 6th, 2005.

Pick a patch in the middle and run (example)

svn update --revision 20664

(the correct number will be in the output of the 'log' command). Iterate a few times more and you'll soon have the exact patch that breaks things.

Then it's time to go ask the developers what's going on. Or look at the log entry with svn log --revision XXX and go ask the guy that's mentioned in the log entry what the devil he was thinking.

Offline Subversion

If you have limited access to the internet you could ask Troy to zip up the SVN repository (either a couple of database files or ~23.000 revision files, depends..), dump 'em in a directory on your local pc and run 'svnserve --daemon .' in that directory. After that, point your working copy to your local repository (svn://localhost/). Then you'd be able to take a brisk walk back and forth in Wine versions without being on the 'Net.

Compiling Wine

First of all - if you have not already, install gcc, flex, bison, mesa-libGLU-devel and ccache.

Fedora10 users would type (using the y flag to avoid having to agree to each package)

yum install -y gcc ccache flex bison mesa-libGLU-devel


After noting some have difficulties in recompiling M. Meissener said the correct sequence is :

make clean
cvs up 
./configure ...
make depend

[because] After [a] "cvs update" it no longer new how to clean the tree. Wine Archive

R. Jensen explained [Oct 05] why make clean is sometimes necessary: it does make the build take longer, however, if the makefiles are altered it's too late to 'make clean' after_ the cvs update. [...] The other suggestion to this error was to delete the entire tree and pull an new CVS down from the net.

As you get closer to finding the bug, you could quickly check over wine patches for makefile changes so as to avoid using make clean unless really necessary. These changes are not very common but do occour.

To see what "make clean" would delete (hopefully without actually deleting anything) try:

make clean RM='@echo would-rm'

Further Reading


Some claim that it may be hard to get all the parts of wine that are needed to compile wine, but that is not necessarily true. If you install a Wine source package it will install these for you. After you uninstall it you should still have all the dependencies already set up.

If you are really stuck, then carefully check the configure error messages and keep installing the packages that are listed as needed.

Further Reading

Speeding up Compiling Wine

With an older computer it can take quite a while to compile wine. But there are things that you can do to speed it up.

Basically you are doing for wine is ./configure && make depend && make && make install, however this includes the wine tests which if you are merely doing regression testing, which is not necessarily needed. Regression testing is faster by disabling the tests, using ccache, forcing configure , make and make depend to be silent and dropping make install. However this means you need to be careful in case there is an error with configure or make etc. So if you run into problems you will need to use the verbose flags and check for any errors. For the very first time, you would want to run it with verbose flags.

Using configure.status
Use `config.status' (with no arguments) to regenerate all files (`Makefile', `config.h', etc.) based on the results of the configure script used last. (note this will run into problems if it becomes stale and out of date). If you have problems, run configure.

silencing configure
On an older computer configure too 3min21 sec, with ./configure -q 3min1 seconds. Not bad, but you may want to watch out for configure errors. For the very first time you use it - use verbose and check for errors. Only after your wine works would you consider silencing configure. One a 4 core processor it has been known to take as little as 5 minutes for the whole job so a faster computer is better.

silencing make
For the very first time you use it - check for errors. Only after your wine works would you consider silencing make and then only if you have an older slow computer. make on an older computer took 29 s but make -s dropped to around 13 seconds.

skipping make install Yes, just run the wine programs from the folders. To be able to use winetricks you will need to use these commands:

export WINE=~/wine-git/wine
export WINEPREFIX=~/winetest

Lets put this together:

  1. copy any existing wine folders out of the way and dont bother un installing your current version of wine.(when finished testing we can revert to it by typing rm -rf .wine to remove the test version of wine and then moving back your wine folder mv .oldwine wine)
    mv .wine .oldwine
  2. Using git, download the latest version of Wine
    git clone git:// wine-git
  3. For the first go use all the options to check for configure errors etc, but disable the tests (for an older computer this may take up to 40min)
    ./configure --disable-tests && make depend && make
  4. run wine config from where it was compiled - it will create a new .wine folder
  5. Install your software and test it to see if it still has the bug you found - if it does you then can regression test to find the patch that caused it. But this time you might try and speed it up (For an older celeron computer this now took around 20min).
    1. make clean
      CC=="ccache gcc" config.status
      make depend -s
      make -s

Of course if anything does go wrong, you will need to run it without the silent flags and check through the messages for configure and make for any errors. With git bisect and ccache you will then hopefully save even more time as you get closer to the problem.

Using ccache

[Ed, dont forget to install it first!]

McCormack: [Aug 05]:[using CVS until you find the problem] is the best way to find the problem. It's not as bad as you think, especially if you use ccache and a binary search.

CC="ccache gcc" ./configure

Additionally, the search gets faster and there's less re-compiling as you narrow it down further. If you know the problem is only in the comctl32 code, you might be able to regress that only...Wine Archive

One user [wine user jan 09] ran into errors with ccache:

{standard input}: Assembler messages:
{standard input}:38: Error: suffix or operands invalid for `push'
{standard input}:39: Error: suffix or operands invalid for `push'
{standard input}:46: Error: suffix or operands invalid for `pop'
{standard input}:47: Error: suffix or operands invalid for `pop' make[2]: *** [interlocked.o] Error 1

Vitamin: If you on x86_64 make sure to add ' -m32' to the CC:

CC='ccache gcc -m32' ./configure

However in this case the user wrote: I am using that. The exact line I run is:

CC="ccache gcc" CFLAGS="-g -O0" ./configure --verbose && make depend && make

but it happens without CFLAGS all the same.

J. McKenzie: What version of Linux are you using and what type of CPU does your computer have? If it is a 64 bit processor, you WILL have to use the -m32 flag or Wine will not compile properly. Yes, we are working on making Wine build properly for future versions.

Further Reading

Jun 08 wine user posted his error from configure which showed how he used ccache:

Rob@Office:~/wine-git$ CC="ccache gcc" ./configure --verbose 
checking build system type... i686-pc-linux-gnulibc1 
checking host system type... i686-pc-linux-gnulibc1 
checking whether make sets $(MAKE)... yes checking for gcc... ccache gcc
checking for C compiler default output file name... configure: error: C compiler cannot create executables

A. English: You need lots of dependencies, namely, a compiler. Look at: h

TlarchicesL You are compiling using ccache :

CC="ccache gcc"

You will need to install the ccache package in order to use it. (And this package is not in the recommended packages list as it only appears in the bisection explanations) Of course you will still need all the other packages from the wiki page.

Avoiding compiling Tests

If you are new to regression testing, you might not worry about this more advanced trick as it suits those who do regression testing regularly. However since the option has been added in recent wine versions, the benefits may be worth it.

disabling the wine tests
For recent versions of Wine, after downloading the latest wine using git (which if you followed the official wiki is in your home folder under the folder called wine-git), change to this directory, check you have the latest and ask configure to skip the tests.

cd ~/wine-git
git pull

disable compiling the test with the command to configure ./configure --disable-tests

You can see this option and several others by examining the output of ./configure -help but do be aware that while disabling the tests is a no brainer, playing with the others can get you into trouble unless you know what you are doing.

For older versions of wine before mid November 2008, you can still disable the tests using a patch which is available on the official wine wiki. Download it to your Download folder (~/Download) and name it disable_test_new.diff.

you then disable compiling the tests with this command:

patch -p1 -R < ~/Download/disable_test_new.diff

And then compile wine. revert or remove the patch each time you work with git like so:

patch -p1 -R < ~/Download/disable_test_new.diff

For versions of wine after November 21 2008,the configure option does this for you. The patch title says it all: configure: Add a --disable-tests option to avoid building regression tests. Of course if you wish to do any development you would most likely need to be running those tests before submitting any patch

D. Kegal [Dec 07 wine devel] Lots of the time in regression searches is spent compiling tests, but when you're only going to run the app that's breaking, that's not too useful. How does one disable compilation of conformance tests?

update1. This is now covered in the official wine wiki under Disabling Tests to Speed up Compliation, download the file disable_test_new.diff and check the instructions here:

Avoiding Make Install

A wineuser Aug 08 psoted: I compiled wine 1.2.2 from git as per instructions on the AppDB page, applying a patch to wine.[..] I am wondering, I have a wine-git folder as I just compiled it[...] [to run cc3.exe]

jeffz: If you build wine in your wine-git folder, you can then use that compiled version by specifying it on the commandline such as:

cd ~/.wine/drive_c/CC3
~/wine-git/wine cc3.exe

The user clarified Aug 08 wine user: so I would leave the existing wine install alone, and just rebuild wine-git with the patch I need and run CNC3 as you indicated?

A. English: Yes

I'm quite new to the compiling process so for my sake, "make depend && make" is what actually makes wine, and sudo make install just installs it into the system with links and such? So I can just do the make depend && make [..] right?

A. English: Yes

Vitamin Aug 08 wineuser: The best way to no not overwrite your current version is to not install your compiled version at all. But rather running it from the compile dir. The only side affect is you have to specify [the full] path to "wine".

Working in Parallel

Make can also take the -j flag. It is often faster, especially with systems containing more than one processor. Some suggest choosing a number 1 more than the number of processors, so if you have a 4 core processor use -j5. On the git mailing list Linus has suggested using it <snip> I don't generally build docs, but they should run in parallel too, and at least your fedora build on has a nice quad-core machine with lots of memory, so "-j8" or something is reasonable.</snip> Archived-At:

you could always trial different values for j and see which is the fastest for you using the time function:

time  make depend -sj5 && time make -sj5

Using Distcc

If you have more than one computer, you can use distcc to compile wine using all your computers. It is a little more involved but not that hard once you try it. Yes it is faster! However you do have to balance security verses speed. Here is an example using SSH, which is more secure. If you are worried, you could add a specific user login for compiling Wine and check other sources on how to lock it down.

  1. On each computer create a user called Wine open a terminal window. Note these instructions are for Fedora 18 - other systems may have differences.
  2. Install the required files for compiling wine (see [Installing Wine]
  3. Set up ssh access for each computer you are using:
    1. Set ssh to accept RSA connections
      code: su -c 'vi /etc/ssh/ssh_config'
      scroll down to # RSAAuthentication yes and delete the '#' at the beginning of the line.
      save the settings, and exit vi using a colon, w and q eg: :wq
    2. Generate a ssh key
    3. (accept default settings and enter a blank password by pressing enter for distcc which needs an automated login)
    4. Set the file permissions for ssh - else it likely will wisely refuse to work.
      Code: chmod 700 ~/.ssh && chmod 600 ~/.ssh/*
    5. Set the network settings to manual, and select an known ip address. (if your network is you might set two computers as and
    6. Send the ssh information to each computer
    7. On the other computers open a terminal and set the file permissions for each computer. i.e Type on the other computer:
      Code: chmod 700 ~/.ssh && chmod 600 ~/.ssh/*
    8. Test the login. Try from the main computer (say username Wine on to login to the other (username WineSlave
      Code ssh [email protected]
      If it fails, check your log - it is very helpful. For example you might start at:
      su -c 'tail /var/log/secure'
  4. Install distcc and distcc-server on each machine

Reporting Regression Tests

Originally regressions were posted to the Wine developer list but this has changed as noted by M. McCormack Nov 06: the right place to report bugs is

When you have found the patch involved, bugzilla can be your friend. It is there you can enter all the gory details and upload screenshots. D. Navara is the hard working maintainer of bugzilla - he or another bug hunter will likely contact your for further information about the bug.

Because the developers are already working on plenty of bugs, when posting a bug you can make the life of a developer easier by including important information:

A quick caution: If you have a long trace or screenshot, make it an attachment (Busy bug zappers should not need to download a 1Gb page to read your post).

With that information a [busy] developer reading [the bug] will know whether it's worth digging deeper and actually look at the bug report and patch. Wine Archive Link

Even if the original developer does not see the message, with this information others will. M. Stefaniuc explains: Regressions bugs are quite interesting especially if the culprit patch is already known.

Sometimes a note may be made to the Developer Mailing List, wine-devel as shown in February 2007. What is interesting here is how the bug report made use of git to describe the exact commit: A. Pignotti: I've noticed that commit 12252d058914a66f40e976484cc7d8aa52ffca47 on the git tree causes a regression in the sims, making characters flipped upside down. It's seems to me that the y axis is flipped. I hope this helps

The developer involved quickly replied: Oops [...] Is there a demo for this game I could use to debug this? [wine devel Feb 14 2007]

Further Reading

Regression Test Example

Using git Bisect across a very, very long range of releases
[Ed, normally you would be testing between one or two releases (which is quite quick), and not testing 34 releases(!) as this example in Winehq Bugzilla entry 21043, which saved a Wine developer having to spend a whole day testing just to find out that it was likely an nvidia bug : I just finished regression test[s] [..] I tested from wine-1.1.0 to wine-1.1.34 and at the end I came to two versions (took me almost all day [ed, his computer appears to be a slightly slower, older one] and I tested both ArtRage 2.5.20 and ArtRage3 Studio Pro Demo):

Last message I got was:

Bisecting: 0 revisions left to test after this (roughly 0 steps) [6b8753185f30197047773af6a26eafd34d45367c] winex11: Add support for 16-bit/32-bit DIB sections.

Since the first bad commit wasn't identified, I have no idea what to do next. Suggestions?

A. English: You still have one more compile to do. Compile wine [...], and report it as good/bad.

He replied: OK, done. [and posted the result of his regression tests].

Manually Finding and indentifying a March 2003 Visual Regression with Internet Explorer: Wine Archive Link [Ed. Note that using git bisect is often faster]

Total Time taken: A couple of hours with an AMD 1.8Gh
J. Hoizer: Internet explorer was installed using winetools, some months ago, in a clean ~/.wine tree (so nothing else messed with registries). I kept [the] installed internet explorer untouched, and used the wine in the build tree (without any system-wide installed wine, just to be sure the right wine version was running)

Whilst working on other things (when waiting for compiling to finish), he then did:

  1. cvs update to 15 march, compiled with ./configure && make depend && make
    • Ensured it was ok,
  2. then cvs update 19 march (middle between 15 and 23).. then.. 21 then... 23
    • At compiling 23 CDT the regression was not there yet;
  3. Updated to 24 CDT and recompiled - just in case, confirming the regression was really there.

Armed with this information, J.Huizer posted to the List:

Okay, I found the regression happened some time on 23 march:
  cvs update -PAd -D "2005-03-23 CDT" doesn't have the regression
  cvs update -PAd -D "2005-03-24 CDT" has the regression
Now how will I be able to find exactly what's causing it? Can I download the individual patch files of that date somehow?

H.Valtonen:You can update by time as well as by year/month/day. Just look at the wine-cvs list archives for potential times to update to. eg:

cvs update -PAd -D "2005-03-23 16:00"

P.van Schayck: shows all the cvs patches. I would try the comctrl patches from the 23th. Not things like winealsa (which are sound related). [Ed. since the update to pipermail The cvs patches are now available here While pipermail does not display the dates, it does list in date order. An alternative is using your favorite newsreader]

Because of J.Huizer's hard work identifing the patch, the developer was able to quickly check his work and found a possible fix:

Wine Developer (Rob Shearman, the very next day):Thanks for narrowing the regression down. Does the attached patch help?

J.Huizer:After applying the patch IE draws its bar normally again :) ...



Testing Patches

Sometimes after finding a regression you are asked to test a patch.

One patch caused a problem for the user until J. Lang noted that one of the patches affected [you] need to run autoconf before running configure. The patch named 1/4 doesn't update configure, just, and it needs autoconf to be run to regenerate configure. Winehq Bugzilla entry 19397

Wineserver error msg

wine: created the configuration directory '/home/[the name]/.wine'
wine client error:9: version mismatch 352/357. Your wineserver binary was not upgraded correctly, or you have an older one somewhere in your PATH. Or maybe the wrong wineserver is still running?

Vitamin [Jan 09]: The older/newer version of wineserver is still running. Make sure all parts of Wine stop before you test next compile.

[Ed try wineserver -k]

Forum Comments


A. English Jan 09 advising a user trying to test:

$ git reset --hard origin
$ git fetch ; git rebase origin
$ ./configure && make depend && make

That will give you the current development version. Try that. 1.1.12 had a couple major regressions.

The user wrote: My son worked out from gitk what was involved in doing a bisect by taking the fix in 8c4a2978b281e9519a6581d859add636de4b42d4 and applying it where the bisect would have been done. This was done by manually editing the configure and with the changes in the fix (after backing up from the changes), and compiling. (We reversed our manual changes after testing).

A. English:that should work fine. See

Compiling Old versions

Changes to Freetype

Winehq Bugzilla entry 17764 A user wrote I've tried to do a regression test but i had compilation problems: as the guide says "Note that old wine versions can give trouble compiling because of changes to freetype, explains this and has a patch.

A. English: The patch is at the lower part of that page, starting with 'diff --git a/dlls/gdi32/freetype.c b/dlls/gdi32/freetype.c'. See:

Very old version of Wine

A developer [May 06] upgraded to fedora core 5 (from fedora 3) In my old system i had about 20 wine-versions (back to april 2004) installed which was great for tracking down regressions. Trying to compile older wineversions now on my new installation fails with various errors (like wine-20050419 fails with error:

union <anonymous> has no member named a_ptr)

Even wine-0.9 (first beta release) won't compile anymore. I guess that's due to newer gcc/glibc versions. Is there a (easy) way to get older wine-versions compiling again?

P. Beutner[May 06]: identify and porting the necessary changes back is probably the easiest way, atleast easier than installing another glibc ;) Assuming you are using git:

  1. create a new branch 'v0.9' starting at version 0.9 git checkout -b v0.9 wine-0.9
  2. fix for the flex issue(needed for wine < 0.9.10) git cherry-pick -r 69dcbaaf93a65820a28fe2485b6d15a90f423899
  3. fix for undefined CLK_TCK (needed for wine < 0.9.1) git cherry-pick -r 5c256c518faf2344266cabecad9fdbfd9d0095ad

Thats all you need atleast back until 0.9. I never tried anything older.

As for the error you mentioned:

$ git log wine-20050419..upstream | grep -B4 a_ptr commit 2b6e7dad58833b0e4bf3a05c8ae2de3542728c2e Author: Marcus Meissner [email redacted] Date: Thu Jun 2 10:30:08 2005 +0000 Elf32_auxv_t.a_un.a_ptr no longer exists in HEAD glibc CVS, use

so I guess you want that commit too for archive

M. Bestefich:

[...]I've managed to fix the above two. They're really simple things. [Ed. Link includes discussion on older versions of wine] Wine Archive

Wine Links

Personal tools