Previously it was suggested to Install using the latest rpm on winehq's download site. Relatively soon after wine reached 0.9 this suggestion has changed [April 06] M. Ludwick: Fedora Wine packages are in Fedora [...] a "yum install wine" should do it (as root of course :-)).
Segin [Apr 06] install Wine like so: wine archive
- yum install wine wine-devel wine-arts wine-tools wine-jack
'July 2006 as a result of a discussion with Wine the packager announced: If you install wine form the Fedora Extras repository via 'yum install wine' nearly everything that would be in a monolithic package is going to be installed. The 'wine' package now is a meta-package containing requires for the various subpackages. So now 'normal' users who do a 'yum install wine' will get everything they need and experts who know what they are doing can go and install only the parts they want. [...] wine archive
A. Bierfet [May 07]: A small update interesting for RHEL/Centos 4 users: All dependencies that where needed to build wine for EPEL 4 have been met and I just pushed a build for it. This means that EPEL  users can just install wine from the EPEL repository. As people have been complaining about the link on the winehq webpage I have taken the time to make a summary page on the fedora wiki which is easier for me to maintain and keep up-to-date and is probably more helpful. I would request that the link in the download section is changed to that page.
[dec 09] Fedora appears to have packaged wine64 (which is for 64bit windows software and does not work too well yet, though admitedly it is improving fast) as well as the normal 32 bit wine version. At this point, you will want to install the 32bit wine which should be called wine.i586 or as Winehq Bugzilla entry 21602 says, i686 packages.
[Update Aug 2010] Official Fedora packages now include a non approved package for running pulse audio. Unfortunately as Wine has moved away from supporting pulse, towards another sound system called openal, which means that the official Fedora packages are no longer supported by Wine developers. Those wanting to file bugs using fedora will need to file them with fedora, not Wine, unless you compile wine yourself (which is surprisingly easy to do).
Packaging Wine and Fedora
June 2006 there was a discussion with the packaging of Wine for Fedora. Wine was being very promptly built and split into quite a number of packages. B. Vincent was one of several took advantage of having the packaging volunteer discussing packaging on the list: First off, thank you very much for building the FC packages. It was something we were sorely lacking for months and it's a thankless job. So, thanks. [...he then made several packaging suggestions to limit the number of packages for wine]
M. Hearn: We had this problem with Debian, where people didn't install the "utils" package and apps broke mysteriously. Unless you have a lot of experience of Wine debugging you cannot detect this easily ... please, there's no reason to split this stuff up as Wine will load everything in a failsafe fashion so there is no need to mark the package as depending on a million things.
The packager noted: I as a packager [...] in this case [...] see why splitting up wine made sense in debian and why it made sense for Fedora Extras as well. The question is what to split and what to leave in. The stuff that has been split from just having one 'wine' package is stuff that made sense and in ways interacts best with what Fedora Core ships with the distro. Sure there are improvements to be made and suggestions are always welcome :)[..] in the near future (1-2 years) rpm and yum support for optional dependencies will be spread enough so it solves a lot of issues [...] and I am really happy to make use of it... but for now this is not an option, sadly...[...]
The packages are: wine, wine-arts, wine-capi, wine-cms, wine-esd, wine-jack, wine-ldap, wine-nas, wine-tools, wine-twain
These are the 10 packages which are relevant for a 'normal' user where wine and wine-tools are the major ones. They are build from the wine sources (without winemp3). Then there is two [...] more or less only interesting for packagers/developers etc.
M. Hearn [cautioned]: [If you dont install] wine-tools[...] [you] will be missing:
These may appear to to be optional but they are not. Explorer is needed for shell integration, HAL support and system tray support. It is not an end user tool, it's a part of the Wine infrastructure. Winedbg is needed to produce useful crash data for developers. Notepad and winecmd are sometimes used by installers which will *fail silently* if they are missing. Winepath is used by various third party scripts. Winhelp is used by apps for online help, obviously.[...] Wine isn't really a suite. It's a large, monolithic program.[...]
after some discussion the packager made several changes and suggested a compromise:What I can offer would be this: add a meta package wine-suite which will install all wine packages and change the summary of wine so it:
- points to the wine-* subpackages so everyone knows they exist
- tell them that there is the wine-suite meta package
- and of course as discussed before add a Require for wine-tools to wine.
I hope that this is a solution the wine folks can live with. Remember: I do the packaging I do in my free time and touching wine and fitting it into Fedora Extras and upgrading it every two weeks is not the easiest thing to do. wine archive
Ed. Thanks for working in with Wine.
Fedora Packaging bugs
A. Bierfiet:[regarding packaging bugs] Direct them to me or https://bugzilla.redhat.com. [...] Maybe just maybe try to see the packager/distro side of things [...] what is modern packaging and very distribution specific to fedora or even fedora extras the way I did it is the way to go... not by my opinion but the opinion and rules of the fedora community...
Official Fedora packages for Wine
The official packages work well and are often very recent to even up to date. However if you have 64bit version of Fedora, by default, it may install the 64bit version of wine, which does not do much at all yet [jan 10]. However, once you uninstall the 64bit version and you can then install the 32bit version of wine and all will be well again. Keep in mind that wine is progressing at an amazing rate, so go and get the very latest version you can obtain and keep updating it.
update aug 2010 The wine 1.2 release means wine64 and wine32 should work together now. If you have problems, check you have the video drivers for 32bit, and file a bug.
The wrong version accidentally installed
dimesio [wineusr jan 10] 64 bit Wine is experimental, doesn't run any real apps yet, and at present can't coexist with 32 bit Wine [apparently a goal for Wine 1.2]. Unfortunately, Fedora has been [installing] it on unwitting users. Remove all x86_64 Wine packages and install only the i686 ones. [ed apparently due to processor limitations 64bit wine on 64bit linux can not run 16bit software. The 32 bit version can run 16bit if installed on a 32bit version of fedora. Check the version you have installed if wine does not work]. You can recognize if you are running the wrong version because you will see this message in a terminal:
Trying to load PE image for unsupported architecture (I386) Trying to load PE image for unsupported architecture (I386)
A. Bierfeit: wine-0.9.10.i386 made it to the x86_64 tree so x86_64 users of Fedora Extras can get wine.i386 now by typing yum install wine as well...
Finding Complete Documentation
Part of wine's documentation such as the man pages are in the wine-devel package.
[Mar 2012] Wine 1.4 sound needs a recent version of pulseaudio, which works in Fedora 16. You may need to update your pulseaudio if using an older version of Fedora.
wineusr [jan 10] the absence of an ALSA entry [in wine is] due to the fact that, in Fedora's packaging of wine, ALSA ist not enabled by default [..] After installing the additional wine-alsa package, ALSA comes up in winecfg as expected. [If your sound is broken, this may be the reason.] Pulseaudio does not work well with wine, the unofficial patch for pulse which can be installed for Fedora - may not always work, but has been improved and resubmitted. Perhaps it will be accepted this time.
Yes, now wine depends upon wine-gecko and can crash if it is not present. Yet fedora does not provide a yum package. Gecko previously depended on non free compilers. This is being worked upon, and may now be nearly fixed, with the msi package being created by Wine itself. However you should be able to install it using winetricks
Perhaps try filing a bug report, but recently there has been confusion regarding the packages for Fedora which contain an unofficial patch which is for pulse audio. Because of the difficulty of tracking bugs caused by additional patches, a wine developer said in Winehq Bugzilla entry 21215 Although this bug has been confirmed by people running pure Wine, I'd like to clarify that Fedora Wine package can't be used for retesting or filing any other Wine bugs. Please report to Fedora that their Wine package is broken and can't be supported here. http://fedoraproject.org/wiki/AndreasBierfert/Wine doesn't list wine-pulseaudio as a part of the Wine package, so it's not clear where it comes from.
A bug report may need to be filed with fedora if wine will not accept it for wine bugzilla.
Older versions of Fedora
Sept 08 With the new keys from fedora, you might want to install the very latest version of wine. For fedora 8 Using a text editor as root, go to /etc/yum.repos.d/ and edit the fedora.updates.testing.newkey.repo. If you cant find it, then you need the latest fedora release transitional package - check your updates and you will see it listed - install it. Back to the file...You will find the word enabled=0, change it to be enabled=1 and save. Now type as root in a terminal
- yum update wine.
Done. Welcome to the world of wine
Wine Packages for Fedora
Fedora Core Rpms are [update] not available on the WineHQ download page: WineHQ Download Page now points to the official packages for fedora. However there are a few little wrinkles - see above.
Building from Source with Fedora
As Wine is under active development, users should try the latest version with its many bug fixes. http://wiki.winehq.org/Recommended_Packages lists the needed packages. Checking your favourite software for bugs and filing bug reports often fixes breakages before each Wine release.
Install git, and follow the instructions in the official wiki http://wiki.winehq.org/GitWine
If you are only compiling wine, you can update with 'git pull' which fetches and merges the updates in one step, otherwise use git fetch.
The provided packages for Wine in fedora 17 are broken - M. Lankhurst: [Oct 2012] winepulse in fedora is a really old version, and it doesn't look like they've updated it since they first shipped it. However compiling wine is not that hard. It takes a while, but unless you really need a new feature you can continue to use a compiled wine. You can often recognize the pulse issue when applications with sound often seem to freeze. Another bug, since updated involves libxcb. This is noticed by things crashing. Update it and it should work again.
With the proviso of this becoming out of date, as of Jul 2012 packages are mostly the same as for f16. Sound mostly 'just works' with the latest updates. Using the default fedora install for software development, the list for compiling wine with fedora appears quite small. If sound it not working, don't forget to turn up the sound settings in fedora. It can be so low, that you cannot hear sound playing from Wine.
- yum install cabextract cups-devel libv4l-devel gstreamer-plugins-base-devel
With the proviso of this becoming out of date, as of Mar 2012 packages are mostly the same as for f14. Some packages if legal in your area, are available from RPMFusion. Note: These do not include the scanner development package, nor one of the sound packages but you may not need these - sound mostly 'just works' with the latest updates.
- yum install alsa-lib-devel cups-devel dbus-devel esound-devel fontconfig-devel freetype-devel giflib-devel isdn4k-utils-devel lcms-devel libICE-devel libjpeg-devel libpng-devel libSM-devel libusb-devel libX11-devel libXau-devel libXcomposite-devel libXcursor-devel libXext-devel libXi-devel libXinerama-devel libxml2-devel libXrandr-devel libXrender-devel libxslt-devel libXt-devel libXv-devel libXxf86vm-devel mesa-libGL-devel mesa-libGLU-devel ncurses-devel openldap-devel openssl-devel pkgconfig sane-backends-devel xorg-x11-proto-devel gnutls openal-soft-devel gsm-devel libv4l-devel openal-soft-devel gcc flex bison git cabextract wget libgphoto2-devel libmpg123-devel gstreamer-plugins-base-devel
Compile using silent (it's faster), disabling Winetests (unnessary, time consuming) and use the -j option for make, which seems to speed it up as well (the best value is usually near the number of processor cores you have - ie, a dual core might use -j2 or even -j4. Time different numbers to find the fastest, but -j4 should work quite fine)
./configure --silent --disable-tests && make -j4 --silent
Note: if you run into problems try again, but skip the --silent options and check for errors.
With the proviso of this becoming out of date unless regularly updated, as of Dec 2010 the packages appear to be the same as for f12 for compiling 1.3
- yum install alsa-lib-devel cups-devel dbus-devel esound-devel fontconfig-devel freetype-devel giflib-devel hal-devel isdn4k-utils-devel lcms-devel libICE-devel libjpeg-devel libpng-devel libSM-devel libusb-devel libX11-devel libXau-devel libXcomposite-devel libXcursor-devel libXext-devel libXi-devel libXinerama-devel libxml2-devel libXrandr-devel libXrender-devel libxslt-devel libXt-devel libXv-devel libXxf86vm-devel mesa-libGL-devel ncurses-devel openldap-devel openssl-devel pkgconfig sane-backends-devel xorg-x11-proto-devel gnutls openal-soft-devel gsm-devel libv4l-devel openal-soft-devel gcc flex bison git cabextract wget
With the proviso of this becoming out of date unless regularly updated, as of July 2010 the packages appear to be the same as for f11 for compiling 1.2rc candidates.
- yum install alsa-lib-devel cups-devel dbus-devel esound-devel fontconfig-devel freetype-devel giflib-devel hal-devel isdn4k-utils-devel lcms-devel libICE-devel libjpeg-devel libpng-devel libSM-devel libusb-devel libX11-devel libXau-devel libXcomposite-devel libXcursor-devel libXext-devel libXi-devel libXinerama-devel libxml2-devel libXrandr-devel libXrender-devel libxslt-devel libXt-devel libXv-devel libXxf86vm-devel mesa-libGL-devel ncurses-devel openldap-devel openssl-devel pkgconfig sane-backends-devel xorg-x11-proto-devel gnutls openal-soft-devel gsm-devel libv4l-devel openal-soft-devel gcc flex bison git
install the packages needed for winetricks
- yum install cabextract wget
Now we have finished our work installing the packages, exit out of root, and as a user, pull a copy of the Wine source code using git, and change to the new directory:
- git clone git://source.winehq.org/git/wine.git ~/wine-git
- cd ~/wine-git
Compile using silent (as this makes it a little faster), and use the -j option which seems to speed it up as well (the best value is not certain, but is often somewhere near the number of processor cores you have - ie, a dual core might use numbers between -j2 or even -j4. You can try and time different numbers to find which one is the very fastest, or just select one, with the understanding it will probably work quite fine)
- ./configure --silent && make -j4 --silent
Note: if you run into problems try again, but skip the --silent options and check for errors.
Set up your environment variable to locate wine and with this use winetricks to install gecko (we should be able to run it as a script without needing to change it's permissions) WINE=~/wine-git/wine sh ~/winetricks
Setup the wine installation using winecfg (without make install, it makes it easer to update wine):
- ./wine winecfg
run your software using wine ~/wine-git/wine [path/to/your/software/setup.exe
fix the shortcuts on the desktop, by changing the "wine" to "~/wine-git/wine" and you should be good to go!
Note that this needs constant updating. When you run configure, it will tell you if you need more packages. Then search using yum. Here is an example of tracking down the new sound files
which informed us: libopenal development files not found
- yum provides libopenal
does not find anything, but checking the file generated by configure, config.log will tell you that al.h was not found. Turning to yum again
- yum provides */al.h
returns with: openal-soft-devel. We know what we need to fix it. After a quick yum install you are on the road again..
- yum install openal-soft-devel
and configure is no longer reporting an error.
With the standard development options for a fedora install, the extra packages needed are [apr 10] (which does not include the libmp3, and builds wine without mp3 codec support):
- yum install gsm-devel lib4vl-devel openal-soft-devel
untested, but it has been reported on one site that lib123 is available here: http://www.atrpms.net/dist/f11/mpg123/
As of Jan 09 the command is something like (this will become out of date)
- yum install alsa-lib-devel cups-devel dbus-devel esound-devel fontconfig-devel freetype-devel giflib-devel hal-devel isdn4k-utils-devel lcms-devel libICE-devel libjpeg-devel libpng-devel libSM-devel libusb-devel libX11-devel libXau-devel libXcomposite-devel libXcursor-devel libXext-devel libXi-devel libXinerama-devel libxml2-devel libXrandr-devel libXrender-devel libxslt-devel libXt-devel libXv-devel libXxf86vm-devel mesa-libGL-devel ncurses-devel openldap-devel openssl-devel pkgconfig sane-backends-devel xorg-x11-proto-devel gnutls
- yum install bison flex prelink
With recent [jun 08] problems building vitamin jun 08 recommended running this code
ulimit -s unlimited
Z. Boszormenyi suggested: use this instead:
export CFLAGS="-fno-tree-pre -fno-tree-fre"
Building from Source Fedora x64
With recent problems building vitamin jun 08 recommended running this code
ulimit -s unlimited
Z. Boszormenyi suggested: use this instead:
export CFLAGS="-fno-tree-pre -fno-tree-fre"
P. Roskin [Dec 05]When trying to set up printing from Wine on Fedora Core 4 for x86_64, I have discovered that Wine fails to find many libraries, including libcups. [.. foo-devel-32bit development packages too] are provided for some basic libraries, such as zlib and ncurses. Other libraries, such as cups, as missing, but my script can remedy it, because the only missing file is the symlink to *.so for the linker. The script creates all missing links in one directory (/usr/local/lib is the default). Not only was libcups found next time, but also the old workaround with imake has become unneeded. The configure script runs out-of-box and finds X11 libraries.
openssl support cannot be fixed by the script since /usr/include/openssl/opensslconf-i386.h is missing. That's where a development package would be very helpful. I see it's not fixed in RawHide yet, so we'll have to deal with such issues for some time. [He then posted the script to the list] wine archive
A user noted:[sept05] The readme states as requirement that XFree86-devel be installed for RedHat boxes. I'm running FC4 which doesn't use XFree-86 but xorg-x11. Are these equivalent, and will the installation of xorg-x11-devel meet the installation requirments?
R. Walls: Should be fine, as both packages contain the X11 header files and libs needed by wine. I'm on a slackware box (also xorg) and wine compiles and runs fine.Wine Archive
Z. B�sz�rm�nyi: The suggested GCC compile options come from what Wine RPM on Fedora uses. Those (and also the "ulimit -s unlimited" solution) work around a bug in GCC 4.3.0 which is fixed in 4.3.1 so the next GCC upgrade in Fedora makes both workarounds unneeded. The CFLAGS solution is safer because although "ulimit -s unlimited" makes Wine compile but GCC may miscompile C code because of its bug.
Troubleshooting Build problems
[Bug 16497] there seems to be an error in menu.o, causing this error upon make
menu.o: In function `test_menu_add_string': /home/Elliot/wine-git/dlls/user32/tests/menu.c:601: undefined reference to `blah.15349' /usr/bin/ld: menu.o: relocation R_386_GOTOFF against undefined symbol `blah.15349' can not be used when making a shared object
A reply: dupe of bug 13445 (even if it's different error manifestation).
You are running into a regression which was introduced in gcc 4.3/4.4 Mainly Fedora 9 users suffered from it and only Wine seemed to trigger this. It was fixed upstream a while ago, so ideally if you update using 'yum' you might get a toolchain with that bug fixed.
If you are interested in the details/background you might want to visit: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35204 where the PR was reported, discussed and fixed.
If the problem still persists after updating using 'yum' (and 'make distclean' before rebuilding Wine), do the following in your shell when building from source:
--- snip --- $ export CFLAGS="-fno-tree-pre -fno-tree-fre" --- snip --- and 'make distclean' to remove any invalid artefacts generated by this bug before rebuilding Wine (make).
A wineuser post reported: After reviewing the sym links on my rebuilt Fedora 9 system, I was able to resolve this problem with the following:
cd /usr/lib rm libGL.so.1 ln -s libGL.so.1.2 libGL.so.1
It was the symbolic link of libGL.so.1 that was the problem. After correcting this Wine compiles with OpenGL -
A user reported: I can't build the CVS version anymore, I get:
gcc -g -O2 -o widl client.o hash.o header.o proxy.o server.o typegen.o typelib.o utils.o widl.o write_msft.o parser.tab.o lex.yy.o -L../../libs -lwpp -lwine_port -lfl ../../libs/libwpp.a(lex.yy.o)(.text+0x624): In function `_yy_dummy_uses_of_static_functions_b2f4_517d_02ff_b30c_3e5a_47d7_aaa3_3b5d_': /home/peter/wine/libs/wpp/lex.yy.c:3357: multiple definition of `_yy_dummy_uses_of_static_functions_b2f4_517d_02ff_b30c_3e5a_47d7_aaa3_3b5d_' lex.yy.o(.text+0x58c):/home/peter/wine/tools/widl/lex.yy.c:1796: first defined here collect2: ld returned 1 exit status make: *** [widl] Error 1 make: Leaving directory `/home/peter/wine/tools/widl'
H. Davies:it's a bug in FC4's flex that's now been fixed. Update to http://download.fedora.redhat.com/pub/fedora/linux/core/updates/4/i386/flex-2.5.4a-36.fc4.i386.rpm
bitblt.c:27:27: X11/Intrinsic.h: No such file or directory
R. Jenson [Oct 05] : See http://bugs.winehq.org/show_bug.cgi?id=3228 The solution appears to be installing the package 'libxt-dev' Going to http://packages.ubuntu.com/ , and using "Search the contents of packages" for files named "Intrinsic.h" will give you 'libxt-dev' as well. You can tuck that trick away for the next time you need to fix this kind of problem building a package.
olepicture.c:1001: error: `DGifOpen' undeclared here (not in a function) [...] Compilation failed, aborting install.
R. Jenson [Oct 05] It looks like you have giflib3g-dev  installed. There seems to be a problem  with that library, suggest you use/install libungif4-dev  instead. wine archive
[Oct 05] A user reported Building using fedora core 4 and wine version 20050930 and CVS from 20051005 I get wineesd error during make depend. He then found the problem: The problem was with alsa. After updating alsa and installing a missing alsa package all was good
Troubleshooting Installing and Using Wine on Fedora
address space randomization
A user posted: Fedora 10 address space randomization is enabled by default. The base address of a process started by wine seems to change.. and it is easy to see when loading Dlls and checking their base addresses. Does the preloader attempt to compensate for this? Or is it necessary to use setarch to turn off ASR completely when debugging with reproducibility?
- $> setarch $(uname -p) -RL
M. Meissner: Check if ntdll.dll and kernel32.dll are always loaded at the same address. If yes, everything is likely ok and no need for further action.
Occasionally SELinux runs into trouble with wine, but this seems to be fixed in updates. If you find when running wine you have SELinux alerting you, you may need to run SELinux in permissive settings for a while, at least until the next SELinux update. [Nov 08] Using the mouse, click on Applications, System Tools, SELinux Management to change the settings.
One user posted about Fedora 10: Yes SELinux is enabled. I eventually managed to get it configured to allow wine to run. I think with something like the following.
- $ setsebool -P allow_execmod 1
- $ chcon -t execmem_exec_t /home/ams/wine/bin/wine-preloader
Which is a bit hackish, but seems to work, and it's possible there's settings I've forgotten about when I installed F9.
Update [Dec 08] With the updated SELinux package it is now fixed.
Below are some bugs reported with different versions of Wine. While these Wine bugs are being regularly squashed and the maintainer is active, we are recording them here for those who must use an older version of wine and those examining when a bug was introduced by trialling older versions of wine. If you run into one of these bugs, then the archive links should enable you to investigate further.
An update to fedora10 breaks wine, possible a security update. Not to worry, a later update fixes it. Just wait a day or two and update again.
A user filed a bug report: the link given on WineHQ.org is broken. It points to a 404 error on the site of RH. Early July this was reported as fixed.
A user reported: the Fedora Core 4 install of the (new to FC4 rpms) wine-core-0.9.20-1.fc4 gets
fixme:ole:OLEPictureImpl_LoadGif Trying to load GIF, but no support for libgif/libungif compiled in.
M. Meissner: Yes, libgif/libungif support is not compiled in. Ask the maintainer of this RPM ;) wine archive
A user reported:I'm getting following messages if I run any program from Wine:
$ winemine wine_main_preload_info not found err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space,please report wine_main_preload_info not found
The programs still work fine after those for lines are printed. What's worse is that that Windows PE files don't work at all, including those that come with Wine. [...] Wine from git on Fedora Core development (future FC6) for x86_64, glibc-2.4.90, gcc-4.1.1, Linux 2.6.18-rc2 (actually, the current version from the wireless-2.6 branch). The CPU is Intel with EM64T. Wine is compiled with default settings for i386 by the i386 compatibility compiler and i386 compatibility libraries included in Fedora.
M. McCormack: Alexandre has committed a patch that looks like it should fix the problem to the git tree. wine archive
A user report the latest CVS gave an X error [19 April 06]: When I [...] start any program (regedit, iexplore) I get an X-crash. I did a WINEDEBUG=+all,+relay and the last X-related thing I see is :
err:x11drv:error_handler X protocol error: serial=6892, request_code=146 - breaking into debugger
After some quick detective work he reported: After doing several bisect's I decided to re-install the NVIDIA driver. Now things are fine again (I hope). So either I've messed with some settings or installing the latest (fc5) xorg-server package messed things up. [wine devel]
A Programmer noted: a program that I thought ran OK on 25 October no longer runs and no longer runs when