Hard GLX dependency prevents builds on systems without X

[kwryankrattiger]

There seems to be a hard dependency on Unix platforms to use a GL interface provided by GLX. This causes problems when X is not available, such as when osmesa is the GL provider.

Is there a reason for including the GLX header explicitly here? Should this be guarded differently for cases when glx is not available?

[kwryankrattiger]

device/rocm/rocglinterop.hpp

[kwryankrattiger]

     195    In file included from /tmp/root/spack-stage/spack-stage-hip-5.1.3-2w3ogmhv7xfhtvchd4igen
            feywpmtk2k/spack-src/rocclr/device/rocm/rocglinterop.cpp:26:
  >> 196    /tmp/root/spack-stage/spack-stage-hip-5.1.3-2w3ogmhv7xfhtvchd4igenfeywpmtk2k/spack-src/r
            occlr/cmake/../device/rocm/rocglinterop.hpp:26:10: fatal error: GL/glx.h: No such file o
            r directory
     197       26 | #include <GL/glx.h>
     198          |          ^~~~~~~~~~
     199    compilation terminated.

[Mystro256]

I believe it's used for GL-CL interop support (hence the filename "rocglinterop"). I believe there's an equivalent HIP-GL interop, but I'm not sure since I've only really worked with OCL.

I don't believe the libraries are currently designed to allow compiling with smaller subsets of functionality, i.e. with no GL interop support.

[kwryankrattiger]

I guess my wondering is why is GLX required all the time. OpenCL is able to interop with EGL or GLX, so if only one is available at build disable the other. Requiring both makes it difficult to build this package on systems that only have one option, ie. headless servers/containers/etc. and impossible to build using headless renders, requiring additional packages needed by X that are otherwise unnecessary.