Closed GoogleCodeExporter closed 8 years ago
That is either a wine or a gentoo bug, not a winetricks bug.
Original comment by daniel.r...@gmail.com
on 29 Mar 2012 at 2:13
No, it's a valid bug Dan.
By default, wine makes 64-bit prefixes (if wine64 is compiled). Some verbs
(e.g., dotnet11) won't work in a 64-bit prefix (or windows 64-bit).
Currently, however, winetricks doesn't pass through the the WINEARCH variable.
That was my oversight when adding initial 64-bit support. I don't have a 64-bit
system handy to test this on though. Will do so when I get a chance.
Original comment by austinenglish@gmail.com
on 29 Mar 2012 at 10:40
Ah, thanks.
Original comment by daniel.r...@gmail.com
on 30 Mar 2012 at 1:36
Wait, what? winetricks doesn't have to do anything to pass through WINEARCH,
does it?
Original comment by daniel.r...@gmail.com
on 30 Mar 2012 at 1:39
This is how it fails: wine cmd.exe /c echo '%ProgramFiles%' returned empty
string
This error can be avoided if you make the default WINEPREFIX made with
WINEARCH=win32 when calling winetricks, or delete it entirely.
Basically, even though you're installing into, say, the world of goo prefix,
winetricks will still use the ~/.wine prefix to determine what %ProgramFiles%
localizes to. If you've given WINEARCH=win32 and ~/.wine is 64-bit, Wine will
error out on that step and Winetricks will give the empty string error.
The workaround is to just remove/rename ~/.wine (it's probably a bug that
winetricks is using that prefix anyway, rather than the one it's about to make
for the game).
Original comment by YokoZar
on 29 Aug 2012 at 1:28
A proper fix would involve winetricks_early_wine() setting WINEARCH, if
requested.
The %programfiles% echo is also related. Theoretically, only the requested
WINEPREFIX should be touched, but getting that done properly is trickier now
with the rewrite.
If someone can patch it, feel free, otherwise I'll work on it when I have some
spare time/machine that can test it.
Original comment by austinenglish@gmail.com
on 29 Aug 2012 at 2:04
Well, now that I have a 64-bit system handy, I don't see this anymore. Not sure
who fixed it, and I'm a bit too busy to dig into the source, so marking fixed.
Original comment by austinenglish@gmail.com
on 27 Sep 2012 at 1:17
Hi,
I'm not sure if I'm hit the same bug as the OP (the OP has not commented
since); but I believe so. I apologize if this is not the case.
However, the current behaviour on a 64 bit wine install when usin a 32bit
prefix, and using the GUI to install an application is, that a new prefix is
created at ~/.local/share/wineprefixes/[APP_NAME]. That may or may not be what
the user want's (and that is another issue, I had a little troble finding out
that there are prefixes created there) - but in any case, whether winetricks
respects the WINEARCH variable or not, depends on if a new prefix directory for
running winetricks itself was created or not.
Example 1:
# let's star on a clean table
$ rm -r ~/.local/share/wineprefixes/steam ~/.wine
$ WINEARCH=win32 winecfg
[Press OK]
$ WINEARCH=win32 winetricks steam
Results:
- a 32-bit prefix is created at ~/.wine
- a 64-bit prefix is created at ~/.local/share/wineprefixes/steam
$ rm -rf ~/.wine
$ rm -rf ~/.local/share/wineprefixes/steam
$ WINEARCH=win32 winetricks steam
Results:
- a 32-bit prefix is created at ~/.wine
- a 32-bit prefix is created at ~/.local/share/wineprefixes/steam
This is on winetricks20130707 (Gentoo).
Original comment by ville.aa...@gmail.com
on 14 Sep 2013 at 8:35
I can't reproduce your results, and can't see how they are possible
unless you made a typo, gentoo ships an intentionally broken winetricks,
or a cosmic ray hit your computer.
Original comment by daniel.r...@gmail.com
on 14 Sep 2013 at 1:42
It looks like typo or cosmic ray, their ebuild isn't doing anything crazy.
I can't reproduce this on gentoo either, fwiw.
Original comment by austinenglish@gmail.com
on 24 Sep 2013 at 1:49
Original issue reported on code.google.com by
jeremybr...@gmail.com
on 29 Mar 2012 at 1:55