OpenGL w systemie Linux: dlopen libGL.so

Question

Większość aplikacji (i bibliotek) korzystających z OpenGL w systemie Linux ładuje libGL.so w środowisku wykonawczym za pomocą interfejsu API dlopen, zamiast dynamicznie łączyć się z nim.

Dlaczego to robią?

Jedyny powód, jaki mogę sobie wyobrazić, to fakt, że każdy sprzedawca sterowników graficznych oferuje inny libGL, a dwa różne libGL mogą być niezgodne z ABI. (No cóż, dlaczego mieliby być niekompatybilni z ABI? A nawet gdyby tak było, to dlaczego ładowanie ich przez dlopen rozwiązałoby ten problem?)

W każdym razie, zakładając, że istnieje ku temu dobry powód, chciałbym to zrobić to również. Czy ktoś ma link do kodu źródłowego C/C++, który ładuje wszystkie funkcje OpenGL przez dlopen, które mogę dołączyć do mojego projektu bez potrzeby wprowadzania zbyt wielu poprawek?

Answer 1

Istnieją dwa główne powody, ludzie to zrobić:

1. Można dać sensowny błąd w systemach, które nie mają OpenGL
2. Sprzedawcy oferują wiele różnych rozszerzeń i jedyny rozsądny sposób na wsparcie wielu zestawów rozszerzeń bez różnych plików binarnych na dostawcę jest użycie dlsym do ich sprawdzenia. GLEW oferuje dobry sposób robienia tego za Ciebie.

Answer 2

Jest to więc nie musisz się statycznie odwołuje się do realizacji GL, na przykład, jeśli Twój kod wykorzystuje glBindFragDataLocation, który jest dostępny na OpenGL 3.0 i nowsze, to nie działać z tajemniczym łącznikiem błąd w OpenGL 2.1 i wcześniejszych implementacjach.

Uzyskiwanie punktów wejściowych dynamicznie pozwala wybrać odpowiednią ścieżkę renderowania w środowisku wykonawczym.

Jest również wymagane w systemie Windows do obsługi funkcji GL> 1.1.

GLEW robi to za ciebie, nie pobiera biblioteki libGL, używa adresu glXGetProcAddress/wglGetProcAddress/aglGetProcAddress, aby uzyskać wskaźniki funkcji GL ze sterownika, i jest to platforma wieloplatformowa.