That said, before commit 4b945a308 (Nov 5, 2022) there was an unwanted initialization of the graphics driver in the constructor of Fl_Widget (and hence also Fl_Window) which was removed with the mentioned commit. This was necessary for the hybrid X11/Wayland FLTK platform on Unix/Linux, but this early initialization of the graphics driver had been problematic anyway.

This *may* have hidden the problem to access uninitialized font data in your program because it crashed now with the missing graphics driver initialization.

On the other hand, maybe some other toolkits (Qt?) take care of this kind of initialization issue in a global initialization routine that programmers are required to call at the start? Like as with Fl::lock() in FLTK when we need to use MT and locks. Or, as it now appears, fl_open_display(), which might essentially fill that role now in FLTK, so calling it at the start of their program is what everyone should do as boilerplate.

fl_open_display() is called internally in many places when needed, e.g. Fl_Window::show() but also Fl::font(face, size), Fl::get_system_colors() and some (many) more functions. The rule is not to call it if it's not needed (as in fluid in command mode `-c`) but if you're sure your program needs it because it's a GUI program, then it's not wrong to call it at the start of main(). Our goal is to open the display only when necessary and that's usually when Fl_Window::show(...) is called.