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
This is my article about wine+staging+nine in slackware64-current multilib. It’s in Indonesian, but I think some screenshot of running Windows Unigine Valley Benchmark gives some picture:
http://www.walecha.web.id/blog/2015/10/aktivasi-prime-dri3-di-slackware64-current
BTW, I could not enable DRI3 in PRIME using slackware stock Xorg and drivers. I had to rebuilt them to use DRI3 in PRIME (Intel+AMD).
I don’t have failing chunks for wine-nine, but I’m using a different patchset.
There is an automatically generated patch for wine-nine (just one file) here:
https://github.com/NP-Hardass/wine-d3d9-patches
It applies clean on wine-staging 1.7.52 and works fine.
I took your SlackBuild as a base and used that patch, see here:
http://schmatzler.de/my_slackbuilds/wine-staging-nine/wine/wine-staging-nine.SlackBuild
schmatzler, I use the same git repository as where you obtained that patch, and my wine.SlackBuild runs the “generate-d3d9-patch.sh” to create the patch for the particular Wine version I am building a package for.
So, I would have thought that that basically creates the same re-created patch as you can download from the git repository.
Maybe that’s the problem.
I just altered the SlackBuild so it downloads a specific pre-generated patch, just around the date where wine-1.7.52 came out.
No problems there.
Thanks for the updated WINE. Question, if I run slackpkg+ and ask “slackpkg info wine”, it shows requirements for OpenAL. Which OpenAL version is required? You have both OpenAL 1.15.1 and OpenAL 1.16.0 available in repository, but slackpkg+ didn’t ask me to upgrade OpenAL, currently installed is 1.51.1. Which is recommended? Additionally, I don’t have libva installed, and it looks like you have separate versions for intel, vdpau, and straightup. Which version should be used if running NVIDIA proprietary driver 340.73?
Hi Eric,
thanks for your patched wine package. I was playing Diablo III: Reaper of Souls using dugan’s wine SlackBuild he posted on LQ (it patches the source using the wine staging patchset). Now I’m playing some more using your package. Runs just fine (I’m using nvidia’s binary blob on -current). I noticed no issues playing Diablo, so kudos to the wine devs, too!
I guess this theoretically obsoletes your wine-pipelight package?
lems
Hi lems.
Pipelight can not use the default wine. It is configured to look for wine-pipelight in a non-standard directory.
Also, wine-pipelight uses a non-standard WINEPREFIX so that it does not mess up your regular wine configuration.
Hi Brian
Wine is compiled against the OpenAL package which is in the repository for the same Slackware release (OpenAL 1.15 for Slackware 13.37 and 14.0, and 1.16 for Slackware 14.1 and -current). that provide the backends. Only libva is required. You should additionally install libvdpau if you are using the NVIDIA binary driver.
The libva package is required because wine links against its shared libraries and won’t start if you did not install a libva package. It is up to you to install a VAAPI backend that works with your graphics card (nvidia, ati or intel). Note that there is only one libva package plus some libva-
Thanks Eric. My config is Slackware64 14.1 with Multilib. I’ve already removed OpenAL 1.15.1 and installed 1.16 (I’m wondering why slackpkg didn’t present the upgrade since I don’t have it black or greylisted, but that is a slackpkg+ config issue not WINE). With multilib should compat32 versions of OpenAL, libva and libvdpau be created and installed also?
Indeed compat32 versions of OpenAL, libva and libvdpau should be created and installed also if you are running 64bit multilib Slackware.
Thought so, thanks for the verification. I’ll create them and install them next. Thanks for the great support and work you continue to provide us Morlocks of Slackware.
Umm, any chance you might send link to the libvdpau-1.1.1. pkg. I don’t find it on slackware.com or taper.alienbase.nl which are both still showing 0.7 versions which won’t help in creating a compat32 pkg. Thanks,
Wait, sorry found in it on taper.alienbase.nl under the restricted repository. Sorry. Thanks again. Remember I said Morlocks,,,:)
Nope wrote too quickly, I found the source files under the ffmeg directory, but not the 32 bit pkgs. Since I have a 64 bit, I’m going to have to go back and read the multilib slackbook wiki and learn how to build a 32 bit pkg then convert it to compat32. Always more to learn….
Hi Eric, I see that you’ve updated your WINE slackbuild for 64 bit to 1.9.23-1 on 29-Nov-2016. If I go to winehq and look at the development branch it is at 2.7 as of 7-May-2017. Can I use the 2.7 x86_64 tarball with your slackbuild and still have all the functionality that you normally add? I was going to use your SlackBuild rather than SBo’s because their wine-staging is 2.6 and only i486 🙁 , plus I’ll bet you’ve made some other modifications to make it run better on Slackware64 -14.2 multilib?
BrianA_MN – if I could give that answer, I would already have the packages available, don’t you think?
You could just try by changing the version numbers in the SlackBuild and run a compilation. With a bit of luck, there will be a package at the end.
I’ll see that I find some time for a new wine package in my repository, but don’t hold your breath.
Eric, I’ll try the build and see what is produced. It was a simple question, of whether your SlackBuild works with the winehq development tarbar, nothing more. Cheers.
Brian, the SlackBuild works with 1.9.23 which was a development build at the time. As long as there’s a wine-staging tarball available with the same release number as the wine tarball, you should be able to generate a package successfully, unless the build process has changed significantly since 1.9.x.
Looking at https://github.com/wine-compholio/wine-staging/releases there is indeed a 2.7 release of wine-staging, so you definitely should try substituting 1.9.23 with 2.7 and then starting the script.
Hi Eric, I was able to build a wine 2.7 and also added the latest mono-4.7.0. Thanks for the encouragement. Cheers
Hi, I am currently trying to run wine with multilib. I installed your packages (thanks) but when I try to run wine I get
Wine cannot find the FreeType font library. To enable Wine to
use TrueType fonts please install a version of FreeType greater than
or equal to 2.0.5.
http://www.freetype.org
although I have the freetype package installed (at some point I added the freetype-compat32 package but still no luck).
I just get a box with an error message without any text. I assume this is related to the previous error.
Do you have any idea on what may be causing this ?
Thanks,
Ciprian
cip you do not mention what version of Slackware you are running, and which exact URL you used for the wine package you have downloaded.
I need more information from you before I can answer your question.
sorry about that. I use Slackware 14.2
I first installed http://www.slackware.com/~alien/slackbuilds/wine/pkg64/14.2/ and I noticed wine64 notepad works with fonts and everything. No error messages.
Afterwards I installed http://www.slackware.com/~alien/multilib/14.2/glibc-2.23_multilib-x86_64-1alien.txz and the compat32 packages built by you (didn’t install all of them, just the one specified in wine official deps https://sourceforge.net/projects/wine/files/Slackware%20Packages/2.10/x86_64/wine-2.10-x86_64-1sg.dep/download)
Then I tried to run a win32 application but I had the errror from above.
Curiously when I started wine64 notepad now, I have a similar error: no fonts and the error message. It looks like the glibc package breaks wine, if this gives you a clue.
Thank you for your time
cip, I don’t care about the “official deps”. If you use multilib, you are best off by installign all the glibc multilib packages (not just the “glibc” package) as well as all the “compat32” packages in the slackware64-compat32 subdirectory. And on top of that the dependencies for *my* wine package (OpenAL, OpenAL-compat32). I do not support people who install only partof the packages *and* can then not resolve the dependency issues themselves.
After installing all packages, you can do proper testing. Also, try to test with an empty new WINEPREFIX.
sorry I installed all the glibc packages but you are right, I will install all the compat32 packages tonight. I will try to use a new WINEPREFIX as well. Thanks
yes, you were right. I installed all the packages with **/*.txz and it works flawlessly. Thanks again