MS Windows on Linux: wine and MinGW-w64

 

I came across two separate discussions on LinuxQuestions.org that had a common root cause; a lack of Windows VST support in Carla and missing PE binary support in Wine causing Windows games to fail on Slackware.
They made me think about how I could help fix the core issue, which is that both SlackBuilds.org and Slackware 3rd party repositories (like mine) do not offer MinGW packages or scripts. To address the issue I needed to create a MinGW-w64 package, which is what I did. More on that, further down.

Back to the issue at hand and their common root cause.

Starting with Wine 5.x, the developers added support for compiling wine’s Windows programs and DLLs into Microsoft PE (portable executable) format instead of building them as Linux ELF binaries. This has advantages, one of the more obvious ones adding compatibility with some copy protection schemes in Windows games.
However with wine-5.12 and newer, it appears that the PE binary format is now a requirement for some modern Windows-based games that you can play in Wine on Linux. Diablo III, World of Warcraft and others are mentioned in the relevant bug report.

This meant that I needed to do something if I ever wanted to update my own Slackware package for wine to a newer version than the 5.6 I had in my repository. Apparently to compile binaries into native MS Windows PE format, you need MinGW, the “Minimalist GNU for Windows“. In fact, I needed MinGW-w64 whichs is a fork made in 2007 of the original MinGW which adds 64bit Windows support and a lot of other enhancements, and is actively developed. Since this is not available for Slackware as a package or SlackBuild yet, I needed to come up with my own version.

The LQ thread mentions an OS-agnostic project from developer ‘Tk-Glitch’ called  “(Mostly) Portable GCC/MinGW” which people used successfully to obtain a working MinGW compiler on Slackware. Since I was completely clueless about MinGW I started with that script, and for me indeed it built a MinGW compiler suite with support tools. Alas, the script was only meant for 64bit OS-es and of course it was not a proper SlackBuild script. So I used the project as inspiration (like, I used the script’s flow and logic) to write a SlackBuild script that would also work on 32bit Slackware.
The result is that I now have MinGW-w64 packages in my repository for Slackware-current as well as 14.2 (32bit and 64bit). The package installs a profile script to “/etc/profile.d/” which adds the MinGW binaries to your $PATH environment variable. On 64bit Slackware you will get both the MinGW programs that create 64bit Windows PE binaries (x64_64-w64-ming32-*) and those that create 32bit Windows PE binaries (i686-w64-mingw32-*). While on 32bit Slackware you will get programs that create 32bit Windows PE binaries (i586-w64-mingw32-*).

Having a MinGW-w64 package finally enabled me to compile the newest wine (enhanced with the wine-staging patch set) properly.
Since the MinGW compilers are in the $PATH, the wine-build will automatically use those where needed, no change to the SlackBuild was required. The result is a wine-5.17wine-5.18 package which has grown considerably in size due to the addition of PE binaries. I hope this package will enable you gamers to play your favorite game again.
Note that I have added new dependencies to the wine package for Slackware-current. In order to improve DirectX sound support you need FAudio.  For Direct3D 12 support, wine additionally depends on vkd3d. You’ll have to install those from my repository as well.
Both FAudio and vkd3d fail to compile on Slackware 14.2, due to a lack of Vulkan library support and outdated other libraries such as Gstreamer, so the wine package for Slackware 14.2 was built without them (but it does need OpenAL as a dependency there. This got added to slackware-current as ‘openal-soft’).

And then there was Carla, the subject of that other LQ thread.
Carla is an audio plugin host; it is contained in my Slackware Live DAW project. It supports a lot of plugin formats, like LADSPA, DSSI, LV2, VST2, VST3 and more. It turned out that my Slackware package for Carla did not support Windows VST plugins. VST is mostly used on Windows, VST is a proprietary format from Steinberg which requires a licence from them to create or host a plugin. The VST3 source code is placed under a GPL3 license; however you still need written agreement from Steinberg if you want to distribute a plugin. Nevertheless, if you are a mucisian and purchased a VST plugin then Carla needs some additional work to use that Windows VST plugin.
Again, MinGW-w64 (and wine) were needed to expand the capabilities of my carla package. Luckily, a new version of Carla was released yesterday so I could apply my newfound knowledge immediately. The new carla-2.2.0 package supports Windows VST’s. Go get it.

