Building glew without GLX

[vanfanel]

Hi there,

Since more and more systems are jumping to Wayland (and embedded GNU/Linux systems use KMS/DRM or Wayland), GLX is becoming something of the past.
There's GLVND, which is vendor-gnostic, for full OpenGL without X11/GLX, too.

So, is it possible to build GLEW without X11/GLX? How?
Looking at the docs, I see SYSTEM=linux-egl but it seems to require GLX too...

I have also located this patch:
https://patchwork.openembedded.org/patch/135251/

Didn't it get merged for some reason?

Thanks!

EDIT: It seems I am not the first person finding the old GLX on my way to building GLEW on Wayland...
#172

EDIT2: I am now confused. As I said, GLEW seems to be looking for GLX instead of GLVND:

CMake Error at /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 (message):
  Could NOT find OpenGL (missing: OPENGL_glx_LIBRARY)

...But I see this commit:
2b50f4a

So in theory it DOES build with GLVND instead of GLX.
I am trying to disable X11 support, but it's still looking for GLX:

pi@raspberrypi:~/src/glew/build $ cmake ./cmake -DGLEW_EGL=ON -DGLEW_X11=OFF        
CMake Error at /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 (message):
  Could NOT find OpenGL (missing: OPENGL_glx_LIBRARY)

[vanfanel]

@nigels-com Can you shed some light to this strange issue, please? It should work.
And GLX is mostly legacy by now, GLVND is the way.

It's even detected by the buildsystem:

root@raspberry:~/src/glew# grep OPENGL_opengl_LIBRARY * -R
build/cmake/CMakeLists.txt:if (OPENGL_opengl_LIBRARY)
build/cmake/CMakeLists.txt:  set (GLEW_LIBRARIES ${OPENGL_opengl_LIBRARY})
CMakeCache.txt:OPENGL_opengl_LIBRARY:FILEPATH=/usr/local/lib/aarch64-linux-gnu/libOpenGL.so

I can also disable find_package (OpenGL REQUIRED) which I guess is incorrectly trying to find GLX, but then I get:

CMake Error at CMakeLists.txt:134 (add_library):
  Cannot find source file:                                                                                                              
                                                                                                                                        
    /root/src/glew/include/GL/wglew.h                                                                                                   
                                                                                                                                        
  Tried extensions .c .C .c++ .cc .cpp .cxx .cu .mpp .m .M .mm .ixx .cppm .h                                                            
  .hh .h++ .hm .hpp .hxx .in .txx .f .F .for .f77 .f90 .f95 .f03 .hip .ispc                                                             
                                                                                                                                        
                                                                                                                                        
CMake Error at CMakeLists.txt:134 (add_library):
  No SOURCES given to target: glew_s                                                                                                    
                                                                                                                                        
                                                                                                                                        
CMake Error at CMakeLists.txt:130 (add_library):
  No SOURCES given to target: glew     

I have been searching and include/GL/wglew.h hasn't existed on GLEW sources for years.

I have also tried with GNU Make and I get this:

root@raspberry:~/src/glew#  make SYSTEM=linux-egl
mkdir lib
make: *** No rule to make target 'src/glew.c', needed by 'tmp/linux-egl/default/shared/glew.o'.  Stop.

...and src/glew.c does not exist on the GLEW sources either.

Maybe the build files are just outdated?

[nigels-com]

The cmake build is mostly user contributed. I can go poke around in there, but I'm probably any more familiar with that than anyone else. For the (first-class supported) GNU make build, see:

https://github.com/nigels-com/glew#code-generation

[vanfanel]

@nigels-com Understood and fixed. Please merge this small PR I did, it works:

#329

[nigels-com]

Great! Thanks!

[vanfanel]

@nigels-com Forgot to add GLEW_NO_GLU = -DGLEW_NO_GLU to the egl-glvnd Makefile.
So can you merge this PR too, please? --> #330

Also, I have noticed that even adding GLEW_NO_GLU = -DGLEW_NO_GLU to the egl-glvnd Makefile, programs built against glew need that I pass -DGLEW_NO_GLU to build them because glew.h tries to include glu.h otherwise.
So, shouldn't GLEW_NO_GLU = -DGLEW_NO_GLU on the egl-glvnd Makefile prevent glu.h inclusion in the generated glew.h?? Or maybe I am missing something here?

[nigels-com]

Probably makes sense to skip the GLU include in EGL mode. Shouldn't need to specify both.

[nigels-com]

The code is the same for WGL, GLX, EGL so glew.h doesn't actually know if the library is built in WGL, GLX or EGL mode.
It's a bit of a pain in these modern days to have to opt-out, but it's that way for existing codebases with (probably unintentional) dependencies on that.

[vanfanel]

Probably makes sense to skip the GLU include in EGL mode. Shouldn't need to specify both.

But how to do this? I do it manually when building the programs using glew.
So I don't understand what you mean exactly (note my english is not perfect).

