Initial exploration of GLEW to GLAD migration, Linux support only. #20013

osschar · 2025-09-30T10:34:33Z

This is in response to #18471

GLEW -> GLAD

GLAD generates API / extension specific hooks / loaders that one is then supposed to build and ship along with their package.

For this initial test I just generated the full GL API along wiht GLX and WGL with glad2 that is avalable in Fedora42:

  glad --api gl:compatibility --out-path . c --loader 
  glad --api glx --out-path . c --loader 
  glad --api wgl --out-path . c --loader

and copied include/glad/ to rglew/inc and content of src/ to rglew/src/.

We can remove a big bunch of content by explicitly passing in extensions that we are actually using (very few).

Putting generated files into root source tree is probably preferable to introducing a build-time dependency on glad2.

Historical framebuffer support

TGLFBO is using an old way for doing FBO / multisample stuff.
This was needed for SLC6 support (old MesaGL).

I can bump this as well to a more modern standard.

GLU Include

GLU is also obsolete, we mostly use tesselator (and maybe sphere and cylinder).

There is GLU tesselator extracted for REve Geometry Viewer.

We could, eventually, look into moving it to graf3d/csg/ and drop GLU dependency as well.

At this point we should probably just remove the global GL/glu.h include in TGLIncludes.h (that used to be in GLEW.h) and include it manually where it is actually needed.

CMAKE to do by somebody else

Remove GLEW search, standalone package support.

Renem rglew to rglad?

Fix cmake stuff as it should be, see comments in rglew/CMakeLists.txt

Windows / OSX testing

Try, test with tutorials/eve/alice_esd.C, undocking windows and swapping GL views around.

Misc

I tried making a branch in root-project/root so others could push to it as well but apparently don't have enough magick for that anymore.

guitargeek · 2025-09-30T11:11:20Z

We can remove a big bunch of content by explicitly passing in extensions that we are actually using (very few).

Putting generated files into root source tree is probably preferable to introducing a build-time dependency on glad

100 %, absolutely, this is the way to go!

Thanks for opening the PR. Will you also look at the macOS situation, or you prefer this to be done by someone else?

osschar · 2025-09-30T11:45:57Z

We definitely need someone to try windows, I put the wgl loading in completely blindly.

If somebody can check osxi that would be great, in principle it should "just work" ™️. There is a mac in the house here, not mine ... I had one 10+ years back, loved it for a week (before actually trying to do anything real), hated it for 3 years, then finally rendered two souls free by installing GNU/Linux on it :)

Also definitely, we need somebody to do the cmake part, probably that person and I should talk before.

I can cleanup the FBO/multisample stuff so we have the correct set of required extensions. Unless you guys want to keep SLC6 support :)

guitargeek · 2025-09-30T12:27:41Z

Ok, thanks! Then what I would suggest to do is to add a commit to this PR branch that fixes the macOS and alma8 failures, and then next week when @bellenot is back from vacation we also have the Windows and CMake expert here to help you to wrap up this PR 🙂

github-actions · 2025-09-30T12:57:38Z

Test Results

20 files 20 suites 3d 7h 7m 21s ⏱️
3 654 tests 3 653 ✅ 0 💤 1 ❌
72 352 runs 72 351 ✅ 0 💤 1 ❌

For more details on these failures, see this check.

Results for commit ba108c9.

♻️ This comment has been updated with latest results.

osschar · 2025-09-30T15:40:10Z

OK, let me know if you want to move the branch to the main repo or I can add people here as collaborators to add in fixes for osx / alma8. Or they can make PRs against my branch, although I'm not a big fan of high-protocol dancing.

osschar · 2025-09-30T15:46:13Z

If you trust LLMs, the alma8 problem seems to be the following ... so fixing it would be a part of the cmake setup.

gl.c from glad fails to link on alma8, failing to know what dlopen dlclose are. the same source builds fine on alma9 and on fedora 42

This specific compilation error points to a key difference in the C library (glibc) between Red Hat Enterprise Linux 8 (and its clones like AlmaLinux 8) and newer releases like AlmaLinux 9 and Fedora 42.

The Core Difference: libdl vs. libc

