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.

Remember Joe Mann

A story of remembrance and gratefulness towards Joe Mann.

Today 76 years ago, on September 19th 1944, a young US soldier called Joe Mann gave his life to save that of his comrades. He jumped on a grenade thrown by a German soldier and died a hero. This was the day after Eindhoven was liberated from the Nazis.

No one knew at the time, but the war in the Netherlands would not end until 8 months later, causing countless civilian deaths during the “hunger winter” of 44/45.

A monument was erected for Joe Mann a few years back, and my wife and I walk the surrounding area a lot, so yesterday we stopped at the monument to contemplate the bravery and fate of this young man. This is a picture of the place:

The inscription reads: “On 19 September 1944, Joe E. Mann as soldier at this place gave his young life to save the lives of his comrades.

LibreOffice 6.4.5 finally for Slackware 14.2

The Document Foundation recently released version 7.0.0 of their Libre Office suite of applications. The packages for Slackware-current can be found in my repository. But the situation for Slackware 14.2 used to be different – I got stuck after LibreOffice 6.2 because the newer source releases (6.3 and onwards) require versions of system software that our stable Slackware 14.2 platform does not offer.

From time to time during the last year, when there was time and the build box was not compiling packages, I messed around with the libreoffice.SlackBuild script in futile attempts to compile recent versions of LibreOffice on Slackware 14.2. I failed all the time.
Until last week. After I had uploaded the new KDE Plasma5 packages to ‘ktown‘, I had an epiphany and decided to use a new approach. What I did was: question all the historic stuff in the SlackBuild script that got added whenever I needed to work around compilation failures; and accept that the compilation needs newer versions of software than Slackware 14.2 offers. The first statement meant that I disabled patches and variable declarations that messed with compiler and linker; and for the second statement I stuck to a single guideline: the end product, if I were able to compile a package successfully, has to run out of the box on Slackware 14.2 without the need to update any of the core Slackware packages.

So I ended with a script that only has two new compile-time requirements: use the ‘unsupported‘ gcc 9.2.0 compilers instead of Slackware’s ageing gcc-5.5.0. And update gperf to the version you find in Slackware-current. The rest of the required supporting libraries will be compiled into LibreOffice automatically. And this time, the LibreOffice sources compiled without errors.
The resulting binaries would however fail to run on a regular Slackware 14.2 (with the stock versions of gcc and gperf packages) because of missing symbols in the dynamically linked system libraries.
I managed to get around that issue, by adding the two runtime support libraries that come with gcc-9.2.0 (libgcc_s.so.1 and libstdc++.so.6) into the ‘program’ directory of LibreOffice. Those libraries contain the symbols LibreOffice is looking for; a simple runtime dependency on gcc.
By the way: you cannot expect everybody to install a set of compilers just to run programs, Slackware solves this dilemma by adding the GCC runtime libraries to the ‘aaa_elflibs‘ package which is usually one of the first packages to get installed on a new system.

That worked! LibreOffice 6.4.5 for Slackware 14.2 is now available in my package repository. And I even built LibreOffice 7.0.0 in the same manner. I stuck with 6.4.5 because I want people to be able to use a stable and well-established version of an office suite on the stable Slackware platform. The more experimental 7.0.0 release is for Slackware-current.

Guess what! Today, just when I uploaded the 6.4.5 packages I noticed that the release of LibreOffice 6.4.6 has been announced (and in October we’ll see the final release in the 6.4 cycle – being 6.4.7).

I will try to find some time to compile those fresh tarballs; but first I do like feedback about the new 6.4.5 packages that are now downloadable for Slackware 14.2.

Get the packages – as usual – from my own server or one of its mirrors; https://slackware.nl/people/alien/slackbuilds/libreoffice/ (rsync://slackware.nl/mirrors/people/alien/slackbuilds/libreoffice/) or https://slackware.uk/people/alien/slackbuilds/libreoffice/ (rsync://slackware.uk/people/alien/slackbuilds/libreoffice/)

Enjoy! Eric

Libre Office 7 packages for Slackware-current

New! LibreOffice 7.0.0 was released last week and I built packages for Slackware-current.