For the techies:
Note the different architecture used in the names of the MinGW 32bit binary compilers: “i686” on Slackware64 and “i586” on Slackware. On 64bit Slackware I compile a new gcc, binutils and all the libraries they need first, and use them as a bootstrap for compiling MinGW-w64. That is why I could switch away from Slackware’s “i586” to a new “i686” architecture target, and in principle I can use a different version of GCC than the one shipped with Slackware. On the Slackware 32bit OS I was unable to compile this “bootstrap GCC” so I needed to stick to the version of GCC which is present on Slackware and use that to compile MinGW-w64.
If someone feels adventurous and has a lot of free time, the issue on 32bit Slackware is that after I compile various support libraries, then binutils and then gcc, I can not complete the gcc compilation because it ends prematurely with an error “/tmp/build/mingw_gcc_bootstrap/bin/ld: cannot find -lc“. Apparently the linker does not search /lib or /usr/lib for whatever reason. If I add symlinks for libc into “/tmp/build/mingw_gcc_bootstrap/lib/” then I get a little further in the process, but then the same happens for -lm”. Etcetera. I do not have this issue on 64bit Slackware where I use my multilib version of gcc packages… no idea whether that makes the difference. So in 32bit Slackware I just skip compiling my own GCC and move immediately to compiling MinGW. Suggestions are welcome and appreciated.

Have fun with this! Eric

Note: I used one of Dave Gauer’s logos for MinGW-w64 to decorate this blog page.

