Review of wine 0.9.44 on revu.tauware.de
scott at open-vote.org
Mon Sep 10 12:25:29 BST 2007
On Sat, 2007-09-08 at 08:58 +0200, Stephan Hermann wrote:
> Moins Scott,
> Scott Ritchie schrieb:
> > On Thu, 2007-09-06 at 08:35 +0200, Stephan Hermann wrote:
> >> Well, there is no problem with 32bit packages on 64bit arch.
> >> It's compiled with -m32, so we have 32bit compilations for amd64.
> >> Regarding -m32 compiled libs, they are sitting normally in /usr/lib32
> >> and not in /usr/lib on amd64 releases.
> >> The current package in revu but, is installing those -m32 compiled libs
> >> to /usr/lib, which is not "correct" for this.
> >> Therefore, we have two possibilities:
> >> 1. For 64bit archs, we compile with -m32, installing the libs to
> >> /usr/lib32 and leaving the binary package names like they are on i386.
> >> With this, we are running into problems in the future, when we ship as
> >> well a native windows64 supported version of wine on amd64
> > The hypothetical native Windows64 version of Wine must still support 32
> > bit windows applications. There is no need for separate wine32 and
> > wine64 packages, as they would both always need to be installed together
> > - otherwise, applications will mysteriously break.
> > While Linux 64 doesn't assume that 32 bit libraries are available,
> > Windows does. Wine must therefore do the same thing, for much the same
> > reason that it still has 16 bit support.
> AFAIK has Windows as well only 32bit libs on board to let 32bit windows
> apps run on windows 64, right?
I don't believe we can make this assumption. There's almost certainly a
64 bit application out there which depends on 32 bit dlls in some way -
either directly or indirectly. It may even be an application that's
part of Windows itself!
> Therefore, you actually have 2 separated (not in windows, right, because
> it installs everything by default) wine versions.
> One which can only run 64bit windows (the apps are really rare, true)
> and 32bit windows.
> Actually regarding this, we could ship in the wine packages the native
> versions (means 32bit windows in wine & wine-dev on ia32 and 64bit
> windows in wine & wine-dev for x86_64) and additionally when the user
> wants to run 32bit windows app, he could install wine32 support.
> The 16bit support of windows is history. It's only there for old apps
> from win 3.1/win95, I wonder when MS is removing this crap.
We couldn't have two "separate" Wine versions, as we'd still need a
single wineserver managing messages between 64 and 32 bit Windows
Admittedly, how this is going to be solved is still an open question
upstream, but there's little value in making a guess ourselves right
now. We can always modify the packages later once it becomes
> > You are right that Wine's 32 bit libs should go into /usr/lib32 though
> > -- that's a fairly simple change; just move the install target on the 64
> > arch. Later, a combined 32 and 64 bit package would put the 64 bit libs
> > into /usr/lib (and the old 32 bit ones into /usr/lib32). In the
> > meantime, there's no real change moving from /usr/lib to /usr/lib32
> > since we don't yet have any duplication and both are in the path.
> For this, you should update the package right now. So, it's clean and we
> don't have to change anything.
> Secondly, in the package itself, there is a "gcc-multilib [amd64]"
> build-dep missing, without it it can't compile in -m32 bit mode.
It's how I've been spending my weekend :)
> Let's get it done correctly, tbh, if we get a cool wine package for
> hardy running 32bit apps on 64bit linux, that's for Ubuntu^WCanonical
> Marketing a bit better...;)
Also interestingly, Wine 1.0 might ("should") come out some time during
Hardy's release cycle. The idea of being so involved in something that
will become a major selling feature of Ubuntu is really exciting me.
More information about the Ubuntu-motu