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.
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.
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
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.
Now that you make me think at it that sounds logical, thanks for your enlightenment.
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.)
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.
Oh gotcha. Yeah, I’m on multilib.
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?
Yes they are all available at the usual place: http://connie.slackware.com/~alien/slackbuilds/
I will try my luck building MinGW-w64 on slackware-14.2 soon, would be a nice-to-have there.
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.
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.
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.)
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”).
Yeah, sounds like Dsmith forgot to logout after installing.
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.
Hello,
it’s most likely a silly question, but… MinGW-w64 package is required only for building Wine, not for simply using it…?
Not a silly question. I did not test, but I do not think you would need to have MinGW-w64 installed in order to use wine.
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!
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.
Thanks Eric for the answer!
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 !
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.
Also, I do not know https://github.com/HansKristian-Work/vkd3d-proton so I stick with Wine’s vkd3d sources. The vkd3d repository on https://source.winehq.org/git/vkd3d.git/ is pretty active.
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.
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 ^_^
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?
For what I’ve grasped, mingw is only an optional build-time requirement and should not be needed at runtime by wine.
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.
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.
Eric thanks for the Slackware 14.2 packages. I’m a little confused by the MinGW-w64 naming. Does it require GCC 9 on the system to function or is that the version of GCC that the MinGW-w64 will build with? Thanks, BrianA_MN
The MinGW-w64 package contains compilers that do not require the native Slackwaregcc compilers to run.
The “v7.0.0_gcc9.3.0” version means that mingw-64 version 7.0.0 was used to compile the gcc 9.3.0 sourcecode in such a way that the resulting compilers can generate native MS Windows binaries from sourcecode.
You could use gcc-10.0.0 sourcecode and then you would have a “v7.0.0_gcc10.0.0” compiler suite as a result, But for common cases, a gcc9 compiler is sufficient.
Look also at the binary names of these compilers: ‘x86_64-w64-mingw32-gcc’ and ‘i686-w64-mingw32-gcc’ are gcc variants that can compile 64bit and 32bit Windows-native executables, respectively.
Compare that to the formal name of Slackware’s own native gcc compiler program, which is ‘x86_64-slackware-linux-gcc’ on 64bit and ‘i586-slackware-linux-gcc’ on 32bit Slackware.
See the similarities?
I think I understand the naming now. Thanks for the explanation. I have a question about using your MinGW and building packages for win executable but will take it off-line, since it seems this is more about how you solved the problem for WINE. Cheers, BrianA_MN
So I’m trying to build WINE, and it’s not finding mingw. (I have used your package fine before.) with the change to glibc and gcc in current, will it need to be rebuilt? Or did I forget a step? I thought you just logged in as root (su -l), ran the slackbuild, and the wine build process uses mingw, if available?
You must also source the /etc/profile.d/mingw-w64.sh file, otherwise the configure script won’t be able to find mingw.
Doh, thanks!
OK…specifically sourced the /etc/profile.d/mingw-w64.sh file, still not found.
What I did:
su -l root
. /etc/profile.d/mingw-w64.sh
./wine.Slackbuild (It’s dugan’s slackbuild, not alien bob’s)
Checked the logs:
checking for x86_64-w64-mingw32-gcc… x86_64-w64-mingw32-gcc
checking whether x86_64-w64-mingw32-gcc works… no
So something that was updated on current (gcc and/or glibc) broke it?
You don’t need to source/use mingw-w64 gcc directly because wine will try to find mingw-w64 support in the system. If mingw-w64 compiler is available then wine will look for vkd3d library (which compiled using mingw-w64). If those compiler and library are available then wine will compile vulkan support dll using mingw-w64 gcc. So not all binaries will be built using mingw. If those compiler and libraries are not available then wine will just skip building vulkan support and just using gcc.
You can use my mingw-w64 and dxvk, vkd3d, wine SlackBuild here:
– https://gitlab.com/w41l/mingw-w64
– https://gitlab.com/w41l/wlsbuild/{dxvk,vkd3d,wine,wine-gecko,wine-mono}
Sourcing that file is required for the configure script to find the mingw compiler, as it sits outside of PATH (if using Alien’s package).
Of course, if mingw is not found, a number of fakedlls won’t be cross-compiled as proper Windows PE dlls (i.e. ntdll, gdi32, etc. and more to come). I’m not sure Vulkan support (winevulkan?) has been ported to PE yet, and I doubt that affects anything as of now.
If you’re talking about DXVK or vkd3d-proton, then that’s another matter altogether.
You’d have to look at the relevant config.log script to see what’s the problem.
Mingw was found this time but the configure script wasn’t able to compile a simple test program to check if it works. Depending on the underlying error, you may require some other package or settings.
If mingw-w64 gcc does not available, then wine will using it’s own c compiler (wine-gcc) to build the PE files (bootstrapping). It’s the same when you are compiling dxvk using wine only (without mingw-w64 gcc).
But if mingw-w64 gcc is outside the PATH then yes the mingw-w64 PATH should be imported before using it.
Mine is different 😀
That’s what I figured, especially with all the changes current has seen in the past few months. I know glibc was changed in October, and the last version of WINE I built was wine-staging 5.20, so it’s at least been that long. I’m rebuilding mingw against the new system glibc and seeing if that fixes it, but building mingw takes forever. (I’m keeping the version of gcc that mingw builds the same, just for the sake of testing. I didn’t think that needed to be kept the same as the system gcc?
Yeah, mingw needs a rebuild. We’ll see if the rebuilt WINE fixes my battle.net problem. Funny that no other WINE program should break, though. you’d expect something else to go wrong.
It will take a while before I find time to fix the big packages. Unfortunately Pat does not sync his schedule with mine so the “Big Merge” could not come at a worse time. Y’all will have to fix stuff yourself for now. I am happy to see the reports of what’s broken however, so I can make a focused effort on fixing what needs fixing – in the worst case, no free time before 16 December.
Already fixed. 🙂 You have a bugtracker?
I do not have a bug tracker and probably I never will.
Running a bug tracker would imply that I am committed to do all this stuff in a formal kind of way. This is just my hobby and you get my best effort at fixing things but that’s all.
So I read everything here on the blog and fix whatever gets reported as broken. I ignore bug reports and complaints about my stuff on linuxquestions.org though. People using my stuff should come over here, read the available docs (how many more times I need to explain that I created poppler-compat, icu4c-compat, boost-compat to avoid breakage of my packages on -current for instance…) and make their requests if the information in my blog articles is not providing answers. I’ll answer or discuss any post here. Trolls and obvious ass-hats excluded 😉
I’ll admit to being an asshat. 🙂
I’ll respect your personal opinions 😉 Still, I was not referring to the commenters here on the blog that I regularly interact with…
Regarding the carla slackbuild (http://www.slackware.com/~alien/slackbuilds/carla/build/carla.SlackBuild), I had to add these lines at the top of the script:
if [ -z “$ARCH” ]; then
case “$( uname -m )” in
i?86) ARCH=i586 ;;
arm*) ARCH=arm ;;
*) ARCH=$( uname -m ) ;;
esac
fi
before:
# Determine whether we have the tools to compile the Windows VST support:
if [ “$ARCH” == “x86_64″ ]; then
WIN_COMPILERS=”x86_64-w64-mingw32-gcc i686-w64-mingw32-gcc winegcc”
WIN32_ARCH=”i686″
else
WIN_COMPILERS=”i586-w64-mingw32-gcc winegcc”
WIN32_ARCH=”i586″
fi
if which ${WIN_COMPILERS} 2>/dev/null ; then
BUILD_WINVST=”YES”
else
BUILD_WINVST=”NO”
cat <<EOT
**
** If you want to compile support for Carla to act as a Windows VST host,
** please install MinGW-w64 and wine packages first.
**
EOT
sleep 5
fi
otherwise it was not compiling the support for windows VST.
After that fix, it compiled well as expected.
Thanks Alien Bob
Yeah good catch. I have fixed that SlackBuild now.