Change:
<del> ## build described at http://wiki.winehq.org/Wine64 </del> <ins> ## build described at https://wiki.winehq.org/Building_Wine#Shared_WoW64 </ins> source $stdenv/setup preFlags="${configureFlags}"

Discussion:
It seems wine WOW builds don't support 32-bit gstreamer. There are such messages in wine : Not sure about other libs in this list, but missing gstreamer causes errors when games try to play mp3 files. For instance, try to run Morrowind with wine32-full and wineWow-full. With the latter it will have an error in the main menu that says that it can't play mp3 file. Wine WOW is able to run Morrowind. Maintainer information:
I marked this as stale due to inactivity. &rarr;
This is still relevant. In particular, I discovered this because EA's Origin crashes after running for a while due to errors like .
On the wiki page there is this, I don't know if it's relevant:
May have a point there. Right now, we're adding both 32 and 64 bit libs into buildInputs: EDIT but I don't really see how we could do anything else for the WOW version and the the description is about the 32 version, right? We're doing the correct thing for that:
I wonder if it's related to ... Speaking of that bug (which is about the fact that binary Wine downloads are unable to use 32 bit GStreamer, when using FHS environments like Bottles)... Some 32 bit games, when I play them in an FHS environment like Bottles, do have a working GStreamer, if I use system Wine WOW (from nixpkgs). I experience this for example with "Ultimate Spider-Man" or "Spider-Man: Shattered Dimensions". I play them without Bottles? Crash. I play them with Bottles? Working videos. But not all games do this (e.g. Oblivion, which has not working audio in both cases). (Note: this comment may be a false alarm that deserves a separate issue, since Wine on my end seems to have problems even without GStreamer, if I use it outside a FHS environment. For example, with 32 bit Wine, Ultimate Spider-Man crashes on boot anyway, while Spider-Man Shattered Dimensions has huge graphical issues)
Still relevant. It happened again (on latest unstable) with specific game on package; however the very same game was working fine on wine 8.5, somewhere within a week timeframe before .

I do not claim that the update caused a regression, most likely issue is about changes in dependencies. Just to clarify: working version - broken version -
Bisected to with error build log vs have you tried using wineWow 8.10 with any 32-bit game? If so, do you have any errors like that one? It's weird.
What game exactly? I tried running Sonic Mania (which is 32 bit) on a fresh prefix, and it runs fine. Also, the error: Doesn't necessarily mean that something is wrong, it's possible that it tries to load the 64 bit plugin first, and then successfully loads the 32 bit plugin with no log. Have you tried on a fresh prefix?
Game is Cyanotype Daydream. Sadly fresh prefix does not fix it. What bothers me is that Wine 8.05 does not have these warnings, yet 8.10 does. Nix is supposed to be all about reproducibility, so different wine versions looking for libraries in different order in weird. Especially when they have identical wrappers (literally compared them with diff, both wines point to the same gstreamer related files in the same order, then launch of corresponding version) Strace logs are also similar. I took a quick look: before crash there was load of , removing it didn't fix anything. There might be other environment impurities that could potentially break things.
Shot in the dark, but maybe this is a regression upstream?
That's unlikely, otherwise we would have seen a lot of similar reports. Turns out root of all evil is nvidia (haha, classics). I have optimus laptop / hybrid graphics (nvidia prime), yet game has never been launched on dGPU, iGPU was used instead. But for the sake of experiment I decided to completely remove nvidia from system config and did nixos-rebuild after that. Same warnings were printed, but game worked in the end! So nvidia randomly breaks things on wineWow 8.10 and works on wineWow 8.05, no idea why. At the same time (pure 32-bit only wine 8.10) works fine on nvidia + intel setup.
Let's go back to the original issue, though. The problem is that pkgconfig is bad at picking the right architecture.

(As I said on ) I see two ways to fix this: 1) The dirty way is in , before starting to configure the 32 build, to prune out all 64 bit derivations from . Or alternatively, replace it with from . Problem is... how do I do that? 2) Rework how is built. Instead of building everything in a single derivation, split in two derivations: one that stops after building (let's call it ), and the other (the actual ) that finishes from where wine64Build left off. This way, we can use as a starting point for , and have only 32 bit dependencies in the environment. Problem is, in nixpkgs Wine wasn't set up for doing all this. For example, staging patches are obtained by overriding the derivation, meaning that won't be patched since it's just an input. Other example, Wine uses a fully fledged builder that isn't meant to be divided in phases like this.
oof ok. I think longer term, exporing your second proposal of re-using the 64bit build's build directory could be well worth it. Originally, I created as a straight port for but that's been a few years back and may have been updated / superseded, so it may be worth revisiting that at some point
On the other hand, though, upstream is working to remove the need for 32 bit dependencies in the first place. When completed, that would make this effort a bit useless. (Info on )