RHEL 8 / AlmaLinux 8: In this older generation, the dynamic linking functions like dlopen and dlclose resided in a separate library file, libdl.so. This required that when you link your program, you must explicitly add the -ldl flag to the compiler command.

RHEL 9 / AlmaLinux 9 / Fedora 42: In the newer glibc versions used by these systems, the dynamic linking functionality from libdl has been merged directly into the main C library, libc.so.6. For most programs, this change means you no longer need the -ldl flag, as the functions are automatically available when you link against libc, which happens by default.

Why glad.c fails on AlmaLinux 8

The glad.c file itself is just source code. The compilation failure is a linker error, not a preprocessor error. The error occurs at the final stage of building the executable because the linker on AlmaLinux 8 cannot find the definitions for dlopen and dlclose in the default libraries it searches.

The Solution for AlmaLinux 8

To fix the build on AlmaLinux 8, you must explicitly link against the libdl library.
Assuming you are using a simple gcc command to compile your application:

sh
# This will fail on AlmaLinux 8
gcc -o my_app main.c glad.c

# This is the correct command for AlmaLinux 8
gcc -o my_app main.c glad.c -ldl
Use code with caution.

If you are using a build system like CMake, you can add the following to your CMakeLists.txt file to automatically handle this difference across platforms: 
cmake
# This variable stores the correct link flag for the system
find_library(DL_LIBRARY dl)
target_link_libraries(my_app PUBLIC ${DL_LIBRARY})

# Or for more modern CMake, use CMAKE_DL_LIBS
target_link_libraries(my_app PUBLIC ${CMAKE_DL_LIBS})

Use code with caution.

This tells CMake to find the dynamic linking library and pass the correct link flag to the compiler, which will be -ldl on older systems and nothing on newer ones where it's no longer necessary.

guitargeek · 2025-09-30T16:50:18Z

OK, let me know if you want to move the branch to the main repo or I can add people here as collaborators to add in fixes for osx / alma8. Or they can make PRs against my branch, although I'm not a big fan of high-protocol dancing.

The root repo is configured such that all team members can push commits to PR branches, so I could just add the commits here to fix alma8 and macOS. Is that okay?

osschar · 2025-09-30T18:01:12Z

Yes, absolutely, that's what I hoped for 🙂 And thank you!

guitargeek · 2025-10-01T14:03:10Z

Try, test with tutorials/eve/alice_esd.C, undocking windows and swapping GL views around.

Works on macOS 26 now!

osschar · 2025-10-01T15:08:06Z

Yay! I see you're having some fun here :)

guitargeek · 2025-10-01T15:49:52Z

Hi @osschar! I'm done with the platform support updates for now, but there are also other problems at runtime where we need your help to figure them out.

If I try to run the grad.C tutorial, it crashes now with the following multi-threaded stack trace.

To you have any idea what could be wrong there?

