Alien Pastures

My thoughts on Slackware, life and everything

Tag: wine (Page 1 of 3)

Wine 8.4 packages for Slackware

March 19, 2023 / / 7 Comments

The Wine developers released version 8.4 last week. There’s lots of bugfixes of course, but the announcement also mentions that the work has started on a Wayland graphics driver. Note that in the previous 8.3 release for which I did not create packages, Smart Card support was added, using PCSC-Lite for which I also have a package.

I have created and uploaded fresh Slackware packages (targeting 15.0 and -current) for pure 32bit Wine as well as a 64bit Wine which also contains the 32bit WoW64 (Wine on Wine64) binaries. Both packages have the ‘staging‘ patches applied and contain Gecko (the Wine implementation of Internet Explorer) and Mono (the open-source and cross-platform implementation of the .NET Framework).

The external dependencies for this package remain the same: FAudio and vkd3d are required.
On 64bit Slackware you need to have multilib installed (read the docs). In addition to a standard multilib package set, in addition you need to convert the 32bit versions of the FAudio and vkd3d packages to ‘compat32’ packages and install those.

Note: the MinGW-w64 compiler suite is used to generate the native Windows DLLs in my wine package. This compiler is not needed when you just want to run wine. If you want to compile your own wine, you can install MinGW-w64 from my repository.

Have a good weekend!
Eric

Steam client update, also fresh Wine, QEMU, MinGW-w64

December 28, 2021 / / 18 Comments

It was already a while ago that I refreshed my ‘steamclient‘ package for Slackware.

The steamclient package is meant to bootstrap the installation of Valve’s Steam gaming platform on your Slackware computer. The package installs a couple of scripts and a 32-bit Linux runtime based on Ubuntu. When you first start ‘steam’ from the menu or from the X terminal commandline, the client will download a larger set of runtime libraries, including 64-bit support. Onwards, the client will keep its runtime libraries up-to-date automatically, every time it starts up and connects to the Steam servers.
The Slackware package has a couple of tweaks because we obviously do not have Ubuntu tools on board. As a result, on Slackware-current (32bit and 64-bit with multilib) Steam works out of the box.

The reason for a package refresh is a recent bug report on Valve’s github, about an ALSA related crash on Slackware. The root cause was eventually found and it was part of the customization I added to the steam launcher 6 years ago when we were still on release 14.1 and we did not have pulseaudio as part of the Operating System.

So I removed (actually, commented-out) these lines, and that should fix the root cause for that bug. If you do not use Pulseaudio or want to enforce ALSA sound regardless, just un-comment the relevant lines at the top of the ‘/usr/bin/steam’ script again – it’s self-explanatory.
I have also refreshed the READMEs for Slackware and additionally removed support for all Slackware versions older than 14.2. To be realistic, I assume that gamers are all on the -current platform already.

NOTE:
If you have an older ‘steamclient’ package installed on 64bit Slackware and use the slackpkg+ extension to manage 3rd-party repositories, you need to un-install the old steamclient package first. The old packages have a ‘i386’ architecture tag whereas the new one has a ‘i386’ architecture tag for the 32bit Slackware, and a x86_64 tag for use on 64bit Slackware.
They are the same package actually but I was asked to make ‘steamclient’ installable via slackpkg/slackpkg+ also on 64bit Slackware. So:

# removepkg steamclient
# slackpkg update
# slackpkg install steamclient

Have fun playing games on Steam!

Some other recent package updates in my Slackware-current repository are:

Wine: we’re up to version 6.23 now. The 32bit wine package is just that – 32bit Wine. My 64bit wine package contains both 64bit Wine and the 32bit WoW64 (Wine on Wine64). Both have the ‘staging‘ patches applied.
The external dependencies for this package remain the same: FAudio and vkd3d are required. On 64bit Slackware you need to have multilib installed. In addition to multilib, you need to convert the 32bit versions of the FAudio and vkd3d packages to ‘compat32’ packages and install those.

MinGW-w64: I have updated this package to v9.0.0_gcc11.2.0. Mingw-w64 is based on the original mingw.org project (which was created to support the GCC compiler on Windows systems), particularly adding 64-bit support.

The MinGW compiler suite is used to generate the native Windows DLLs in the wine package.

The QEMU machine emulator and virtualizer got a refresh because I am preparing (fingers crossed!) for a release of Slackware 15.0 which according to an online statement could happen soon after New Year 2022.
I run Slackware Virtual Machines (VMs) in QEMU and I wanted to take advantage of the newest QEMU features. At the moment my VM host is Slackware 14.2 and that has a fairly old QEMU package installed. The VM host will get an upgrade to Slackware 15.0 as soon as the new release is made available.
Dependencies for my qemu package are: vde (historically for non-root network bridge support) and as of now also: device-tree-compiler, jack2 (note that jack2 has its own sub-dependencies!) and virglrenderer.

Have fun with these during the holiday break, and I wish you all a Happy New Year.

MS Windows on Linux: wine and MinGW-w64

September 28, 2020 / / 48 Comments

 

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.

Pipelight update

July 29, 2016 / / 11 Comments

pipelight-logoI decided to do an update of my “pipelight” package. I had not looked at it for a long time, basically because I do not use it anymore, but after I upgraded my “wine” package someone asked if I could please write up what could be done for wine-pipelight.

