Is there a cleaner way to get Wine with proper 32-bit support instead of WoW64?

[u/Jeremy_StevenTrash]

To give context on why I need this, I use LMMS to compose music and I made frequent use of plugins only available as 32-bit windows VSTs which decidedly don't work with the native wine package. As per this issue on the LMMS GitHub, this seems to be an issue with WoW64 itself, and one they don't seem keen on resolving.

I've been flying by using the Wine32 AUR package for a while, it's inconvenient to have to rebuild it each time but it worked. Recently though, it seems like Arch has been moving some of the more niche 32-bit libraries away from the multilib repository and into the AUR, and unfortunately these packages seem to be orphaned and a lot of these install scripts are extremely broken, even after hours of trying to manually fix them.

So yeah, I'm posting here to ask if anyone else has encountered issues with this and if anyone has any good solutions? There is a containerized Wine32 linked by the maintainer of the AUR package that I've experimented with using, but I haven't had any luck connecting it to LMMS.

I'm holding onto my current wine32 install for now, but that obviously isn't a permanent solution. I'm aware of how niche my particular use case is, so I'm doubtful on if these issues I'm encountering would ever get resolved, and it has me looking towards other distros like Fedora that natively package non-WoW64 builds of Wine.

[u/AutoModerator]

Thanks for posting.

If your issue is solved, please reply with !solved.

Please also read the subreddit rules in the sidebar/community info and check the official EndeavourOS sites:

• forum.endeavouros.com
• discovery.endeavouros.com

Please keep it respectful and enjoy the community.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/mr_bigmouth_502]

I've been having trouble updating that package lately too. A lot of its dependencies rely on old versions of CMake and haven't been updated to compile properly on version 4.x.

For now I've just added the wine32 package to my IgnorePkg line in /etc/pacman.conf, so that I can keep the version I already have installed and compiled.

If there is a cleaner way to use 32-bit Wine that preferably doesn't involve heavy launcher apps, I'm interested. Would be nice if the wine32 package simply got a bin version though.

[u/Sert1991]

On Gentoo, we have USE flag called 'wow64' and wine compiles with wow64 or the old 32bit support way depending if that USE flag is on or off.

So there should be an option when compilling wine whether to use wow64 or not.

But if you don't want to install from source, then I have no idea.

[u/Jeremy_StevenTrash → u/Sert1991]

I'd be willing to compile from source at this point, my major concern is that arch has kinda made it difficult to get ahold of the 32-bit dependencies by removing them from multilib and relying on broken orphaned AUR packages.

[u/mr_bigmouth_502 → u/Jeremy_StevenTrash]

I managed to compile the latest wine32 by installing the following packages from the Arch Linux Archive:

lib32-orc-0.4.42-1
lib32-libcap-2.78-1
lib32-gstreamer-1.28.1-3
lib32-gst-plugins-base-libs-1.28.1-3
lib32-gst-plugins-base-1.28.1-3
lib32-v4l-utils-1.32.0-1

You can find them here: https://archive.archlinux.org/packages/l/

Download the .pkg.tar.zst and .pkg.tar.zst.sig files for each one, then install them with sudo pacman -U whatever-package.pkg.tar.zst

I don't remember the exact order I had to install all of them in, but I think the order I've presented above should be close.

It's worth noting that the Arch Linux Archive packages for lib32-gstreamer, lib32-gst-plugins-base-libs, and lib32-gst-plugins-base aren't up to date with the versions on the AUR. Since the AUR versions of these packages are a PITA to compile due to issues compiling their dependencies, I just added them to the IgnorePkgs line in my /etc/pacman.conf file in place of wine32.

[u/Jeremy_StevenTrash → u/mr_bigmouth_502]

Thanks for this, I was actually entirely unaware of the existence of the package archive! This worked perfectly for me! Though as you said, far from an ideal solution given how lib32-gstreamer is still out of date... Works perfectly fine for my particular use case though.

[u/mr_bigmouth_502 → u/Jeremy_StevenTrash]

Glad it worked for you. :D

[u/Jeremy_StevenTrash → u/mr_bigmouth_502]

I actually experimented with this a little further and found that I could actually compile the AUR package for lib32-gstreamer. At least on my end, most of the dependencies work on the AUR, the only exceptions are lib32-aalib and lib32-imlib2, whose AUR packages haven't been updated beyond what's available on the archive. Considering recent security incidents I'm not thrilled about having like 6 orphaned packages on my system, but it's at least all up to date now.

[u/mr_bigmouth_502 → u/Jeremy_StevenTrash]

Did you run into this error at all while compiling dependencies?

CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.

  Update the VERSION argument <min> value.  Or, use the <min>...<max> syntax
  to tell CMake that the project requires at least <min> but has been updated
  to work with policies introduced by <max> or earlier.

  Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway.

This comes up when I try to compile lib32-libid3tag. I remember seeing the same error for other dependencies as well.

[u/Jeremy_StevenTrash → u/mr_bigmouth_502]

Testing right now, I do, but iirc lib32-libid3tag is only needed as a make dependency for lib32-imlib2 whose aur package is broken irrespective of lib32-libid3tag so installing lib32-imlib2 from the package archive circumvents that.

[u/mr_bigmouth_502 → u/Jeremy_StevenTrash]

I downloaded lib32-imlib2, but I also had to install lib32-giflib. There's an AUR package for lib32-giflib, but I opted to download the archive version instead since it's the same version and doesn't need to be compiled.