fltk FTBFS if opengl (mesa) is not available, but wayland, wayland-protocols, libxkbcommon, and pango (with cairo) are

[pierre]

In this case, configure just flags:

checking for glXGetProcAddressARB in -lGL... no

and exits successfully. But then compilation fails:

Compiling Fl_Gl_Device_Plugin.cxx...
Compiling Fl_Gl_Window.cxx...
Compiling freeglut_geometry.cxx...
In file included from Fl_Gl_Window_Driver.H:28,
                 from Fl_Gl_Device_Plugin.cxx:21:
../FL/gl.h:65:14: fatal error: GL/gl.h: No such file or directory
   65 | #    include <GL/gl.h>
      |              ^~~~~~~~~
compilation terminated.
In file included from ../FL/glut.H:43,
                 from freeglut_geometry.cxx:28:
../FL/gl.h:65:14: fatal error: GL/gl.h: No such file or directory
   65 | #    include <GL/gl.h>
      |              ^~~~~~~~~
compilation terminated.

mesa and glu are only optional dependencies of fltk in the book. It is possible to remove the dependency on mesa by passing --disable-gl to configure, but we may not want to do this: the main interest of fltk is its ability to use hardware acceleration through opengl.

It is also possible to pass --disable-wayland to fix the issue when mesa is not installed and the other dependencies mentioned in the summary are.

But anyway I think we should promote glu (which requires mesa) to recommended.

[pierre]

Another point not directly related to the ticket (well, arguably a little) is that upstream does not maintain autotools build anymore and recommend using cmake. This might be the opportunity to shift build systems.

[Bruce Dubbs]

I concur with your recommendation. Thanks for doing this.

[zeckma]

I don't have a Mesa GL system, but I tried to do some testing regardless, since I know that CMake and Mesa GL can often not get along.

By default, when Wayland exists, FLTK will check for GLU. If GLU is present, it will try to look for OpenGL. This is advertised by opengl.pc. If this file does not exist, configuration will bomb.

opengl.pc is not provided by Mesa, but gl.pc and egl.pc are provided by Mesa.

The module for searching for GLU, which is just the FindOpenGL module, is provided by CMake.

The CMake modules heavily prefer libOpenGL and opengl.pc to exist and can sometimes clash when EGL is in the mix, which is the main reason why I tested this.

In other words, from my limited testing, we can't check for GLU via CMake.

Perhaps we could add opengl.pc as part of the Mesa installation, but I think that's more of a bandaid fix and may lead to undesirable effects.

[Douglas R. Reno]

As Zeckma mentioned above, it could be nearly impossible for us to check for GLU via CMake because we're using Mesa GL and not libglvnd (like almost all other distributions are doing at this point, we're again one of the extremely few outliers)

Promoting glu right now is a good temporary workaround, but this is something that we should revisit in the future.

[pierre]

So, if I understand correctly, there is no way to check for GLU with cmake. Note that autotools don't even check it. But GLU is only needed (and checked by cmake IIUC) if wayland is installed, while in the book, fltk is only required by tigervnc, which is an X11 package anyway (other dependent packages are pinentry (optional) and alsa-tools (for some specific tools)). So I think promoting GLU is not needed, and we should find a way to disable GLU if wayland is installed (not sure it is possible with autotools, and haven't looked at cmake yet).

Another possibility would be installing libglvnd, but there has been a ​mail thread* about it, and no compelling reason for installing it emerged. Would the build system shift in fltk be enough of a reason to put libglvnd in the book?

!* Thanks to Zeckma for mentioning it on discord

[zeckma]

Part of the argument I was going for was that SLFS already has multiple packages that outright require libglvnd, and when they have been pressed to allow Mesa libGL, they said the burden lies upon CMake, which they won't really fix the issues with the FindOpenGL module.

And while CMake has that issue, it's only a matter of time before other packages in BLFS require libglvnd, specifically libraries like libOpenGL. The reason a project may do this is that libGL is fundamentally tied to X.org, and libOpenGL is a neutral way of working with OpenGL and not be tied to X.org. This is ideal for Wayland. It will be too much work to work around this with bandaid fixes and patches in the future. It's far better to future proof. After all, we are going against the grain, here, at the detriment to a lot of users' experience.

There is a way that checking for GLU can be done in CMake, but you cannot use the modules for it. You have to search for the libraries and headers manually instead. This is not encouraged at all but it seems to be the main way to go around the issue. IIRC, xine-lib uses this technique.

I plan on doing an audit with Mesa libGL to see the full scale of the issue, and see if it's more than FLTK that are ticking time bombs waiting to land here.

[pierre]

Actually, doing more testing, the FTBFS is only when wayland{,-protocols}, libxkbcommon, and pango (built upon cairo) are present and mesa is not. When using autotools, it fails during the build (make) stage. When using cmake, it fails during the configuration (cmake) stage. I modify the title accordingly.

[pierre]

Replying to zeckma:

Part of the argument I was going for was that SLFS already has multiple packages that outright require libglvnd, and when they have been pressed to allow Mesa libGL, they said the burden lies upon CMake, which they won't really fix the issues with the FindOpenGL module.

Should we open another ticket for this discussion? Anyway, it looks like fltk has its own cmake modules for finding GLU (CMake/ressources.cmake and CMake/options.cmake), so the discussion might not be relevant for this case.

[pierre]

Fixed at 294c83519b. Promoted GLU to recommended, and changed build system to cmake. GLU is correctly found.

[zeckma]

Replying to pierre:

Should we open another ticket for this discussion?

Not yet. I'm starting my audit. It's interesting FLTK does its own checking, and there's some logic checking for libGL and GLU + OpenGL. I'll fiddle with the build system eventually myself. Nice to know that it does work as is, however.