As you know, pipelight is a Linux plugin wrapper for Mozilla-compatible browsers which lets you install and use Windows plugins on Linux. This configuration enables you to access online services which would otherwise be unavailable to you on a Linux platform. The pipelight plugin wrapper uses wine to load the Windows software.
The pipelight developers created a series of patches for Wine which made all of this possible. They called this patch set “wine-compholio” which was later renamed to “wine-staging” and eventually was absorbed into the Wine developer community. Nowadays, wine-staging is the testing ground for Wine – stuff which has not yet been approved for inclusion into the main repository but looks promising.
Together with my “pipelight” package I offered a “wine-pipelight” package which contained a version of wine that had been patched with the “wine-staging” patch set and installed into a non-standard location so that only the pipelight plugin would find it.

Since then, my regular “wine” package has also been enhanced with the wine-staging patch set. In addition, I am applying the d3d9 (wine-nine) patch set which uses the gallium-nine state tracker in Mesa for added performance on some graphics cards.

Therefore a separate “wine-pipelight” package is no longer required. My regular wine package is sufficient.

I have reconfigured and rebuilt my pipelight packages (for Slackware 14.1 and newer) so that you can remove the old “wine-pipelight” package. Pipelight uses my regular wine package now. The “wine-pipelight” packages (for Slackware 14.1 and newer) have been removed from my repository.

That simplifies things a lot. I used to have a warning that you should not try to run programs simultaneously that use the wine and wine-pipelight programs – the two would interfere. That warning has become obsolete now that there is only one version of wine left on your system.

If you want to use someone else’s wine package instead of mine, you need to ensure that that wine package applies the wine-staging patches or else your pipelight will not work!

Good to know: you can always get the latest Windows plugin releases (an important feature in case of security fixes) without having to wait for me creating a new package. Just run the command “pipelight-plugin –update” as root. After doing that, the next time your browser loads the pipelight plugin, it will automatically download the newest version of your installed Windows plugin(s).
This feature depends on the pipelight developers updating their “install-dependency” script, so if they forget or are too busy, the above command will not give you the latest Windows plugin releases unfortunately…

 

In my original post about pipelight, you will find full installation and configuration instructions, as well as a troubleshooting section. That blog article is also referred to on the pipelight.net support page. Let me remind you that you need to go multilib if you want to use pipelight on 64-bit Slackware.

Packages can be downloaded from these locations:

Have fun! Eric

 

Wine 1.7.52 with additional patch set

October 12, 2015 / / 26 Comments

I uploaded a new set of Wine packages. I know that Wine HQ itself is offering Wine packages for Slackware (see this sourceforge.net link) but being the control freak that I am, I want to know exactly what I am using. I am using my own build script.

My Wine package needs some explanation. As you know, Wine traditionally was meant to run Windows software – 32bit Windows software. Therefore it will run fine on 32bit Slackware but if your computer is equipped with 64bit Slackware, you need to enhance it with multilib capabilities to make this 32bit software work on a 64bit OS.

Microsoft caved in at some point and started offering 64bit versions of their Windows OS. The 64bit MS Windows can run 32bit software out of the box… a wise move since a lot of Windows software is still 32bit binary code. They made this work transparently by adding something akin to our multilib. Microsoft calls it WoW64 or “Windows on Windows 64”.

The Wine package I provide for the 64bit Slackware therefore mimicks this WoW64 configuration and offers both a 32bit “wine” and a 64bit “wine64” environment. You still need multilib to make this work on Slackware64 but you will be able to run 64bit Windows binaries just as easily as 32bit Windows programs.

Now, recent versions of my package have been enhanced again. You may recall that I offer a “pipelight” package which allows you to use MS Windows browser plugins with your Slackware Firefox. Pipelight uses a patched version of Wine. This patch set was orginally called “Wine Compholio” but as more and more people saw how useful these patches were for regular Wine users, an effort was made to formalize these patches and make them more widely known – and used. Nowadays, this patch set is known as “wine-staging” and on 25 September the team announced their integration into WineHQ, making wine-staging a structural part of the Wine development process. I have decided to apply the wine-staging patch set to my Wine package by default since the 1.7.51 release. Fedora does this too for their package.

And with my 1.7.52 package I have added a second patch set which should bring near-native performance to Direct 3D 9 applications in Wine. This patch set is called “direct3d9” and leverages the new “d3dadapter” of the mesa package (provided by the Gallium Nine state tracker of Mesa). The d3dadapter library has been enabled in the mesa package of Slackware-current. My wine.SlackBuild script checks for this library and applies the direct3d9 patch set if that library is found. The wine-1.7.52 packages for Slackware 14.1 and -current are therefore different.

I noticed that there is some overlap between the wine-staging the direct3d9 patch sets. After applying wine-staging there are some chunks of the direct3d9 patches that fail to apply. I do not know if this will have any adverse effects when running Windows applications. I checked with other distros and found that Arch Linux is also applying both patch sets in their “wine-staging-d3dadapter” and don’t seem to be bothered by failing patch-chunks. If you are on Slackware-current and want to (re-)compile Wine without the direct3d9 patch set, you can simply run the SlackBuild script like so:

# USE_NINE=NO ./wine.SlackBuild

I would like to hear from you if these patch sets are making a difference in running your Windows games and other programs.

Cheers, Eric

 

« Older posts

© 2024 Alien Pastures

Theme by Anders Noren — Up ↑