"null function or function signature mismatch" for `glClearDepth`

[geometrian]

I believe this issue is the same as Issue 14801 but for glClearDepth; that function is null. Other core functions (such as glClear) load just fine (the loader is GLAD), and the program works correctly under desktop.

Note that glClearDepth takes a double and has been available since OpenGL (not WebGL) 2.0, while glClearDepthf (which I found poking around the Emscripten source) takes a float and is available since OpenGL 4.1 (see docs for both). Note that glClearDepthf is null as well. The corresponding WebGL call is .clearDepth.

Version (emcc -v)

emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.30 (cfe2bdfe2692457cb5f5770672f6e5ccb3ffc2f2)
clang version 16.0.0 (https://github.com/llvm/llvm-project 800f0f1546b2352ba42a4777149afb13cb874fcd)

[sbc100]

Can you explain a little more? Are you trying to link directly against glClearDepth and glClearDepthf? Or are you trying to load them at runtime some how, using dlsym maybe?

Can you share the full link command line you are using? Are you using -sMAIN_MODULE? Does this issue only occur with -sMAIN_MODULE?

[geometrian]

To clarify: I'm using SDL2. GLAD loads all functions at runtime—in this case, it effectively does SDL_GL_GetProcAddress("glClearDepth") (which calls GL_GetProcAddress. On the Windows test system, that's ultimately WIN_GL_GetProcAddress and then wglGetProcAddress or GetProcAddress).

It's a static application, so I don't think MAIN_MODULE should be used. In any case, CMake didn't generate it:

The link command that gets invoked is:

em++.bat -g -fwasm-exceptions -sMIN_WEBGL_VERSION=2 -sMAX_WEBGL_VERSION=2 <filename>.cpp.o -o <filename>.html <lib1>.a <lib2>.a sUSE_SDL=2 -lpthread

[sbc100]

So you are saying that SDL_GL_GetProcAddress("glClearDepth") and SDL_GL_GetProcAddress("glClearDepthf") are both returning NULL? At least the should be an easy repro case to write.

[geometrian]

At least [it] should be an easy repro case to write.

Yes :P

//Compile with "eemcc -Iinclude/ -sUSE_SDL=2 src/glad.c main.cpp -o TestRepro.html"

#include <SDL.h>
#include <emscripten.h>
#include "include/glad/glad.h"

static SDL_Window* window;
static SDL_Renderer* renderer;

static int frame_number = 0;
static void update() {
	SDL_Event event;
	while (SDL_PollEvent(&event)) {}

	printf("Frame %d\n",++frame_number);

	if (frame_number==10) glClearDepth(1.0); //Crash on 10th frame
	glClearColor( 0.0f,0.8f,0.2f, 1.0f );
	glClear( GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT );

	SDL_GL_SwapWindow(window);
};

int main( int argc, char* argv[] ) {
	SDL_CreateWindowAndRenderer( 512,512, SDL_WINDOW_OPENGL, &window, &renderer );
	gladLoadGLLoader( reinterpret_cast<GLADloadproc>(SDL_GL_GetProcAddress) );
	emscripten_set_main_loop( update, 0,1 );
}

This works for the first 9 frames (it draws a green background; how you know it's working). On the 10th it calls glClearDepth, and crashes.

For your convenience, I've also attached a repro that also includes the necessary GLAD loader and some convenience scripts:
TestEmscriptenGLFunction.zip

Lastly, I'll note that with #include <GLES2/gl2.h> instead of GLAD, it works, so I expect it's related to how emscripten wraps vanilla GL.

[sbc100]

Thats interesting.. it looks like its just calling glClearDepth directly here.. not via some kind of dynamic "getProcAddress" type thing. Thanks for the repro, that looks like it should be easy to reproduce.

[geometrian]

(Note: as before, the gladLoadGLLoader ultimately does call wglGetProcAddress/GetProcAddress to load glClearDepth (and glClear, and all the others). GLAD defines GL functions as macros that point to function pointers, which are loaded.)

[sbc100]

I see, thanks, I hadn't noticed that gladLoadGLLoader there. If you run this program without glad (and therefore use direction function call) I assume it works fine?

[sbc100]

Also, just checking, is this a regression (i.e. is there some older version of emscripten where this used to work for you?)?

[geometrian]

If you run this program without glad (and therefore use direction function call) I assume it works fine?

Well, you still have to load OpenGL somehow. As I noted above, using emscripten's #include <GLES2/gl2.h> instead of GLAD does work.

is this a regression

I have not previously used GLAD with glClearDepth successfully, no (it is only recently that I have tried this).