开发者

OpenGL on Linux: dlopen libGL.so

开发者 https://www.devze.com 2023-01-25 08:45 出处:网络
Most applications (and libraries) using OpenGL on Linux load libGL.so at runtime using dlopen API, instead of dynamically linking against it.

Most applications (and libraries) using OpenGL on Linux load libGL.so at runtime using dlopen API, instead of dynamically linking against it.

Why do they do this?

The only reason I can imagine is that it's because any graphic driver vendor provides a different libGL, and two different libGL could be ABI incompatible. (Well, hum, why should they be ABI incompatible? And even if they are, why loading them via dlopen would fix this issue?)

Anyway, supposing there's a开发者_开发百科 good reason for doing that, I'd like to do that as well. Does anybody have a link to an opensource C/C++ code that loads all the OpenGL functions via dlopen, which I can include to my project without needing too many tweaks?


There are two main reasons people do this:

  1. You can give a sensible error for systems that don't have OpenGL
  2. Vendors offer many different extensions and the only sane way to support multiple sets of extensions without different binaries per vendor is to use dlsym to check for them. GLEW offers a nice way of doing this for you though.


This is made so you don't have to statically link to a GL implementation, for example, if your code uses glBindFragDataLocation, which is available on OpenGL 3.0 and newer, it would fail to run with a cryptic linker error on OpenGL 2.1 and earlier implementations.

So getting entry points dynamically allows you to select the apropiate rendering path at runtime.

Also, it's required on Windows for GL functions > 1.1.

GLEW does this for you, it doesn't dlopen libGL, it uses glXGetProcAddress/wglGetProcAddress/aglGetProcAddress to get GL function pointers from the driver, and it's cross platform.

0

精彩评论

暂无评论...
验证码 换一张
取 消