SFML EOL - solution?

OpenCL
#1

In trying to build OpenCL SDK on RHEL 8.5, a problem arises that OpenCL requires SFML. SFML is no longer supported by its developers. Also, it is not supported by RedHat. Also, when trying to build SFML from source it requires libudev, which in RHEL 8 apparently has been replaced by libgudev. In any case, the cmake build system for the latest SFML (2.5.1) fails on RHEL 8.5, even if libgudev and libgudev-devel packages are installed.

Is there a solution to this problem? So OpenSL can be used on RHEL 8.5?

#2

I don’t know much about SFML, but the repository has received a fairly steady stream of commits this year so far - that doesn’t look like a dead project to me.

As far as I can tell libudev.h is provided by the systemd-devel package at least on the CentOS 8 machine I have partial access to.
I believe SFML is also only needed for the examples in the SDK, so OpenCL itself can be used without it.

#3

O.k. thanks for the inputs. Opencl cmake fails without SFML. I will see if I can edit the cmake config files so it will build without SFML.

The creator of SFML is on record saying that the project is no longer under development. Whether that means it is a dead project is a matter of opinion. I am aware that some open source people have created SFML modules for Centos 7 and 8, and there may be something for Centos Stream 8. However, it is not available in the RHEL 8 repos and so far RedHat has not responded to my queries about supporting it in RHEL 8.

One of the issues for SFML maintenance is that it requires libudev, which appears to be considered obsolete by RedHat. Still working on getting a definitive statement on that from RH. Likely, the libudev dependencies could be replaced with libgudev with minor code mods, but someone would have to go to the trouble…

#4

Hmm, libgudev says it provides GObject bindings for libudev and lists libudev as a dependency in its build system.
Is there perhaps a misunderstanding between RH deprecating the libudev/libudev-devel packages (because they got rolled into systemd/systemd-devel packages or similar) vs deprecating the actual library?