[pkg-wine-party] Call for testing: automatically detect wine arch and WoW64
jre.winesim at gmail.com
Thu Dec 31 20:08:56 UTC 2015
WoW64 seems to work if wineserver (from the native arch) is in /usr/bin
and the 32-bit wineserver is deleted.
No need for other build process --with-wine64=...
Should we drop the /usr/bin/wine script and link wine, wine64 and
wineserver to /usr/bin/?
On 12/13/2015 01:47 PM, Jens Reyer wrote:
> On 12/13/2015 08:11 AM, Michael Gilbert wrote:
>> On Sat, Dec 12, 2015 at 10:52 PM, Jens Reyer <jre.winesim at gmail.com> wrote:
>>> On 12/13/2015 04:06 AM, Jens Reyer wrote:
>>>> But afaics there is no need to launch different executables:
>>>> If I then have an application that works only in plain wine32 I have to
>>>> opt-out and use:
>>>> WINEARCH=win32 WINEPREFIX="$HOME/.wine32" wine ...
>>> Hmm, I added "export WINEARCH=win64" to .bashrc.
>>> Seems that only WINEARCH=win32 Desktop launcher work out of the box.
>>> The launchers for the 64-bit applications only work if a 64-bit
>>> wineserver is already running (which was the case during my previous
>> So, maybe we want wineserver to not be multiarch? So if the user is
>> on a 64-bit platform, the only wineserver we make available is the
>> 64-bit one?
> No, then we can't use win32 prefixes on a 64-bit platform.
I found that it works, as soon as you link the 64-bit wineserver to
$ sudo rm /usr/lib/i386-linux-gnu/wine/wineserver*
$ sudo ln -s /usr/lib/x86_64-linux-gnu/wine/wineserver \
$ sudo ln -s /usr/lib/x86_64-linux-gnu/wine/wineserver.real \
[Besides that I use our unchanged debian.org packages]
Seeing that, I went a step further and removed the /usr/bin/wine script
and linked the wine and wine64 binaries to /usr/bin:
$ sudo rm /usr/bin/wine
$ sudo ln -s /usr/lib/wine/wine /usr/bin/wine
$ sudo ln -s /usr/lib/wine/wine64 /usr/bin/wine64
With this I successfully installed Steam (32-bit), Origin (32-bit) and
ImageMagick (64-bit with 32-bit installer) just by issuing "wine
All are installed in a 64-bit ~/.wine.
I successfully ran all of them, either separately (no wineserver running
previously), or at the same time.
So all related issues that I am aware of are solved here:
- Generally the "automatically launch wine64".
- Origin previously failed to install in a 64-bit prefix.
- ImageMagick installed to 32-bit prefix per default, but obviously
failed to run with 32-bit wine/in that prefix.
- 64-bit desktop launchers failed, if wineserver wasn't running already.
About building a shared WoW64-Wine with "--with-wine64=..." as described
in the winehq wiki:
That wiki changed a lot (again in the last weeks) and (at least now)
states that as packager you don't have to care about "relinking" when
doing separate builds. Instead you'd just have to care about picking the
correct files (however strangely mentioning the *32-bit* wineserver). So
by now (contrary to the past) I think we absolutely don't need
I see no need for building an all-in-one monolithic WoW64 package.
So are there any reasons not to do the above? I.e. based on current
packaging, just change:
- Put wineserver in a multiarch:none page, so that only one, the native
wineserver, is installed.
- Put the wine, wine64 and wineserver binaries in /usr/bin (directly or
- That implies dropping the wine script, at least for the full
installation, see below.
Thinking about the /usr/bin/wine script:
- Users may set WINEDEBUG="" in ~/.bashrc if they want. I'd prefer that
anyway, because I find the upstream default quite helpful.
- WINEPREFIX may be set in ~/.bashrc. Not sure if this would work with
binfmt, but imo this is not relevant.
- It seems there are no transitioning issues with ~/.wine defaulting to
64-bit now, because with an existing 32-bit ~/.wine wine is happy to
- What about co-installability and co-usability of wine and
Probably add patches for /usr/bin/wineserver-development and try to get
upstream to not hardcode these filenames (I think there was a discussion
about that already recently on wine-devel).
- How to handle wine64 only installations?
Maybe make wine64 depends:wine32|wine32-dummy, and wine32
break/replacing wine32-dummy? With wine32-dummy shipping a /usr/bin/wine
script with instructions to install wine32. Should that script also call
wine64? Although not recommended there are use cases for wine64-only
Did I miss anything? (I didn't look into the -preloader packages, and
never used them previously. However iirc upstream is in process of
deprecating them mid-term. Neither do I use binfmt or -tools.)
Besides that I'd like to see my successful (very short) tests confirmed
Greets and have a good time
More information about the pkg-wine-party