How to obtain and compile Wine, and problems that may arise... If you are going to compile Wine, either to use the most recent code possible or to improve it, then the first thing to do is to obtain a copy of the source code. We'll cover how to retrieve and compile the official source releases from the FTP archives, and also how to get the cutting edge up-to-the-minute fresh Wine source code from CVS (Concurrent Versions System). Both processes of source code installation are similar, and once you master one, you should have no trouble dealing with the other one. You may also need to know how to apply a source code patch to your version of Wine. Perhaps you've uncovered a bug in Wine, reported it to the Wine mailing list, and received a patch from a developer to hopefully fix the bug. We will show you how to safely apply the patch and revert it if it doesn't work. The safest way to grab the source is from one of the official FTP archives. An up to date listing is in the ANNOUNCE file in the Wine distribution (which you would have if you already downloaded it). Here is a list of FTP servers carrying Wine: ftp://ftp.ibiblio.org/pub/Linux/ALPHA/wine/development/ ftp://ftp.infomagic.com/pub/mirrors/linux/sunsite/ALPHA/wine/development/ ftp://ftp.fu-berlin.de/unix/linux/mirrors/sunsite.unc.edu/ALPHA/wine/development/ ftp://orcus.progsoc.uts.edu.au/pub/Wine/development/ The official releases are tagged by date with the format "Wine-YYYYMMDD.tar.gz". Your best bet is to grab the latest one. Once you have downloaded this, you must first compile Wine, and then install it. This is not very hard to do. First switch to the directory containing the file you just downloaded. Then extract the source with (e.g.): $ tar xzvf wine-20021031.tar.gz Then, switch to the directory that was created and compile it by typing (e.g.): $ ./tools/wineinstall NOTE: You must make sure that you are not the superuser (root) when doing this, and that you have write permission to the directory that was created by the tar command as well as all of its subdirectories and files. The official web page for Wine CVS is http://www.winehq.com/development/. First, you need to get a copy of the latest Wine sources using CVS. You can tell it where to find the source tree by setting the CVSROOT environment variable. You also have to log in anonymously to the Wine CVS server. In bash, it might look something like this: $ export CVSROOT=:pserver:cvs@cvs.winehq.com:/home/wine $ cvs login Password: $ cvs checkout wine That'll pull down the entire Wine source tree from winehq.com and place it in the current directory (actually in the 'wine' subdirectory). CVS has a million command line parameters, so there are many ways to pull down files, from anywhere in the revision history. Later, you can grab just the updates: $ cvs update -PAd cvs update works from inside the source tree. You don't need the CVSROOT environment variable to run it either. You just have to be inside the source tree. The -P, -A and -d options make sure your local Wine tree directory structure stays in sync with the remote repository. After you've made changes, you can create a patch with cvs diff -u, which sends output to stdout (the -u controls the format of the patch). So, to create a my_patch.diff file, you would do this: $ cvs diff -u >my_patch.diff You can call cvs diff from anywhere in the tree (just like cvs update), and it will diff recursively from that point. You can also specify single files or subdirectories: $ cvs diff -u dlls/winaspi >my_aspi_patch.diff Experiment around a little. It's fairly intuitive. If you have the Wine source code, as opposed to a binary distribution, you have the option of applying patches to the source tree to fix bugs and add experimental features. Perhaps you've found a bug, reported it to the Wine mailing list, and received a patch file to fix the bug. You can apply the patch with the patch command, which takes a streamed patch from stdin: $ cd wine $ patch -p0 <../patch_to_apply.diff To remove the patch, use the -R option: $ patch -p0 -R <../patch_to_apply.diff If you want to do a test run to see if the patch will apply successfully (e.g., if the patch was created from an older or newer version of the tree), you can use the --dry-run parameter to run the patch without writing to any files: $ patch -p0 --dry-run <../patch_to_apply.diff patch is pretty smart about extracting patches from the middle of a file, so if you save an email with an inlined patch to a file on your hard drive, you can invoke patch on it without stripping out the email headers and other text. patch ignores everything that doesn't look like a patch. The -p0 option to patch tells it to keep the full file name from the patch file. For example, if the file name in the patch file was wine/programs/clock/main.c. Setting the -p0 option would apply the patch to the file of the same name i.e. wine/programs/clock/main.c . Setting the -p1 option would strip off the first part of the file name and apply the patch to programs/clock/main.c . The -p1 option would be useful if you named your top level Wine directory differently than the person who sent you the patch. For the -p1 option patch should be run from the top level Wine directory. gcc >= 2.7.x required (Wine uses the stdcall attribute). Versions earlier than 2.7.2.3 barf on shellord.c -- compile without optimizing for that file. In addition EGCS 1.1.x and GCC 2.95.x are reported to work fine. flex >= 2.5.1 (required for the debugger and wrc, and lex won't do) bison (also required for debugger. Don't know whether BSD yacc would work.) X11 libs and include files texinfo >= 3.11 (optional, to compile the documentation.) autoconf (if you want to remake configure, which is not normally required) XF86DGA extension (optional, detected by configure, needed for DirectX support) Open Sound System (optional, detected by configure, for sound support) The Red Hat RPMs are gcc-XXX, flex-XXX, and XFree86-devel-XXX, where XXX is the version number. You also need about 230 MB of available disk space for compilation. The compiled libwine.so binary takes around 5 MB of disk space, which can be reduced to about 1 MB by stripping ('strip wine'). Stripping is not recommended, however, as you can't submit proper crash reports with a stripped binary. If you get a repeatable sig11 compiling shellord.c, thunk.c or other files, try compiling just that file without optimization. Then you should be able to finish the build. FreeBSD -- In order to run Wine, the FreeBSD kernel needs to be compiled with options USER_LDT options SYSVSHM options SYSVSEM options SYSVMSG If you need help, read the chapter "Building and Installing a Custom Kernel" in the "FreeBSD handbook. You'll need to be running FreeBSD 3.x or later. SCO Unixware, Openserver -- UW port is supported by SCO. Solaris x86 2.x -- Needs the GNU toolchain (gcc, gas, flex as above, yacc may work) to compile, seems functional (980215). DGUX, HP, Irix, or other Unixes; non-x86 Linux. No ports have been seriously attempted. For non-x86 Unixes, only a Winelib port is relevant. Alignment may be a problem. OS/2 -- not a complete port. See Odin. Note that this project uses some Wine code but is not based on Wine. BeOS -- not a complete port. See BeWine. Macintosh/Rhapsody -- no ports have been attempted.