===========================================================
There was a crash.
This is the entire stack trace of all threads:
===========================================================
#0  0x00007f4d5ab0a4a7 in wait4 () from /nix/store/776irwlgfb65a782cxmyk61pck460fs9-glibc-2.40-66/lib/libc.so.6
#1  0x00007f4d5aa56b6b in do_system () from /nix/store/776irwlgfb65a782cxmyk61pck460fs9-glibc-2.40-66/lib/libc.so.6
#2  0x00007f4d5b515a16 in TUnixSystem::StackTrace (this=0x557b7cf01400) at /home/rembserj/code/root/root_src/core/unix/src/TUnixSystem.cxx:2450
#3  0x00007f4d5b5196c3 in TUnixSystem::DispatchSignals (this=0x557b7cf01400, sig=kSigSegmentationViolation) at /home/rembserj/code/root/root_src/core/unix/src/TUnixSystem.cxx:3670
#4  <signal handler called>
#5  0x0000000000000000 in ?? ()
#6  0x00007f4d3db42471 in TGLPadPainter::InitPainter (this=0x557b7fbae6d0) at /home/rembserj/code/root/root_src/graf3d/gl/src/TGLPadPainter.cxx:342
#7  0x00007f4d40058816 in TCanvas::Flush (this=0x557b7e6b4700) at /home/rembserj/code/root/root_src/graf2d/gpad/src/TCanvas.cxx:1158
#8  0x00007f4d3e90207d in TRootCanvas::HandleContainerExpose (this=0x7f4d3dc0f798 <vtable for TGLPadPainter+16>, event=0x0) at /home/rembserj/code/root/root_src/gui/gui/src/TRootCanvas.cxx:1952
#9  TRootContainer::HandleExpose (this=<optimized out>, ev=0x0) at /home/rembserj/code/root/root_src/gui/gui/src/TRootCanvas.cxx:247
#10 0x00007f4d3e8466a2 in TGFrame::HandleEvent (this=0x557b7f7bd460, event=0x7ffc171f7ff0) at /home/rembserj/code/root/root_src/gui/gui/src/TGFrame.cxx:459
#11 0x00007f4d3e80bb75 in TGClient::HandleEvent (this=0x557b7f411150, event=0x7ffc171f7ff0) at /home/rembserj/code/root/root_src/gui/gui/src/TGClient.cxx:852
#12 0x00007f4d3e80ba10 in TGClient::ProcessOneEvent (this=this
entry=0x557b7f411150) at /home/rembserj/code/root/root_src/gui/gui/src/TGClient.cxx:662
#13 0x00007f4d3e80a338 in TGClient::HandleInput (this=0x557b7f411150) at /home/rembserj/code/root/root_src/gui/gui/src/TGClient.cxx:709
#14 TGInputHandler::Notify (this=<optimized out>) at /home/rembserj/code/root/root_src/gui/gui/src/TGClient.cxx:117
#15 0x00007f4d5b512006 in TUnixSystem::DispatchOneEvent (this=0x557b7cf01400, pendingOnly=<optimized out>) at /home/rembserj/code/root/root_src/core/unix/src/TUnixSystem.cxx:1098
#16 0x00007f4d5b43699a in TSystem::InnerLoop (this=0xb71) at /home/rembserj/code/root/root_src/core/base/src/TSystem.cxx:401
#17 0x00007f4d5b4367b5 in TSystem::Run (this=0x557b7cf01400) at /home/rembserj/code/root/root_src/core/base/src/TSystem.cxx:351
#18 0x00007f4d5b3d51f5 in TApplication::Run (this=0x557b7cf368f0, retrn=false) at /home/rembserj/code/root/root_src/core/base/src/TApplication.cxx:1894
#19 0x00007f4d5b77f4d5 in TRint::Run (this=0x557b7cf368f0, retrn=<optimized out>) at /home/rembserj/code/root/root_src/core/rint/src/TRint.cxx:504
#20 0x0000557b4b116572 in main (argc=1, argv=0x7ffc171fa438) at /home/rembserj/code/root/root_src/main/src/rmain.cxx:84
===========================================================


