OpenGL sous Linux: dlopen libGL.so

La plupart des applications (et des bibliothèques) utilisant OpenGL sous Linux chargent libGL.so à l’exécution en utilisant l’API dlopen , au lieu de la lier dynamicment.

Pourquoi font-ils cela?

La seule raison pour laquelle je peux imaginer est que c’est parce que tout fournisseur de pilote graphique fournit une libGL différente, et deux libGL différents pourraient être incompatibles avec ABI. (Eh bien, hum, pourquoi devraient-ils être incompatibles avec ABI? Et même s’ils le sont, pourquoi les charger via dlopen permettrait-il de résoudre ce problème?)

Quoi qu’il en soit, en supposant qu’il y ait une bonne raison de le faire, je le ferais aussi. Quelqu’un at-il un lien vers un code opensource C / C ++ qui charge toutes les fonctions OpenGL via dlopen , que je peux inclure dans mon projet sans avoir besoin de beaucoup de réglages?

Il y a deux raisons principales pour lesquelles les gens font ceci:

  1. Vous pouvez donner une erreur sensible pour les systèmes qui n’ont pas OpenGL
  2. Les fournisseurs offrent de nombreuses extensions différentes et la seule manière sensée de prendre en charge plusieurs ensembles d’extensions sans binarys différents par fournisseur est d’utiliser dlsym pour les vérifier. GLEW offre un moyen pratique de le faire pour vous.

Ceci est fait de sorte que vous n’avez pas à établir de lien statique avec une implémentation GL, par exemple, si votre code utilise glBindFragDataLocation, disponible sur OpenGL 3.0 et versions ultérieures, il ne pourra pas s’exécuter avec une erreur de l’éditeur de liens sur OpenGL 2.1 implémentations.

Ainsi, l’obtention dynamic des points d’entrée vous permet de sélectionner le chemin de rendu approprié lors de l’exécution.

En outre, il est requirejs sur Windows pour les fonctions GL> 1.1.

GLEW le fait pour vous, il ne libère pas libGL, il utilise glXGetProcAddress / wglGetProcAddress / aglGetProcAddress pour obtenir des pointeurs de fonction GL à partir du pilote, et la plateforme est croisée.