OpenGL sous Linux: dlopen libGL.so

Question

La plupart des applications (et bibliothèques) en utilisant OpenGL sur Linux libGL.so de charge lors de l'exécution en utilisant l'API de dlopen, au lieu de lier dynamiquement contre.

Pourquoi font-ils cela?

La seule raison pour laquelle je peux imaginer que c'est parce que tout fournisseur de pilote graphique fournit un libGL différent, et deux libGL différents pourrait être ABI incompatible. (Eh bien, hum, pourquoi devraient-ils être incompatibles ABI? Et même si elles sont, pourquoi les charger via dlopen fixerait cette question?)

Quoi qu'il en soit, en supposant qu'il ya une bonne raison pour le faire, je voudrais faire aussi bien. Quelqu'un at-il un lien vers un opensource code C / C ++ qui charge toutes les fonctions OpenGL via dlopen, que je peux comprendre à mon projet sans avoir besoin trop de coups secs?

Answer 1

Il y a deux principales raisons les gens faire ceci:

1. Vous pouvez donner une erreur sensible pour les systèmes qui ne sont pas OpenGL
2. Les fournisseurs offrent de nombreuses extensions et la seule façon saine pour supporter de multiples ensembles d'extensions sans binaires différents par fournisseur est d'utiliser dlsym pour vérifier pour eux. GLEW offre un moyen agréable de le faire pour vous si.

Answer 2

Ceci est fait de sorte que vous ne devez pas lier statiquement à une mise en œuvre GL, par exemple, si votre code utilise glBindFragDataLocation, qui est disponible sur OpenGL 3.0 et plus récent, il ne parviendrait pas à fonctionner avec une erreur de liaison cryptique sur OpenGL 2.1 et antérieures mises en œuvre.

Alors obtenir des points d'entrée vous permet de sélectionner dynamiquement le chemin de rendu Adéquat lors de l'exécution.

, il est également nécessaire sur Windows pour les fonctions GL> 1.1.

GLEW fait pour vous, il ne DLOpen libGL, il utilise glXGetProcAddress / wglGetProcAddress / aglGetProcAddress pour obtenir des pointeurs de fonction GL du conducteur, et sa plate-forme de croix.