I understand glu.h inclusion in glew.h should be skipped, but how? glew.h doesn't know about EGL or not EGL, as you said...
(Maybe we are both saying the same thing: There's no solution so -DGLEW_NO_GLU has to be passed to the programs using glew. Am I right?)

[nigels-com]

I did take a look at glew.h just now. I was hoping there would be a good way to skip the GLU inclusion in EGL mode. Less optimistic now.

[nigels-com]

Yes, agreed, you seem stuck with the -DGLEW_NO_GLU, unfortunately.

[vanfanel]

@nigels-com Ah, dont worry, it's OK, I can also "mutilate" glew.h on my systems so I don't have to deal with glu inclusion on every build.
I was just trying to understand.

Thanks, really! I am closing this issue, if that's OK!

[nigels-com]

So while we're chatting about EGL. I'm on both Ubuntu 18.04 and Ubuntu 20.04 with Nvidia GPU and driver.
I'm running in X11 mode, according to:

echo $XDG_SESSION_TYPE
x11

I really don't know if I'm the outlier, it's basically the same machine I've had for 10+ years.

It looks like the system-installed GLEW is X11/GLX.
Question is, what needs to be done for EGL?

$ ldd -r /usr/lib/x86_64-linux-gnu/libGLEW.so.2.1.0
	linux-vdso.so.1 (0x00007fffbf332000)
	libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x00007f736f6ba000)
	libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f736f602000)
	libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f736f5ce000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f736f3dc000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f736f3d6000)
	libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007f736f299000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f736f811000)
	libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f736f26d000)
	libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007f736f267000)
	libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f736f25f000)
	libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f736f245000)

[nigels-com]

Ah, an old thread at Issue #172

[vanfanel]

So while we're chatting about EGL. I'm on both Ubuntu 18.04 and Ubuntu 20.04 with Nvidia GPU and driver. I'm running in X11 mode, according to:

echo $XDG_SESSION_TYPE
x11

I really don't know if I'm the outlier, it's basically the same machine I've had for 10+ years.

It looks like the system-installed GLEW is X11/GLX. Question is, what needs to be done for EGL?

$ ldd -r /usr/lib/x86_64-linux-gnu/libGLEW.so.2.1.0
	linux-vdso.so.1 (0x00007fffbf332000)
	libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x00007f736f6ba000)
	libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f736f602000)
	libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f736f5ce000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f736f3dc000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f736f3d6000)
	libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007f736f299000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f736f811000)
	libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f736f26d000)
	libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007f736f267000)
	libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f736f25f000)
	libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f736f245000)

Hmm.. GLX on X11 should suffice I guess.
But I don't know much about the NVIDIA specifics, I abandoned NVIDIA when I understood and suffered their driver/API politics, and never touched it again.
Something failing on NVIDIA only, it's an NVIDIA issue.

[nigels-com]

Apparently not Nvidia-specific. Ubuntu 20.04 is still X11/GLX by default, but I can opt-in to Wayland, so will try that and see.
There is some prospect that with the WGL/GLX/EGL-neutral initialisation path we might be able to support dual GLX/EGL glew and handle X11 or Wayland more gracefully. Worth some more investigation, at least.

[cbix]

GLFW is implementing runtime platform selection for the upcoming version and by default it's using the first platform that works, so existing software keeps working. It's a slightly different focus but it would be great to see a similar behavior in GLEW wrt. GLX/EGL if compiled with both.

[nigels-com]

Yes, I agree it makes sense for things to move in that direction.
I'm not sure GLEW can do that while remaining compatible, but I agree it should be looked at.

[chewi]

I maintain the glew package on Gentoo Linux. I had a user suggest we support linux-egl as well as linux, which we can do as a source-based distribution, but having it not support X11 and native Wayland at the same time is slightly irritating. I don't understand this stuff very well, but I thought that X11 supported EGL anyway? I'm surprised that doesn't just work.

env -u WAYLAND_DISPLAY supertux2 --renderer opengl
[FATAL] SuperTux-v0.6.3-Source/src/supertux/main.cpp:672 Unexpected exception: GLVideoSystem: GlewError: Missing GL version

env -u WAYLAND_DISPLAY x64dtv.gtk                 
x64dtv.gtk: symbol lookup error: x64dtv.gtk: undefined symbol: __glewXSwapIntervalSGI

[nigels-com]

It's a bit of a historical problem, on the face of it. GLEW was compiled WGL-mode on Windows, and GLX-mode on not-Windows.
With the addition of EGL we have the choice to compile in EGL-mode for either platform, but that's not a runtime choice currently, it's a compile-time one. I'm not sure it can be made a runtime choice in a compatible sort of way.

[chewi]

Okay, but that doesn't quite address my point. If I build it for EGL only, why doesn't it work under X11? It's definitely a thing, Firefox can do it, for example. I'm guessing it needs some additional code in GLEW, but it sounds like it would effectively solve this problem? Or is it down to the application using GLEW, so if that uses GLX then GLEW needs to use it too?

[chewi]

Maybe it would be a lot of work, but I wonder whether Waffle could help here. I heard about it at FOSDEM a few years ago.

[nigels-com]

The reluctance is about breaking compatibility with existing applications that are expecting GLX. The solution would likely be a libGLEW3.so for supporting either/or GLX and EGL on Linux, WGL and EGL on Windows.