The release announcement gives a concise overview of the new features and enhancements all over the board – among which a much improved support for Microsoft Office document file formats. I will not repeat all of that here on the blog, so please check out the content behind above link.
Amazing that even with several big companies driving the development of this Open Source office suite, still 26% of LibreOffice’s code contributions come from non-corporate individuals.

LibreOffice and KDE Plasma5

The libreoffice.SlackBuild script is now defaulting to building KDE5 (aka Plasma5) support. It will generate errors if you try to compile on a system that does not have KDE Frameworks5 and libdbus-qt5 installed. See the README.kde5 in the source: you can get all of them from my ‘ktown‘ repository.
Or, if you do not want to install KDE5 components, you set the value of the “ADD_KDE5” variable in the script to “NO”.
Note that you can safely install the KDE support package on a system that does not have any trace of KDE; it will simply do nothing.

Java support dropped from the libreoffice Slackware package

One caveat with the new packages is that to build Java support into them, one will need Oracle JDK 9 or higher. I do not have OpenJDK 9 or higher in my repositories and I will not, until IcedTea adds support for these versions. Until then, I stick with Java 8 and that means I had to disable Java support in the libreoffice packages that I compile from source. There’s a new variable in the libreoffice.SlackBuild script, “USE_JAVA“, and it defaults to “NO”. If you want to recompile the packages adding Java support, get a recent enough JDK from Oracle and be sure to also install Apache Ant.

From ​​the LibreOffice Wiki page:

What is Java used for in LibreOffice?
LibreOffice is written primarily in C / C++, a language that generates programs called “native” designed for specific platforms. There are versions for Windows, Linux or Solaris, but not for all three at the same time. However, some modules can be written in other languages, including Java.
Specifically, currently (as of version 6.3) at least these components/functionality require Java:

  • HSQLDB (optionally used for embedded database in Base; default is Firebird that doesn’t depend on Java)
  • JDBC
  • Some wizards (particularly, Table/Query/Form/Report Wizards in Base)
  • ReportBuilder (used to generate actual reports from report templates in Base)
  • Non-Linear solvers built-in extension (DEPS and SCO) in Calc (there is an experimental Swarm solver that doesn’t depend on Java)
  • MediaWiki extension (Wiki Publisher)
  • Support for scripts and extensions written in Java/Beans

I hope none of you are in dire need of this functionality, in that case I would suggest installing the official binaries from the Document Foundation and a Oracle JDK (or JRE) version 9 or higher.

Also, this is a .0.0 release – do you feel that you can use this release as your daily driver? Should I make the previous 6.4.5 available somehow (not that I would like that)? Note that these packages are available only for Slackware-current anyway, and that is a testing ground already.

Eric

KDE Plasma 5 August 2020 release for Slackware

New Plasma5 packages for Slackware-current are ready for download & installation. I skipped July (holiday season) and so here is KDE-5_20.08 aka my August 2020 release. Be sure to read the upgrade instructions very carefully to prevent  breakage, because starting with my June batch the goal is to remove Slackware’s ConsoleKit2 and replace it with elogind!.

It would not harm if you (re-)read my previous blog article about Plasma5, “Replacing ConsoleKit2 with elogind – first steps“. It has a lot more detail about the reasons for this move as well as guidance on using the Wayland Window Manager (as a test) instead of regular X.Org. Note that Wayland sessions still need a lot of maturing and X.Org will remain Slackware’s default choice.

A repeat from that article: with elogind as the session/seat manager instead of ConsoleKit2, you’ll see some new behaviour. A quite obvious change: if you run ‘startx’ or ‘startkwayland’ at the console, you won’t see a VT (virtual terminal) switch. In the past, your console TTY would usually be tty1 but your graphical session would start on tty7 and you would automatically be switched from tty1 to tty7. This is no longer true – the graphical session will re-use your console TTY.
SDDM is still starting on tty7 but only because I make it do so via its configuration file.

What news is there to tell about KDE-5_20.08?

This August ktown release contains the KDE Frameworks 5.72.0, Plasma 5.19.4 and Applications 20.04.3. All this on top of the Qt 5.15.0 in Slackware-current.