The lines below might hint at the cause of the crash. If you see question
marks as part of the stack trace, try to recompile with debugging information
enabled and export CLING_DEBUG=1 environment variable before running.
You may get help by asking at the ROOT forum https://root.cern/forum
preferably using the command (.forum bug) in the ROOT prompt.
Only if you are really convinced it is a bug in ROOT then please submit a
report at https://root.cern/bugs or (preferably) using the command (.gh bug) in
the ROOT prompt. Please post the ENTIRE stack trace
from above as an attachment in addition to anything else
that might help us fixing this issue.
===========================================================
#5  0x0000000000000000 in ?? ()
#6  0x00007f4d3db42471 in TGLPadPainter::InitPainter (this=0x557b7fbae6d0) at /home/rembserj/code/root/root_src/graf3d/gl/src/TGLPadPainter.cxx:342
#7  0x00007f4d40058816 in TCanvas::Flush (this=0x557b7e6b4700) at /home/rembserj/code/root/root_src/graf2d/gpad/src/TCanvas.cxx:1158
#8  0x00007f4d3e90207d in TRootCanvas::HandleContainerExpose (this=0x7f4d3dc0f798 <vtable for TGLPadPainter+16>, event=0x0) at /home/rembserj/code/root/root_src/gui/gui/src/TRootCanvas.cxx:1952
#9  TRootContainer::HandleExpose (this=<optimized out>, ev=0x0) at /home/rembserj/code/root/root_src/gui/gui/src/TRootCanvas.cxx:247
#10 0x00007f4d3e8466a2 in TGFrame::HandleEvent (this=0x557b7f7bd460, event=0x7ffc171f7ff0) at /home/rembserj/code/root/root_src/gui/gui/src/TGFrame.cxx:459
#11 0x00007f4d3e80bb75 in TGClient::HandleEvent (this=0x557b7f411150, event=0x7ffc171f7ff0) at /home/rembserj/code/root/root_src/gui/gui/src/TGClient.cxx:852
#12 0x00007f4d3e80ba10 in TGClient::ProcessOneEvent (this=this
entry=0x557b7f411150) at /home/rembserj/code/root/root_src/gui/gui/src/TGClient.cxx:662
#13 0x00007f4d3e80a338 in TGClient::HandleInput (this=0x557b7f411150) at /home/rembserj/code/root/root_src/gui/gui/src/TGClient.cxx:709
#14 TGInputHandler::Notify (this=<optimized out>) at /home/rembserj/code/root/root_src/gui/gui/src/TGClient.cxx:117
#15 0x00007f4d5b512006 in TUnixSystem::DispatchOneEvent (this=0x557b7cf01400, pendingOnly=<optimized out>) at /home/rembserj/code/root/root_src/core/unix/src/TUnixSystem.cxx:1098
#16 0x00007f4d5b43699a in TSystem::InnerLoop (this=0xb71) at /home/rembserj/code/root/root_src/core/base/src/TSystem.cxx:401
#17 0x00007f4d5b4367b5 in TSystem::Run (this=0x557b7cf01400) at /home/rembserj/code/root/root_src/core/base/src/TSystem.cxx:351
#18 0x00007f4d5b3d51f5 in TApplication::Run (this=0x557b7cf368f0, retrn=false) at /home/rembserj/code/root/root_src/core/base/src/TApplication.cxx:1894
#19 0x00007f4d5b77f4d5 in TRint::Run (this=0x557b7cf368f0, retrn=<optimized out>) at /home/rembserj/code/root/root_src/core/rint/src/TRint.cxx:504
#20 0x0000557b4b116572 in main (argc=1, argv=0x7ffc171fa438) at /home/rembserj/code/root/root_src/main/src/rmain.cxx:84
===========================================================

osschar · 2025-10-01T23:09:48Z

Thank you .. I'll give grad.C a spin.

I'd recommend we use command-line generation of glad stuff (and put it as comment in cmake-file or a readme), so it's easier to modify later (I see you used the web version). Do you want me to bring the multisampling/FBO up to the latest standard? Then we'd need to modify the extension list :)

I don't think we need kronos-types stuff.

guitargeek · 2025-10-01T23:13:56Z

Thanks! Yes that would be great 👍 Indeed, we can probably remove the kronos headers. I thought it was needed on mac, but then the problem were some include paths that were not set in the end.

No, I didn't use the web interface for the final generation 🙂 These are the commands I used:

glad --out-path=out/ --api='gl:compatibility=4.6' --extensions='GL_ARB_framebuffer_object,GL_ARB_multisample,GL_EXT_framebuffer_blit,GL_EXT_framebuffer_multisample,GL_EXT_framebuffer_object,GL_NV_framebuffer_multisample_coverage' c --loader
glad --out-path=out/ --api='glx=1.4' --extensions='GLX_ARB_multisample' c --loader
glad --out-path=out/ --api='wgl=1.0' --extensions='WGL_ARB_extensions_string,WGL_ARB_multisample,WGL_EXT_extensions_string' c --loader

I only used the web interface intermediately to figure out the extensions

osschar · 2025-10-01T23:15:47Z

Ah, good, I thought I saw it as comment in one of the generated files.

osschar · 2025-10-02T00:55:56Z

The grad.C thing ... turns out it's a major PITN. It goes down into parts of legacy GL usage in ROOT I have never been involved with, the old TVirtualGL and TGLManager stuff that allows open-gl calls in TPad. Bertrand might remember some of it, Timur did most of the latest work there (none of it recent, of course).

TGLManager has subclasses:

