Re: README: add a note about 64-bit Wine needing 32-bit Wine to work
Austin English <austinenglish(a)gmail.com> wrote:
+ http://wiki.winehq.org/Wine64 for details. Note that a 64-bit Wine + build will not work without also building 32-bit Wine.
This statement is not true in general. Actually 64-bit Wine build works just fine without any 32-bit part. That's just a useless configuration, but it's a minor detail. -- Dmitry.
On Sun, Nov 29, 2015 at 10:37 PM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote:
Austin English <austinenglish(a)gmail.com> wrote:
+ http://wiki.winehq.org/Wine64 for details. Note that a 64-bit Wine + build will not work without also building 32-bit Wine.
This statement is not true in general.
Actually 64-bit Wine build works just fine without any 32-bit part. That's just a useless configuration, but it's a minor detail.
-- Dmitry.
Good point. How do you feel about: + http://wiki.winehq.org/Wine64 for details. Note that a 64-bit Wine build + will not work for most applications without also building 32-bit Wine. -- -Austin
Austin English <austinenglish(a)gmail.com> wrote:
+ http://wiki.winehq.org/Wine64 for details. Note that a 64-bit Wine + build will not work without also building 32-bit Wine.
This statement is not true in general.
Actually 64-bit Wine build works just fine without any 32-bit part. That's just a useless configuration, but it's a minor detail.
-- Dmitry.
Good point. How do you feel about: + http://wiki.winehq.org/Wine64 for details. Note that a 64-bit Wine build + will not work for most applications without also building 32-bit Wine.
Why do you need that? README already mentions 64-bit Wine and references this wiki page. -- Dmitry.
On Sun, Nov 29, 2015 at 10:56 PM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote:
Austin English <austinenglish(a)gmail.com> wrote:
+ http://wiki.winehq.org/Wine64 for details. Note that a 64-bit Wine + build will not work without also building 32-bit Wine.
This statement is not true in general.
Actually 64-bit Wine build works just fine without any 32-bit part. That's just a useless configuration, but it's a minor detail.
-- Dmitry.
Good point. How do you feel about: + http://wiki.winehq.org/Wine64 for details. Note that a 64-bit Wine build + will not work for most applications without also building 32-bit Wine.
Why do you need that? README already mentions 64-bit Wine and references this wiki page.
-- Dmitry.
Not everyone is going to bother to open a webpage. -- -Austin
On 30.11.2015 05:37, Dmitry Timoshkov wrote:
Austin English <austinenglish(a)gmail.com> wrote:
+ http://wiki.winehq.org/Wine64 for details. Note that a 64-bit Wine + build will not work without also building 32-bit Wine.
This statement is not true in general.
Actually 64-bit Wine build works just fine without any 32-bit part. That's just a useless configuration, but it's a minor detail.
It depends on your definion of "works just fine". Various parts of wine contain hardcoded paths to 32-bit executables, which can't work in a pure 64-bit build. programs/winemenubuilder/winemenubuilder.c: fprintf(file, "Exec=env WINEPREFIX=\"%s\" wine %s %s\n", tools/wineapploader.in exec wine "$appname" "$@" Not sure if there is a way to express it a bit better, but I think in general it probably wouldn't hurt to have this documented somewhere in the source tree.
Sebastian Lackner <sebastian(a)fds-team.de> wrote:
+ http://wiki.winehq.org/Wine64 for details. Note that a 64-bit Wine + build will not work without also building 32-bit Wine.
This statement is not true in general.
Actually 64-bit Wine build works just fine without any 32-bit part. That's just a useless configuration, but it's a minor detail.
It depends on your definion of "works just fine". Various parts of wine contain hardcoded paths to 32-bit executables, which can't work in a pure 64-bit build.
By "works just fine" I mean that 64-bit Wine build is able to execute 64-bit Windows applications and built-in Wine programs.
programs/winemenubuilder/winemenubuilder.c: fprintf(file, "Exec=env WINEPREFIX=\"%s\" wine %s %s\n",
tools/wineapploader.in exec wine "$appname" "$@"
That's just a symlink to the launcher, and probably it should depend on actual build.
Not sure if there is a way to express it a bit better, but I think in general it probably wouldn't hurt to have this documented somewhere in the source tree.
Sure. -- Dmitry.
On 30.11.2015 06:04, Dmitry Timoshkov wrote:
Sebastian Lackner <sebastian(a)fds-team.de> wrote:
+ http://wiki.winehq.org/Wine64 for details. Note that a 64-bit Wine + build will not work without also building 32-bit Wine.
This statement is not true in general.
Actually 64-bit Wine build works just fine without any 32-bit part. That's just a useless configuration, but it's a minor detail.
It depends on your definion of "works just fine". Various parts of wine contain hardcoded paths to 32-bit executables, which can't work in a pure 64-bit build.
By "works just fine" I mean that 64-bit Wine build is able to execute 64-bit Windows applications and built-in Wine programs.
But not if a user tries to run the built-in program with one of the shell script wrappers. ;)
programs/winemenubuilder/winemenubuilder.c: fprintf(file, "Exec=env WINEPREFIX=\"%s\" wine %s %s\n",
tools/wineapploader.in exec wine "$appname" "$@"
That's just a symlink to the launcher, and probably it should depend on actual build.
Not sure if there is a way to express it a bit better, but I think in general it probably wouldn't hurt to have this documented somewhere in the source tree.
Sure.
Actually, when I think a bit more about it, instead of adding more documentation, we probably just want to fix those few remaining symlink / wrapper script problems. Of course it will still confuse unexperienced users who want to run their 32-bit apps, but at least experienced users could use it as an (almost) fully functional standalone Wine version then - of course at their own risk. ;)
Sebastian Lackner <sebastian(a)fds-team.de> wrote:
programs/winemenubuilder/winemenubuilder.c: fprintf(file, "Exec=env WINEPREFIX=\"%s\" wine %s %s\n",
tools/wineapploader.in exec wine "$appname" "$@"
That's just a symlink to the launcher, and probably it should depend on actual build.
Not sure if there is a way to express it a bit better, but I think in general it probably wouldn't hurt to have this documented somewhere in the source tree.
Sure.
Actually, when I think a bit more about it, instead of adding more documentation, we probably just want to fix those few remaining symlink / wrapper script problems. Of course it will still confuse unexperienced users who want to run their 32-bit apps, but at least experienced users could use it as an (almost) fully functional standalone Wine version then - of course at their own risk. ;)
I'd argue that users should be strongly advised to use pre-built wine packages because building a package requires a lot of intimate knowledge. All these mixed WoW setups, "soft" dependencies (which are actually "hard" for production builds), multiarch nuances, and some other things that experianced packagers are aware about may easily cause endless headaches for a user. For instance using mixed WoW64 setup may actually break more things than fix, bugzilla has numerous bug reports about that. That's what actually needs to be added to the readme imho. -- Dmitry.
On Mon, 30 Nov 2015 13:40:51 +0800 Dmitry Timoshkov <dmitry(a)baikal.ru> wrote:
I'd argue that users should be strongly advised to use pre-built wine packages because building a package requires a lot of intimate knowledge.
--CentOS/RHEL/Scientific Linux packages are pure 64 bit. Users have been begging for months for proper packages. Red Hat has refused to provide them and now so have we. --FreeBSD packages both 32 and 64 bit Wine, but doesn't support WoW64. https://forum.winehq.org/viewtopic.php?f=2&t=25600 -- Rosanne DiMesio <dimesio(a)earthlink.net>
On 11/30/2015 03:20 PM, Rosanne DiMesio wrote:
On Mon, 30 Nov 2015 13:40:51 +0800 Dmitry Timoshkov <dmitry(a)baikal.ru> wrote:
I'd argue that users should be strongly advised to use pre-built wine packages because building a package requires a lot of intimate knowledge.
--CentOS/RHEL/Scientific Linux packages are pure 64 bit. Users have been begging for months for proper packages. Red Hat has refused to provide them and now so have we. That's not "Red Hat". The Fedora and CentOS/EPEL Wine maintainers are not employed by Red Hat but are part of the community.
The issue with EPEL is that RHEL7 dropped 32bit support. And CentOS7 took a long time to do a 32bit version. That's now out for 1 months or so and there the issue can be fixed properly now.
--FreeBSD packages both 32 and 64 bit Wine, but doesn't support WoW64. https://forum.winehq.org/viewtopic.php?f=2&t=25600
bye michael
On Mon, Nov 30, 2015 at 8:20 AM, Rosanne DiMesio <dimesio(a)earthlink.net> wrote:
On Mon, 30 Nov 2015 13:40:51 +0800 Dmitry Timoshkov <dmitry(a)baikal.ru> wrote:
I'd argue that users should be strongly advised to use pre-built wine packages because building a package requires a lot of intimate knowledge.
--CentOS/RHEL/Scientific Linux packages are pure 64 bit. Users have been begging for months for proper packages. Red Hat has refused to provide them and now so have we.
I don't think refused is accurate, deferred or delayed might be. -- -Austin
participants (5)
-
Austin English -
Dmitry Timoshkov -
Michael Stefaniuc -
Rosanne DiMesio -
Sebastian Lackner