Deps:
The ‘deps’ section got a bit smaller again this month:

  • pcaudiolib, espeak-ng, hack-fonts-ttf, noto-fonts-ttf, and noto-cjk-fonts-ttf were moved into the actual Slackware distro. Things are progressing nicely in that regard.
  • flite has been removed since Pat decided we will go with just espeak-ng.
  • a new package ‘pipewire’ was added as a dependency for krfb and xdg-desktop-portal-kde.
  • The elogind-aware dbus package was upgraded to match the Slackware version.
  • Finally, qca-qt5 was upgraded and I recompiled mlt (to fix the broken kdenlive) and speech-dispatcher.

Frameworks:
Frameworks 5.72.0 is an incremental stability release, see: https://kde.org/announcements/kde-frameworks-5.72.0. A new ‘kdav’ source tarball got added but that is actually the same package you’ll find in KDEPIM. Next batch, the actual kdav package will be built from Frameworks sources.

Plasma:
Plasma 5.19.4 is a further increment of the 5.19 cycle (5.19.5 will be the last, in September). See https://kde.org/announcements/plasma-5.19.4 and if you want to read more about the goals for 5.19 you should check out https://kde.org/announcements/plasma-5.19.0 .

Plasma-extra;
In plasma-extra In plasma-extra I rebuilt sddm-qt5 to install man pages correctly, and upgraded plasma-wayland-protocols and wacomtablet.

Applications;
Applications 20.04.3 is an incremental bug fix release, see also https://kde.org/announcements/releases/2020-07-apps-update/

Applications-extra:
For applications-extra, I updated digikam, krita, libktorrent and ktorrent, and skanlite.
Note that the size of the digikam source tarball ‘blew up’ due to the addition of new neural network facial recognition data files, but the actual package ‘only’ grew from 97 to 108 MB.

Telepathy:
KDE Telepathy is no longer part of my ‘ktown’ distribution of KDE Plasma5.

KDE Sources:
Not so visible but important nevertheless is this month’s contribution of Patrick Volkerding who validated all the KDE slack-desc files and enhanced/polished a lot of them. He also cleaned out the ‘patches’ directory and removed all the obsolete patches that are not being applied anymore. As you also will have noticed, Pat is slowly picking packages out of my ‘deps’ and adding them to Slackware. Even espeak-ng which I had not expected to happen.

Where to get KDE Plasma5 for Slackware

It should be obvious, but these packages will not work on Slackware 14.2. The old (KDE 5_17.11) Plasma5 packages that were still in my ‘ktown’ repository for Slackware 14.2 were removed in May 2020 because they were un-maintained and had security issues.

Download the KDE-5_20.08 for Slackware-current from the usual location at https://slackware.nl/alien-kde/current/ or one of its mirrors like http://slackware.uk/people/alien-kde/current/ .

Check out the README file in the root of the repository for detailed installation or upgrade instructions.

BIG FAT WARNING: Read these README instructions carefully if you do not yet have elogind installed (i.e. if you did not install the ktown June 2020 release previously)!
In short:

  1. UPGRADE TO THE LATEST slackware-current first.
  2. Then, REMOVE the ConsoleKit2 package if you had not installed my June ktown batch before.
  3. Next, install or upgrade the KDE5 package set.
  4. Change to directory /usr/share/sddm/scripts/ and move the Xession.new & Xsetup.new files into place (remove the .new extension) after carefully checking that you are not overwriting your own customizations in the Xsession & Xsetup scripts. Note: because “slackpkg new-config” only looks inside the /etc/ directory it will miss the two scripts in /usr/share/sddm/scripts/.
    You’ll still have to manually check /etc/ for some critical *.new files that need to be put into place if you are not using slackpkg (which does this *.new check at the end of its run).
  5. Finally, REBOOT.

Development of Plasma5 is tracked in git: https://git.slackware.nl/ktown/ and this month’s development took place in the ‘elogind‘ branch. I will fold these elogind developments back into the master branch soon.

A new Plasma5 Live ISO will be available soon at https://slackware.nl/slackware-live/latest/ (rsync://slackware.nl/mirrors/slackware-live/latest/) with user/pass being “live/live” as always.

Have fun! Eric