Fedora

From Wine-Wiki

Jump to: navigation, search

Contents

[edit] Introduction

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 Extras:

And even 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 the previous discussion 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 [2] 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[1] 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.

1 - http://fedoraproject.org/wiki/AndreasBierfert/Wine 2 - http://fedoraproject.org/wiki/EPEL

[edit] 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.

wine-debuginfo. wine-devel

M. Hearn [cautioned]: [If you dont install] wine-tools[...] [you] will be missing:

  • winecmd
  • notepad
  • winedbg
  • winepath
  • winhelp
  • _EXPLORER_

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.

[edit] 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...

[edit] Official Fedora packages for Wine

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 latest and greatest wine.

N. Gompa[May 06]: Usually about a week after Wine Project releases a version, Fedora Extras updates to the newest version. [...] for Wine-0.9.13, [...] it only took 3 days to release it. [wine archive] The links below are to the webview of Fedora Extras:
x86

Note that it is viewing the alphabet group of "W". Scroll down a bit and you will see Wine packages wine archive x86_64


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...

N. Gompa [Mar 06]: for Fedora Core 3, 4, and 5, simply using terminal, sudo into root, and then do "yum install wine" to get the latest WINE packages. Also, [...] Fedora Core 3 has to manually be configured for Fedora Extras. wine archive

[edit] Wine Packages for Fedora

Fedora Core Rpms are available on the WineHQ download page: WineHQ Download Page

[Dec 05] A user noted: The regular [prebuilt wine] i686 RPMS work just fine for me on x86_64 FC4. wine archive

