You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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):
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 :)
The text was updated successfully, but these errors were encountered:
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)
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.
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):
which gives an error and totally breaks the q4wine usage:
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 :)
The text was updated successfully, but these errors were encountered: