Change:
Project description There is a great wine package currently in NixOS but it lacks mingw support for the DLLs. This is needed for a few games including World of Warcraft it seems. Basically we need to build WINE with "--with-mingw" compile flag. The problem I have here is - I have no idea how to actually include the mingw compiler as a dependency to WINE. Any help here would be appreciated. Metadata homepage URL: | source URL: n/a license: n/a platforms: linux
cc
I think something like this should work: You should see something like this in your build output: I've had to do something similar when trying build Guy1524's Easy Anti-Cheat fork:
Maybe it would make sense to add a parameter to handle this?
I am not sure what it actually does, but maybe
Thanks a lot for that - I also another problem which your linked code sorted - the "compiler cannot create executables" error - strictDeps looks to have solved it though. :+1: I can tell you - it uses the mingw compiler to compile "PE DLLs" (I believe this is in reference to Windows PE DLLs but could be wrong.) It then uses these in place of the normal fake builtin DLLs it uses. This enables a much more convincing Windows environment which some apps / games appear to need.
Ahhh makes perfect sense. Do I understand correctly that build closure grows quite a bit? Any impact on runtime closure? I will merge a PR adding an off-by-default MinGW option, absent some well-grounded onjections, but maybe it should indeed be off-by-default. I guess if runtime closure change is small and build closure change is within 20% or so, we could enable by default…
I'm not too sure what closure means in this context D: What I will say, however, is that this is OFF by default in most distros so I think it should be as an option and not enabled by default - just as you suggested. Your changes got me a lot further in to the build but I believe I am missing one critical change - the build runs correctly and starts building DLLs via mingw but then fails out with: Actual overlay pkg (including the fix for exactly this error from your code linked above.) I wonder if mingw is ignoring the hardeningDisable flag or is using defaults somewhere? We're so close to fixing this I can feel it! :+1: :
I think Arch builds wine with mingw: () In official wine repos for fedora () there are lines: and for Ubuntu (), there is mingw-w64 in . So, if it doesn't increase closure size by too much, I'd say it's a good idea to enable it by default.
Transitive closure: deps, deps-of-deps, deps-of-deps-of-deps-of-deps… This can go over runtime or build-time dependencies, of course But yes, no need to look too deeply into impact if the default is off.
Hmm, it worked for me when specifying . Maybe there is a problem with using ? The Nixpkgs manual strongly recommends using instead of . I think it's very likely that's the cause: I'll gather information about the closure sizes for each configuration (wine32, wine64, wineWow) and I'll also look into creating a PR that adds a new support flag.
I hadn't noticed that little difference - changed it to overrideAttrs and it's now building properly from the looks of things. Thanks again for all of your help on this - that's super helpful! :+1: It looks like it was disabled by default in Gentoo (in: ) due to the following bug: ^ This may not be all that relevant to NixOS - just wanted to bring it to your attention.
Hm, interesting. We'll see. if it is default-off, feel free to skip the closure-measuring step for anything you are not going to use anyway. No need to build something just for that.
I noticed that runtime closures were dramatically increased with this option: wine32 (minimal): 829.3M -2.6G wine64 (minimal): 912.5M -2.6G wineWow (minimal): 1.5G -4.9G It looks like development header files from are being referenced in all DLLS under . For example, these paths are referenced in the wine32 build: Right now I'm looking into why they're being and if they can be removed / reduced.
If mingw is disabled by default, perhaps it could be as a new attribute so that it's cached? Considering it's enabled by default in (at least) Arch and official wine repos, some users may expect it to be enabled by default in NixOS too. Having to override wine for e.g. lutris and also build wine (which takes a pretty long time) is a lot of friction for an unexperienced NixOS user (or someone with not so powerful hardware).
Preferably we would enable it by default. Once, binutils 2.34 is which contains the we can re-enable stripping to avoid the closure increase caused by the header references.
Considering the OP mentioned specifically games, I'll just mention that lutris now ships (via its "runners" machinery) wine 5.21 with mingw.
Now that has been merged you can just use: This isn't currently enabled by default or cached, but does this solve your issue? Hopefully we can enable this on the base build once is merged, and after stripping is enabled.
I don't seem to be able to overwrite to enable . It does work for though. It complains about a missing hexdump dependency and a patch that it is unable to apply.
Did you eventually get WoW 9.0.2 running? Starting ends in an Access Violation popup for me. This is on wine 5.22:
Just a heads up, I noticed a regression running Cities: Skylines (specifically the Paradox Launcher) with : It looks like this is a problem upstream (I have the exact same problem with Lutris wine), but for now I'm just forcing it to launch with a wine built with .
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Discussion:
xineramaSupport = true; xmlSupport = true; sdlSupport = true; <ins> mingwSupport = true; </ins> }; full = base.override {