[Dec 05] However recently the official builds are a little slow, which prompted a user to ask where to get the latest builds. A. Gibson: I just use the SUSE 10 rpms on FC4. They seem to work fine on FC4 [but then he noticed] Fedora extras repo has Wine now (currently 0.9.4) so no need to wait[...] [wine archive http://www.winehq.org/pipermail/wine-users/2006-January/020093.html] [Jan 06] Another user noted: for FC4 Red Hat is providing a copy of Wine in extras. This is [..] in a different form from the one put out by Wine HQ. [...] The version posted by RH seems to be later than what is posted by Wine HQ. D Navea: the wine included in fc4 is customized by redhat.. there are no new features in it afaik. wine archive

[edit] Building from Source with Fedora

As Wine is under active development, users should try the latest version with its many bug fixes.

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"


[edit] 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.

[edit] Troubleshooting Build problems

Dec 08
[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).


Aug 08
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 -

Feb 06
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[2]: *** [widl] Error 1
make[2]: 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


Oct 05

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 [1] installed. There seems to be a problem [2] with that library, suggest you use/install libungif4-dev [3] instead. wine archive

  1. http://packages.ubuntu.com/hoary/libdevel/giflib3g-dev
  2. http://www.winehq.com/hypermail/wine-devel/2005/05/0948.html
  3. http://packages.ubuntu.com/hoary/libdevel/libungif4-dev


[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

[edit] Troubleshooting Installing and Using Wine on Fedora

[edit] SELinux

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.

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.

[edit] Jun 07

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.

[edit] Sept 06

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

[edit] Jul 06

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

[edit] April 05

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]


[edit] Dec 05

A Programmer noted: a program that I thought ran OK on 25 October no longer runs and no longer runs when I recompile from that code too. [...] the program accesses invalid memory down inside the WNDPROC stuff (winproc.c line 418, it says, so I guess it means line 416). So I turn on WINDEBUG=+relay to see what is being passed...And wine segfaults.

A cause was located: It's the kernel choice. It works on the non-smp kernel and fails on the smp kernel. (2.6.9-22.EL works; 2.6.9-22.ELsmp fails, both are RedHat kernels) wine archive


[edit] Nov 05

A report of a lockup problem was resolved: It appears the latest kernel from Fedora updates fixes the lockup problem completely. Previously I was using kernels from april timeframe of FC4 to the previous released kernel-2.6.13-1.1532_FC4 with the lockup problem issue still there. It just so happens that the latest kernel-2.6.14-1.1637_FC4 fixes the problem. So to make a long story short... if you have a lockup in wine with a monster sound vortex card in FC4, make sure you have the latest or newer kernel from Fedora updates. wine archive

[edit] Oct 05

Segfault

J. Lang [Oct 05]: Running wine on my P4 with Fedora core 4 segfaults immediately, but doesn't drop into the debugger. [He then reported that] updating my system [fixed it]Wine Archive


[edit] April 05

Fedora Core 4 test2

Running notepad or regedit with wine works fine, but if I try to run any other program or the regression tests, I get this error: 

[truiken@dynamic-129-120-169-13 tests]$ wine advapi32_test.exe.so registry
wine: could not load
L"Z:\\home\\truiken\\workspace\\wine\\dlls\\advapi32\\tests\\advapi32_test.exe.so":
/home/truiken/.wine/dosdevices/z:/home/truiken/workspace/wine/dlls/advapi32/tests/advapi32_test.exe.so:
cannot restore segment prot after reloc: Permission denied

After following suggestions, J. Hawkins: Disabling SEL did the trick.
M. Hearn: It will do. Run restorecon to fix it.
I think the problem is some of our ELF libraries have text relocations, and on SELinux targetted you need to mark textrel libs as shlib_textrel_t. I know a bit about SELinux, I'll investigate this.Wine Archive Link


GCC4
The RH updates for FC3 include the new version of gcc. If you install it causes problems with things like Wine.
M. Meissner: Wine CVS will compile with current CVS and gcc 4. [If you find further problems], Please post error messages.


Failed to create the process heap.
A user found his version of Wine gave the error message "Failed to create the process heap". He downloaded and installed wine-20050419-1fc3winehq and was surprised to get the same error message.

M. Hearn identified the problem as something that is now fixed in Wine: That's an execshield/prelink failure. You definitely should not get it with the newest Wine - maybe the old version is sticking around somehow?

The user mentioned that he had compiled and installed an old version of Wine previously and wondered if this was the cause.

H. Bostick suggested to make sure it was uninstalled: This assumes that you did do a make install at the time you compiled the source. In any case, this would remove any lurking files installed from the source compile. go to the source directory and run (as root) 

make uninstall

Window Drawing Issues
A user reported: When I run windows applications there is a transparent border around the menubar and all toolbars [are] appx 5 pixels thick. This transparent border will not draw, therefore if you do something like move the window offscreen then back again, it will be filled with bad pixels from the background. This makes windows apps appear very ugly.

R. Klazes: I think that has been fixed ages ago. Please upgrade.

The user reported success.


[edit] X Error of failed request: GLXUnsupportedPrivateRequest

:X Error of failed request: GLXUnsupportedPrivateRequest

Major opcode of failed request: 143 (GLX)[...]

A user reported: From what I googled, this seems to be some missing functionality of my X server (in Fedora 4), but there is no more information on how to fix this. In the worst-case scenario that I need to recompile from source, will the source RPMS from Fedora 4 be enough?

DirectX guru O. Stieber : It looks like the X server you are using doesn't support the OpenGL related function glXMakeCurrent()[He then asked for the output of glxinfo]

J. Gavin: If [in the worst case situation, Fedora] do use some custom patchset, the source rpms probably use it too. I would expect the binary rpms to have been created using the source rpms so they probably still contain the problem. I'd try the direct source from freedesktop. [The discussin ended at this point] Wine Archive

[edit] Troubleshooting Sound and Fedora

A user reported When the binary wine-0.9 package is installed, I can choose "ALSA" or "OSS" in winecfg as sound setting and have sound. With the compiled version only "OSS" gives me sound. I have been rpmbuilding the sources on my FC3 system with the latest standard kernel-2.6.12-1.1381_FC3, [...] The binary packages were built against kernel-2.6.12-1.1380_FC3, as that was the latest available on the release date of 0.9. [...] My installed alsa rpms are: alsaplayer-0.99.76-3, alsa-utils-1.0.6-3, alsa-lib-1.0.6-8.FC3.

V. Beron: You're missing alsa-lib-devel-1.0.6-8.FC3. No wonder you get no sound with ALSA :) Wine Archive

[edit] Fedora Wine Links

Retrieved from "http://wiki.jswindle.com/index.php/Fedora"
Personal tools