Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improper usage of WINEARCH env variable that is always part of %ENV_ARGS% #162

Open
PhobosK opened this issue Aug 5, 2020 · 1 comment
Assignees
Labels

Comments

@PhobosK
Copy link

PhobosK commented Aug 5, 2020

Putting always the Wine's WINEARCH env variable in the %ENV_ARGS% is not a proper way of using it.
As it is stated in wine's FAQ (and documentation) the WINEARCH should be used only when creating a new prefix. Once created the prefix cannot be changed, so any later usage of the env var is not proper - see here

This bug cannot be noticed on systems that allow (or have) only one Wine version installed, but on systems that allow (or have) several versions it causes problems, especially when the wine executable is suffixed.
The problem is easily seen when using it with the WINELOADER env variable which is also a persistent variable in %ENV_ARGS%

For example: Gentoo allows installing several versions of Wine at the same time.

/usr/bin/wine -> /usr/bin/wine-staging-5.14
/usr/bin/wine64 -> /usr/bin/wine64-staging-5.14
/usr/bin/wine64-staging -> /usr/bin/wine64-staging-5.14
/usr/bin/wine64-staging-5.14
/usr/bin/wine64-vanilla -> /usr/bin/wine64-vanilla-5.0.1
/usr/bin/wine64-vanilla-5.0.1
/usr/bin/wine-staging -> /usr/bin/wine-staging-5.14
/usr/bin/wine-staging-5.14
/usr/bin/wine-vanilla -> /usr/bin/wine-vanilla-5.0.1
/usr/bin/wine-vanilla-5.0.1

q4wine supports this via Wine version manager, but it doesn't operate properly with the WINEARCH env variable, because it always adds it to the %ENV_ARGS%.
Thus in the above Gentoo example, if I have q4wine Wine version named Vanilla the command line will always be (when using the default template of q4wine):

/usr/bin/env  WINE='/usr/bin/wine-vanilla'  WINEPREFIX='/home/USER/prefix'  WINESERVER='/usr/bin/wineserver-vanilla'  WINELOADER='/usr/bin/wine-preloader-vanilla'  WINEDLLPATH=''  WINEARCH='win64'  WINEDEBUG='-all'  WINEDLLOVERRIDES=''  LANG=''  /bin/sh -c \"cd '/home/USER' && /usr/bin/nice -n 10 /usr/bin/wine-vanilla  explorer.exe /desktop=winecfg,800x600  'winecfg' -h 2>&1 \" "

which gives an error and totally breaks the q4wine usage:

/usr/lib64/wine-vanilla-5.0.1/bin/wine-vanilla64: could not open

This error is a Wine one because it adds the arch at the end of the binary name... But anyway the WINEARCH should not be used anywhere else besides creating new prefixes...

BTW in already existing q4wine prefixes the interface allows changing the architecture, which should not be allowed

Probably this case should also be considered when working on issue #140

Great app by the way :) and great work.
Thanks :)

@PhobosK
Copy link
Author

PhobosK commented Aug 5, 2020

After further investigation I found out that the error /usr/lib64/wine-vanilla-5.0.1/bin/wine-vanilla64: could not open is actually caused by the WINELOADER env variable alone.
This may be distro specific handling of this env variable, but still needs to be addressed... Usually the var is set automatically by Wine, so there is no need to be enforced in %ENV_ARGS%
Anyway this doesn't invalidate this issue.

IMHO the way to address such Wine specifics is to add all the major wine env variables as separate template vars like for example %WINELOADER% etc, so the user can select from them in the prefix template and %ENV_ARGS% to stay for all of them combined (as it is now)

@brezerk brezerk self-assigned this Aug 6, 2020
@brezerk brezerk added the Bug label Aug 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants