Broken with Wine from WineHQ

[p0358]

Results in the following error:

Microsoft (R) C/C++ Optimizing Compiler Version 19.36.32535 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

cl : Command line error D8037 : cannot create temporary il file; clean temp directory of old il files

Not really an issue for me, since I just used the Wine from Debian repos, and that apparently just solved it. So leaving that in here if anyone else runs into the same issue...

---

Also, if using Debian 12 and installing wine64, the executable wine64 is installed to /usr/lib/wine, which is not in PATH. So someone writing a Dockerfile needs to either manually add it to path, or do ln -s /usr/lib/wine/wine64 /usr/bin/wine64.

Now this is a thing that could be theoretically fixed here by the project, because I think that wine64 is equivalent to WINEARCH=win64 wine, and also wine should be in path. Either that, or to add some path detection perhaps? If Ubuntu bases their packages on Debian, then it might eventually became an issue on it as well.

[mstorsjo]

Results in the following error:

Microsoft (R) C/C++ Optimizing Compiler Version 19.36.32535 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

cl : Command line error D8037 : cannot create temporary il file; clean temp directory of old il files

Not really an issue for me, since I just used the Wine from Debian repos, and that apparently just solved it. So leaving that in here if anyone else runs into the same issue...

That's weird, but I kinda think I remember seeing this some time with some older version. Can you mention what version of Wine this was with?

It's not so much about who provides it (WineHQ vs distro) but about the version; generally I'd assume WineHQ binaries would be newer so I'm surprised that you ran into this issue. (I just tested with latest wine from git, and that seems to work fine.)

Also, if using Debian 12 and installing wine64, the executable wine64 is installed to /usr/lib/wine, which is not in PATH. So someone writing a Dockerfile needs to either manually add it to path, or do ln -s /usr/lib/wine/wine64 /usr/bin/wine64.

Now this is a thing that could be theoretically fixed here by the project, because I think that wine64 is equivalent to WINEARCH=win64 wine, and also wine should be in path. Either that, or to add some path detection perhaps? If Ubuntu bases their packages on Debian, then it might eventually became an issue on it as well.

FWIW, ideally I'd just be using wine everywhere, but in many cases on x86, wine requires having the 32 bit variant of wine installed too (else it whines quite loudly, or possibly fails), and installing the 32 bit part is a bit of a hassle (especially on things like GitHub Actions runners). Just invoking wine64 bypasses this... With the newer setup of building most of wine as PE modules, this might be less of an issue in the future though.

[p0358]

Can you mention what version of Wine this was with?

So that's kinda weird, since I've tried on both winehq-stable and winehq-devel (I remember starting with stable and then mistyping the name of devel first time around lol), so that'd be 8.0.x and 8.11 respectively. While version in Debian's bookworm repos is 8.0~repack-4, so that's overall pretty odd to me too...

The only idea I have is that maybe the WineHQ version has more deps specified as recommends (didn't check that), and I installed with --no-install-recommends (as honestly who wants to pull 1-2 GB of unneeded junk that they'd otherwise pull). I did install the deps you mentioned in the readme though in both cases.

FWIW, ideally I'd just be using wine everywhere, but in many cases on x86, wine requires having the 32 bit variant of wine installed too

I realized after typing it out later on that indeed when there's just wine64 installed, there might actually only be wine64 executable... in which case disregard what I said. I think the only worthwhile solution to what I ran into would be running some simple path detection routine that could also check /usr/lib/wine too including PATH (perhaps allow manual override with env var?), and use that detected path instead of just trying to exec wine64?

[johnsonjh]

I'm not sure this applies any longer, I've used winehq wine successfully.