Any plan on trying to build on Slackware 15?

[nempk1]

I remember trying to compile xlibre on slackware 15 but the slackware version of the dependencies where "to old".

[ONykyf]

@nempk1
Please see https://github.com/orgs/X11Libre/discussions/275.

I expect this to succeed.

[boggsja83]

I think I read on the XLibre git that slack maintainers are currently on the "we might support xlibre" list. Maybe it was in docs somewhere. But xlibre has lists of maintainers on-board, maintainers not on-board, and undecided maintainers

[ONykyf]

@boggsja83
I am sure that Patrick Volkerding will not consider adoption of XLibre into Slackware even in testing directory until it is at unstable alpha stage. We just have to become more mature, and then he will make a decision.

As far as I understand, the OP asked whether this build tree (intended for Slackware-current) is applicable to stable Slackware-15. I have no working Slackware-15 stable to test, but expect no serious difficulties (apart from the described at start page and in https://github.com/orgs/X11Libre/discussions/275).

I would like to hear what will be the outcome of @nempk1 attempt.

If it will be successful, based on his experience I could extend the slackbuild script to build for stable as well.

[rc-05]

@ONykyf @nempk1 @boggsja83
I can confirm that it's perfectly possible to build and run XLibre on Slackware64 15.0.
Make sure of the following things:

• You must have a recent version of libdrm which can be found on Slackware's testing repository, no need to compile it from source.
• You should also install the X software set to build and upgrade XOrg to XLibre.
• Put all the built packages in the /etc/slackpkg/blacklist file to prevent slackpkg from updating packages related to XLibre.
• Add libdrm to the slackpkg blacklist as a precautionary measure.

The list of packages to blacklist can be generated with this:

find /tmp/x11-build/ -name "*.t?z" | sed -E -e "s_/tmp/x11-build/__" -e "s/-[0-9]+\.[0-9]+\.[0-9].+//" -e "s/-[0-9]+\.[0-9].+//" -e "s/xisxwayland.+/xiswayland/" | sort

I've looked at the build logs and certain elements like the AMDGPU driver fail to build on Slackware64 15.0. In the case of the AMDGPU driver, Slackware 15.0's mesa library is too old.

[rc-05]

To follow up, I've managed to build the remaining drivers by upgrading Mesa from major version 21 to 25 thanks to Slackware's testing repository.

You will also need to use LLVM 20 for the drivers to actually work. In short, you'll need to upgrade libdrm and mesa from the testing repository and you'll need to install llvm-20 from the extra repository.

Then, blacklist libdrm and mesa to prevent slackpkg from accidentally downgrading them.
Older LLVM versions are distributed as separate packages, so they can be installed side-by-side for older programs.

[ONykyf]

@rc-05 Thank you for your information, if you don't mind, I'll use it to update build instructions respectively.

[nempk1]

I have it running on a slackware64-current live for testing and had it working perfecly fine running on the nvidia 470 legacy driver. But i wanted to try testing other things like gaming and was going to install multilib. But then i remember that multilib has packages involving Xorg, decided to continue anyway just to see what happens since its a live distro, then GG. Problems started left to right specially with ldconfig, when looking at the logs it was gettings memory fault and segmentation fault, i will assume the problem was multilib x packages being incompatible this xlibre script.

Is multilib supposed to create problem with this build script for now? Or i made something wrong

[ONykyf]

I have it running on a slackware64-current live for testing and had it working perfecly fine running on the nvidia 470 legacy driver. But i wanted to try testing other things like gaming and was going to install multilib. But then i remember that multilib has packages involving Xorg, decided to continue anyway just to see what happens since its a live distro, then GG. Problems started left to right specially with ldconfig, when looking at the logs it was gettings memory fault and segmentation fault, i will assume the problem was multilib x packages being incompatible this xlibre script.

Is multilib supposed to create problem with this build script for now? Or i made something wrong

@nempk1
Could you describe what problems happened, probably with logs or whatever?

Yes, there are lots of 32-bit X libraries in ~alien/multilib/current/slackware64-compat32/x-compat32/, maybe something there depends on headers /usr/include/xorg, which is different in XLibre. Although most of things here is common for XLibre and XOrg.

[ONykyf]

Now I am trying to install multilib on current first, and then to compile and install XLibre with nvidia470. Will see what happens....

[ONykyf]

@nempk1 @boggsja83

I have just completed the installation of the latest slackware-current with alien's multilib packages, XLibre as in https://github.com/ONykyf/X11Libre-SlackBuild, and nvidia470 kernel modules and driver as in https://github.com/ONykyf/nvidia390-slackbuild. All works out of the box as expected. I have built Wine-10.5 WoW, which is multilib, and run an old WinEDT-1.41, which is a combined 16bit+32bit application. No issues yet, but I haven't tried any gaming yet.

[ONykyf]

@rc-05
Could you review the changes I have made in README at https://github.com/ONykyf/X11Libre-SlackBuild based on your suggestions?

[ONykyf]

@nempk1
I installed MS Office 2007 under Wine on XLibre, which is always 32 bit, and run it without any issues yet. Maybe You could try reinstalling fresh alien's mutlilib, and then rebuild and reinstall XLibre?

[rc-05]

@rc-05 Could you review the changes I have made in README at https://github.com/ONykyf/X11Libre-SlackBuild based on your suggestions?

Changes look fine, I don't see anything wrong with them.

[rc-05]

@ONykyf
Add to the README that libva also needs to be upgraded from the testing repository to let programs use hardware video acceleration with the VA-API specification and upgraded mesa.

As always, libva should also be blacklisted too.

Actually, it would even be better to document all of these caveats with Slackware 15 on a separate README for user friendliness.

I've discovered this problem while analyzing why Firefox did not use hardware video decoding. Another solution would perhaps to re-build Firefox from the SlackBuild but mine is easier because it does not require any recompilation whatsoever.

[ONykyf]

@rc-05

@ONykyf Add to the README that libva also needs to be upgraded from the testing repository to let programs use hardware video acceleration with the VA-API specification and upgraded mesa.

As always, libva should also be blacklisted too.

Done

Actually, it would even be better to document all of these caveats with Slackware 15 on a separate README for user friendliness.

This README would be rather short, I am not sure that following a link to read two paragraphs is more convenient.