extensionSupportedGLX Segmentation Fault

Thanks for making GLFW, I’ve been using it for a while in my application, but recently it stopped working and throws an exception on the first call to glfwCreateWindow. I made a simpler program and it works fine there so I know my OS (Ubuntu 20.14) and X11/GPU driver stack are good (mesa/Intel Iris). There are too many moving parts for me to identify what’s changed since I last tried it. I downloaded and compiled the GLFW code in debug and found that it dies here: glXQueryExtensionsString(_glfw.x11.display, _glfw.x11.screen);

display is a valid pointer and screen is zero. Gdb stack indicates that _dlopen was called and exception thrown. I had to add the -ldl library to link with the GLFW source.
I even moved the window creation to the main thread after reading your FAQs.
Here’s the GLFW code I use:
#include <GLFW/glfw3.h>
#include <GL/gl.h>
#include <GL/glext.h>
static GLFWwindow* _win;

// now called from main thread
bool InitGL(void)
bool ret = glfwInit ();
if (ret)
_win = glfwCreateWindow (640, 480, “Display”, NULL, NULL);
return ret;

Here’s the compile options:
/usr/bin/gcc -g -fPIC -fno-rtti -Wno-long-long -Wno-multichar -Wno-format-security -Wno-endif-labels -Wno-narrowing -m64 -MMD -fno-exceptions -DNULL=0 -D__STL_USE_NEW_IOSTREAMS -D__STL_NO_EXCEPTION_HEADER -D__STL_NO_BAD_ALLOC -DCUSTOM_EXCEPTIONS -L/home/dev003/GLFW/glfw/src -Wl,–hash-style=gnu -Wl,–as-needed -lglfw3 -lGL -ldl -lm -lstdc++ -lpthread -lrt

I’ve been stuck on this for days, please help.

Hi fritz, welcome to the GLFW form!

I’m not sure from your post if the code and compile line given are the full reproduction - are they? I don’t see the source file in the compile line.

Could you try building the code, tests and examples with cmake and then running some of the examples and tests to see if they work?

If these work (which I expect they will since you mention a simple program does) then a next step might be to alter an example or this cmake starter with the minimal differences needed to get the problem, then report back here and we can take a look at the what’s going on.


Hi Doug,

The application has a million LOC, so I only included the useful bits and pasted the compile options that were related. The simpler application is the rendering core removed from it and is still quite big, but works fine. However, the make for it is much simpler:

all: $(OBJ)
	@gcc $(CFLAGS) -I. -o gputest $^ \
    -lm -lstdc++ -lpthread -lglfw -lGL

As far as I can tell it does the same thing at startup. I haven’t tried any examples as they use Glad and I don’t have it installed. I only use core EXT calls. Maybe I should just remove that call from GLFW?

I know this is not much to go on, but it seems to be related to dlopen trying to load a library but I don’t know which one. By now I’m fairly convinced it’s a make issue.

Thanks for your help!

I got it to work by removing these compile options:
-fPIC -fno-rtti -m64

I’ll try to narrow it down, but it takes a while to build.

That wasn’t enough information to deduce the problem for me - but it looks like you’re beginning to narrow it down.

You don’t need Glad installed, the source code from Github includes the Glad dependencies and should build from cmake.

-fno-rtti shouldn’t do anything for GLFW as it’s C code. -fPIC should only be needed if you’re building a library.

-m64 should be fine, and on a 64bit system I would have thought the default gcc target would be 64bit, but you can check that with gcc -v.

Thanks for your time Doug, sometimes it just helps to tell someone about your problems. LOL

Most of the code in the application is built into libraries.
It turns out that it’s a combination of -fno-rtti and the application redefining global new/delete. Both of which I can remove for the Ubuntu build.

Feel free to remove this thread if you think it won’t be useful for anyone else.

Happy to be a Rubber Duck if that’s what it takes to get things working :slight_smile: