Bug 742456

Summary:	32-bit wine won't create a 32-bit prefix on 64-bit system
Product:	[Fedora] Fedora	Reporter:	Michał Goliński <ecthelion>
Component:	wine	Assignee:	Andreas Bierfert <andreas.bierfert>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	15	CC:	andreas.bierfert, ptalbert, stefan
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-03-23 09:58:35 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Michał Goliński 2011-09-30 08:16:15 UTC

Description of problem:

I have both 64-bit and 32-bit installed on a Fedora 15 x86_64 system.

There are some Windows programs, which for some unknown reason don't want to run under the default settings (64-bit prefix) -- this is the case for Age of Empires III installer (which is a pity, because appdb gives the app itself gold status). Other 32-bit applications work fine under the default settings.

Workaround for this problem found on the internet involves setting a enviroment variable

export WINEARCH=win32

and now wine should create a new prefix, with structure emulating the 32-bit Windows only.

Unfortunately this doesn't work out of the box. I believe this to be a packaging problem (read further on).




Version-Release number of selected component (if applicable):

$ rpm -qa 'wine*'|sort
wine-1.3.29-1.fc15.x86_64
wine-alsa-1.3.29-1.fc15.i686
wine-alsa-1.3.29-1.fc15.x86_64
wine-capi-1.3.29-1.fc15.i686
wine-capi-1.3.29-1.fc15.x86_64
wine-cms-1.3.29-1.fc15.i686
wine-cms-1.3.29-1.fc15.x86_64
wine-common-1.3.29-1.fc15.noarch
wine-core-1.3.29-1.fc15.i686
wine-core-1.3.29-1.fc15.x86_64
wine-courier-fonts-1.3.29-1.fc15.noarch
wine-desktop-1.3.29-1.fc15.noarch
wine-fonts-1.3.29-1.fc15.noarch
wine-ldap-1.3.29-1.fc15.i686
wine-ldap-1.3.29-1.fc15.x86_64
wine-marlett-fonts-1.3.29-1.fc15.noarch
wine-ms-sans-serif-fonts-1.3.29-1.fc15.noarch
wine-openal-1.3.29-1.fc15.i686
wine-openal-1.3.29-1.fc15.x86_64
wine-pulseaudio-1.3.29-1.fc15.i686
wine-pulseaudio-1.3.29-1.fc15.x86_64
wine-small-fonts-1.3.29-1.fc15.noarch
wine-symbol-fonts-1.3.29-1.fc15.noarch
wine-systemd-1.3.29-1.fc15.noarch
wine-system-fonts-1.3.29-1.fc15.noarch
wine-tahoma-fonts-1.3.29-1.fc15.noarch
wine-twain-1.3.29-1.fc15.i686
wine-twain-1.3.29-1.fc15.x86_64
wine-wow-1.3.29-1.fc15.x86_64

Steps to Reproduce:
1. Install 64-bit and 32-bit packages on 64-bit system.
2. export WINEARCH=win32
3. run wincfg
  
Actual results:
$ winecfg
wine: created the configuration directory '/home/michal/.wine'
wine: cannot find L"C:\\windows\\system32\\wineboot.exe"
err:process:start_wineboot failed to start wineboot, err 2


Now the .wine directory is created, but drive_c has only one element: the directory windows/system32, no other necessary files.


Expected results:
Complete 32-bit prefix created.


Additional info:
This problem goes away once one copies by hand the file /usr/lib/wine/wineboot.exe.so from wine-wow-1.3.29-1.fc15.i686.rpm. Unfortunately the package wine-wow.i686 cannot be installed because of a conflict:

$ rpm -Uvh wine-wow-1.3.29-1.fc15.i686.rpm
wine-wow(x86-32) = 1.3.29-1.fc15 conflicts (installed) wine-1.3.29-1.fc15.x86_64

Maybe the package should be divided, to allow installation of the necessary file under 64-bit systems?

Comment 1 Andreas Bierfert 2012-03-23 09:58:35 UTC

Hi there,

sorry for picking this up so late.

Having the package conflicts in place is essentially right. For normal setups this will ensure that 32bit and 64bit wow are never mixed. What you are trying to describe is a scenario which points to a wine bug (as the mixed prefix should allow the program to install/run just fine) so this should be fixed in wine. If you really need to install wine-wow(x86-32) you can always remove the wine(x86-64) meta package and you are free to install it. This is why the conflicts are setup in the meta package. However keep in mind that leaving the recommended install may cause other problems and should be done by expert users only.