29 thoughts on “MS Windows on Linux: wine and MinGW-w64

  1. Hi Eric

    I am not a gamer, but the effort and results are an important contribution to slackware. THANKS for your effort and contribution to keep skackware in shape with user’s demands.


  2. Hello Eric,

    I concur to what Francisco said…

    Just a little remark: you wrote: “Apparently to compile binaries into native MS Windows PE format, you need MinGW, the “Minimalist GNU for Windows“.

    Alternatively you could compile binaries in ELF format then convert these binaries to PE using objcopy, shipped in Slackware. That’s what software like elilo or grub do to write UEFI images, as per the UEFI specification these images should be in a PE/COFF format.

    Cheers, Didier


    1. Hi Didier,

      Yes objcopy can convert ELF binaries into PE format.
      However, that does not make them MS WIndows binaries. The PE binaries produced by MinGW do not use the Linux C library, they call functions in the MSVC runtime. The idea here is to produce code that can run as native binaries in a Wine environment, or in the actual Windows OS for that matter.



  3. Oh way cool! I thought that the mingw package in the distro-agnostic script created a 32-bit mingw environment, as well? I could’ve sworn seeing things compiled with it in the console spew when building the 32-bit part of WINE. I’ll definitely switch to your package, though, because your stuff just works.

    The profile script obviates the need to point to mingw-64 in the wine slackbuild?

    WINE post 5.12 is kind of a mess lately, though. It seems like the non-game things I use it for (scrivener, scapple) are fine, but it’s hit or miss whether or not something will break with a given game. I’m on 5.16 staging at the moment, and it’s been a bumpy ride. (Although Origin also works with the PE-enabled build, while it didn’t before.)


    1. Hi Jen,

      I assume you are on a 64bit multilib Slackware computer, yes? There, MinGW-w64 will build tools to create 64bit as well as 32bit Windows binaries (x86_64-w64-mingw-* and i686-w64-mingw32-* compiler programs).
      However, the same script will not work on 32bit Slackware. There’s not so many Linux distributions out there anymore that are available as a 32bit variant.



  4. Thank you! I was wondering what was preventing your repository from providing newer WINE versions. Unfortunately, I’m still on stable with my old Pentium D platform. I’ll have to try your ideas out with stable. Are these slackbuilds available in the normal repository locations?



  5. Speaking of Wine, good luck when you get around to 5.18. Even after building vkd3d-1.2 it is giving me headaches finding the correct libs.


    1. Hmm looked OK here when I tried a compile.
      I will release a 5.18 update soon-ish. I need to strip the new .dll files anyway in the wine package since they currently blow up the package size.


    2. Dumb question, but is mingw showing up in your path? I had to log out/log back in before it did. (I forgot to do so after installing it last night.)


      1. Yes, that is how profile scripts work, they are interpreted when you login. Which means, if you install a package that comes with a profile script you either logout/login or else you source that profile script in your current session (execute “source /etc/profile.d/mingw-w64.sh”).



          1. MinGW wasn’t the problem that part works fine, it was not finding the headers for vkd3d_shaders. I ended up kludging around that problem by copying the header file to the source directory. The real solution would involve making both slackbuilds for vkd3d-1.2 and making sure everything is really in the correct places. TBH building a multilib WINE is about the extent of my abilities, it is a wonder I can pull it off in the first place.
            PS Also made a compat32 of FAudio, I needed for the 32 bit part of the build.


  6. Hello,
    it’s most likely a silly question, but… MinGW-w64 package is required only for building Wine, not for simply using it…?



  7. Hi Eric. Thanks for providing these packages. Mine is also a silly question.
    If I would like to run 32-bit Windows executables under Wine do I need to have a multilib base system? (My Slackware is 64-bit now).
    Thanks!


    1. Eduardo, yes, you will need a multilib installation.
      It’s just like running 32bit Linux binaries on a 64bit Slackware – you need multilib for that. Likewise, you can run 32bit Windows programs only if you install the 32bit wine part. On a 64bit Slackware computer without multilib, all you’ll get is wine64 which is able to run 64bit WIndows programs only.



  8. Kudos for the MinGW packages Eric, thanks a lot will come in handy, I used mxe’s portable MinGW implementation and it is really not practical, as a sidenote, your wine packages still miss one feature I’ve noticed, d3dvk, wine’s DirectX12 implementation, I managed to build it for myself, but I figured out it would help you releasing the most feature complete Wine packages possible, here it is :
    https://github.com/HansKristian-Work/vkd3d-proton

    Cheers Eric, thanks again !


    1. Hi Svoboda, here at home I already have a wine-5.18 compiled against a (yet) unreleased vkd3d package. Those will be uploaded soon, but I am looking at Slackware 14.2 as well to build some of the new stuff.



      1. vkd3d-proton is the “more-advanced” fork where dvkv devs(Hans Kristian is one of them, I thunk they’re being sponsored by Valve) are bringing along DX12 features at a faster pace than the base vkd3d.
        They recently got Horizon: Zero Dawn working on Linux and, in doing so, also discovered some Nvidia Vulkan driver bugs, where rocks would be shown floating in the air.
        A vkd3d-proton Arch maintainer just yesterday posted on Discord his PKGBUILD (https://gist.github.com/Saancreed/25a42fccf8329ff05b66f8c5261ac836) for a system-wide installation of vkd3d-proton, that also leverages a properly edited install script from the DXVK project to ease the installation of vkd3d-proton DX12 dlls into a WINEPREFIX. He also mentioned that, by using the “–symlink” option when installing the dll in a WINEPREFIX, one can expect the prefix (or “bottle”, as I understand are called wine prefixes) to be automatically updated as soon as one builds a newer vkd3d-proton system package.


  9. Doh, I just spent the last 6 days in getting a working SlackBuild for mingw-w64 to compile on Slackware64 14.2 to play around with wine-staging >_<
    I struggled also in finding proper build instructions, as the official ones (https://sourceforge.net/p/mingw-w64/wiki2/Cross%20Win32%20and%20Win64%20compiler/) are a bit outdated.
    I initially went the multilib route but finally decided against it, as downstream projects (like wine) expect a separate 32-bit toolchain anyway and forcing them to work on a multilib setup brings serious linking-time headache problems… I've tried T_T
    Thanks for the package, will definitely try your version when I've time, as I think it will be more dependable than mine ^_^


  10. Has anyone tried upgrading to wine-5.17 without installing MinGW, being able to confirm that it works? Since I don’t care about games but am dependent on wine for some things (e.g. ADE), I would rather do without the large MinGW package on my laptop with limited SSD space.
    I might try myself, of course, but if I upgrade and wine-5.17 doesn’t run without MinGW, how can I retrieve Eric’s wine-5.6 package? Would the 14.2 version (still available in Eric’s repo) do on -current?
    No doubt Eric has 5.6 for -current archived somewhere, but not, I guess, freely available for outsiders?


    1. For what I’ve grasped, mingw is only an optional build-time requirement and should not be needed at runtime by wine.


      1. I bit the bullet and upgraded to 5.18 but skipped MinGW and can confirm that the few applications I run under wine all work as they should. During wine configuration I got a dialog box: “rundll32.exe – .NET Framework initialization, Unable to find a version of the runtime to run this application.” But that happens at every update and as earlier I just clicked OK and the process continued so apparently nothing for me to worry about.
        So from my viewpoint MinGW, FAudio, and vkd3d are optional dependencies of importance for those who need them for gaming or some other task.


  11. In the meantime, I have added Slackware 14.2 packages for MinGW-w64 and for wine.
    I also updated all wine packages to 5.18, and on Slackware-current wine now has an additional dependency, vkd3d, to add Direct3D 12 support.
    I have updated the main article as well with this info.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.