OpenGL en Linux: dlopen libGL.so

Question

La mayoría de las aplicaciones (y bibliotecas) que usan OpenGL en Linux cargan libGL.so en tiempo de ejecución usando la API dlopen, en lugar de enlazar dinámicamente con ella.

¿Por qué lo hacen?

La única razón que me puedo imaginar es que es porque cualquier proveedor de controladores gráficos proporciona un libGL diferente, y dos libGL diferentes podrían ser incompatibles ABI. (Bueno, hum, ¿por qué deberían ser ABI incompatibles? E incluso si lo son, ¿por qué cargarlos a través de dlopen solucionaría este problema?)

De todos modos, suponiendo que haya una buena razón para hacerlo, me gustaría hacer eso tambien. ¿Alguien tiene un enlace a un código C/C++ de código abierto que carga todas las funciones OpenGL a través del dlopen, que puedo incluir en mi proyecto sin necesidad de demasiados ajustes?

Answer 1

Hay dos razones principales que la gente hace esto:

1. le puede dar un error más útil para sistemas que no tienen OpenGL
2. Los vendedores ofrecen muchas extensiones diferentes y la única manera sensata para soportar múltiples conjuntos de extensiones sin binarios diferentes por proveedor es usar dlsym para buscarlas. GLEW ofrece una buena manera de hacer esto por usted.

Answer 2

Esto se hace para que no se tiene que vincular estáticamente a una aplicación GL, por ejemplo, si su código utiliza glBindFragDataLocation, que está disponible en OpenGL 3.0 y posteriores, éste deje de funcionar con un enlazador críptica error en OpenGL 2.1 y las implementaciones anteriores.

Conseguir puntos de entrada de forma dinámica le permite seleccionar la ruta de representación adecuada en el tiempo de ejecución.

Además, es necesario en Windows para funciones GL> 1.1.

GLEW hace esto por usted, no abre libGL, usa glXGetProcAddress/wglGetProcAddress/aglGetProcAddress para obtener punteros de función GL desde el controlador, y es multiplataforma.