[SOLVED] I have a game that requires libwayland-egl
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
The easiest way to do what fskmh recommends is to download Slackware's mesa source tree, including the SlackBuild and additional files, then just rerun the SlackBuild and upgradepkg the resulting package. See below for instructions.
Code:
wget -r -nH --no-parent --reject="index.html*" --cut-dirs=5 http://slackbuilds.org/mirror/slackware/slackware64-14.1/source/x/mesa/
cd mesa
su -
sh mesa.SlackBuild
upgradepkg /tmp/mesa-9.1.7-x86_64-1.txz
Last edited by bassmadrigal; 01-07-2016 at 12:11 PM.
Reason: Switched links to 14.1 instead of -current
Now I wonder if I should perhaps add a recompiled mesa to the "deps" section of my Plasma 5 repository (which contains a wayland package).
I noticed that some of the KWin stuff would not compile due to absense of wayland-egl which makes running a Plasma 5 Wayland session an impossible task at the moment.
The easiest way to do what fskmh recommends is to download Slackware's mesa source tree, including the SlackBuild and additional files, then just rerun the SlackBuild and upgradepkg the resulting package. See below for instructions.
Code:
wget -r -nH --no-parent --reject="index.html*" --cut-dirs=5 http://slackbuilds.org/mirror/slackware/slackware64-14.1/source/x/mesa/
cd mesa
su -
sh mesa.SlackBuild
upgradepkg /tmp/mesa-9.1.7-x86_64-1.txz
Here's my config section, some additional comments are needed for background info.
Note that I've also installed libomxil-bellagio (hence the --enable-omx) and libtxc_dxtn (hence the --enable-texture-float). Installing libomxil-bellagio is optional but installing libtxc_dxtn is recommended. You can also remove "--enable-gallium-llvm" if you don't have llvm compiled with "--enable-targets". I use this to enable the llvm back-end for my r600 graphics. I see -current has switched to using cmake and my SlackBuild still uses autoconf. I don't know what the equivalent cmake invocation is, perhaps it's a default now. It might be best to use the SlackBuilds from -current if you want to update your graphics stack (libdrm, llvm, mesa) on 14.1, just know that it involves recompiling a fair number of packages, as well as the kernel for newer DRM features). N.B. on Slack64 with multilib the above means also compiling the 32 bit packages and converting the subsequent packages with Alien Bob's convertpkg-compat32 (compat32-tools) (BTW thanks Eric ;-)). I have toyed with writing these SlackBuilds with automatic dual 32/64 bit compilation but this becomes problematic for package management, especially for multiple machines.
OpenMAX support only really affect AMD GPUs, mainly embedded GPUs, so it's really optional. Plus libomxil-bellagio requires a patch to build at the latest release. Unless you're needing multimedia content support on AMD embedded GPUs, OpenMAX support is unnecessary.
DXTC/S3TC support isn't compiled in at any time, its dynamically loaded so you don't need it at build time. It's nice to have but only for games.
OpenCL however will require libclc from the llvm project and it's only available via git. The OpenCL ICD flag is fairly useless and will tend to break the compile. Not only this, but OpenCL support is limited to AMD only in hardware support, while Intel and Nouveau fallback to software support. At best it's moderately useful, yet equally useless.
The only real addition you might want to make is actually adding Gallium driver "ilo" for Intel chipsets to utilize Nine support for Wine. This, honestly, is the only useful addition anyone could make to the Mesa build other than adding Wayland support. That's it.
It might be best to use the SlackBuilds from -current if you want to update your graphics stack (libdrm, llvm, mesa) on 14.1, just know that it involves recompiling a fair number of packages, as well as the kernel for newer DRM features).
Just to give people an actual idea of what all it entails, back in DEC of 2014, this involved recompiling 284 packages (although, 276 were recompiling X itself) and then recompiling everything again in a 32bit VM so I could generate the compat32 packages for multilib). It is very possible that in the year since, many more updated dependencies would be required to do the same thing with the newest versions of mesa. I think I just grabbed the -current version (at the time) for all but mesa, libdrm (since the latest mesa required a newer libdrm than was in -current), and the kernel (3.18 was brand new and Pat didn't have a config available for it, however, I later switched to his config when he made one available). Here's what I needed to update back then:
autoconf 2.69 (recompiled)
automake 1.11.5 -> 1.14.1
kernel 3.10.17 -> 3.18.0 (have since upgraded to 3.18.24)
libdrm 2.4.46 -> 2.4.58
libelf 0.8.13 (recompiled)
libevdev 1.2 (added)
llvm 3.3 -> 3.4.2
mesa 9.1.7 -> 10.4 (have since upgraded to 10.4.7)
qt 4.8.5 -> 4.8.6
xorg 1.14.3 -> 1.15.2 (this was just the server version; I didn't want to list each xorg package individually, since it was 276 packages)
OpenMAX support only really affect AMD GPUs, mainly embedded GPUs, so it's really optional. Plus libomxil-bellagio requires a patch to build at the latest release. Unless you're needing multimedia content support on AMD embedded GPUs, OpenMAX support is unnecessary.
Er, I think I said as much.
Quote:
Originally Posted by ReaperX7
DXTC/S3TC support isn't compiled in at any time, its dynamically loaded so you don't need it at build time. It's nice to have but only for games.
That's what I use it for. It seems relevant to the OP's situation too.
Quote:
Originally Posted by ReaperX7
OpenCL however will require libclc from the llvm project and it's only available via git. The OpenCL ICD flag is fairly useless and will tend to break the compile. Not only this, but OpenCL support is limited to AMD only in hardware support, while Intel and Nouveau fallback to software support. At best it's moderately useful, yet equally useless.
It's only useless if you don't have the other packages too, which I do. As I said in an earlier post I have added a lot of other packages.
Quote:
Originally Posted by ReaperX7
The only real addition you might want to make is actually adding Gallium driver "ilo" for Intel chipsets to utilize Nine support for Wine. This, honestly, is the only useful addition anyone could make to the Mesa build other than adding Wayland support. That's it.
Again, this is what I use it for, along with the d3d9 patch for wine. Also kind of relevant to the OP's situation since he might also play some games via wine like I do.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