TX11GLManager in graf3d/gl
TGWin32GLManager in graf2d/win32gdk (sigh)
TGOSXGLManager in graf2d/cocoa (also sigh), it's C# source

So Win32 and OSX call gl-stuff from outside of graf3d/gl/. Yay.

The gl/glx there doesn't use any extensions, I think it's all 1.5 (or maybe 2.0) ... and so it didn't use glew. glad wraps all calls as function pointers and sets them up at init time ... so when these functions call gl-stuff it's all nullptrs. Yay 2, etc.

Maybe talk to Bertrand and Olivier if they remember anything.

I'll sleep on it for a bit as well. ... but it seems we need to find a way to call glad-loaders in those managers (preferably through a common interface as in TGLWidget/TGLContext). Probably we'd need to move the win/osx GLManagers to graf3d/gl/.

IIUC, those things get pulled in through etc/plugins/TVirtualGLImp ... there are X11 and Win32 loaders, they both also pull in RGL. Not sure how this gets done on OSX.

osschar requested review from bellenot and couet as code owners September 30, 2025 10:34

guitargeek force-pushed the glew-to-glad branch from f2a1103 to 5713b9d Compare September 30, 2025 17:28

guitargeek force-pushed the glew-to-glad branch from 42d418d to ef6f743 Compare October 1, 2025 08:27

guitargeek requested a review from dpiparo as a code owner October 1, 2025 11:06

osschar and others added 9 commits October 1, 2025 16:24

Initial exploration of GLEW to GLAD migration, Linux support only.

d38e341

Only build glx if x11=ON

3cce7fc

Add KHR/khrplatform.h generated by glad

765c869

Include OpenGL/glu.h instead of GL/glu.h on macOS

edcb998

Use RGlew in TGCocoa

e1812c3

Remove traces of glew

e07a329

wglew -> wgl

9a9dcd7

Link RGlew against dl

24118f3

Also compile wgl.c

20e05ec

guitargeek force-pushed the glew-to-glad branch from 31884b7 to 20e05ec Compare October 1, 2025 14:33

guitargeek added 2 commits October 1, 2025 17:11

Improve rglew/CMakeLists.txt

38b52a6

rglew: remove unneeded extensions

ba108c9

dpiparo assigned silverweed Oct 8, 2025

dpiparo requested a review from silverweed October 8, 2025 05:08

dpiparo assigned guitargeek Oct 8, 2025

Initial exploration of GLEW to GLAD migration, Linux support only. #20013

Are you sure you want to change the base?

Initial exploration of GLEW to GLAD migration, Linux support only. #20013

Uh oh!

Conversation

osschar commented Sep 30, 2025

GLEW -> GLAD

Historical framebuffer support

GLU Include

CMAKE to do by somebody else

Windows / OSX testing

Misc

Uh oh!

guitargeek commented Sep 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

osschar commented Sep 30, 2025

Uh oh!

guitargeek commented Sep 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Sep 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Test Results

Uh oh!

osschar commented Sep 30, 2025

Uh oh!

osschar commented Sep 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

gl.c from glad fails to link on alma8, failing to know what dlopen dlclose are. the same source builds fine on alma9 and on fedora 42

The Core Difference: libdl vs. libc

Why glad.c fails on AlmaLinux 8

The Solution for AlmaLinux 8

Uh oh!

guitargeek commented Sep 30, 2025

Uh oh!

osschar commented Sep 30, 2025

Uh oh!

guitargeek commented Oct 1, 2025

Uh oh!

osschar commented Oct 1, 2025

Uh oh!

guitargeek commented Oct 1, 2025

Uh oh!

osschar commented Oct 1, 2025

Uh oh!

guitargeek commented Oct 1, 2025

Uh oh!

osschar commented Oct 1, 2025

Uh oh!

osschar commented Oct 2, 2025 • edited by dpiparo Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

guitargeek commented Sep 30, 2025 •

edited

Loading

guitargeek commented Sep 30, 2025 •

edited

Loading

github-actions bot commented Sep 30, 2025 •

edited

Loading

osschar commented Sep 30, 2025 •

edited

Loading

osschar commented Oct 2, 2025 •

edited by dpiparo

Loading