OpenGL в Linux: dlopen libGL.so

Question

Большинство приложений (и библиотек), использующих OpenGL в Linux, загружают libGL.so во время выполнения, используя dlopen API, вместо динамического связывания с ним.

Почему они это делают?

Единственная причина, которую я могу себе представить, заключается в том, что любой поставщик графического драйвера предоставляет другой libGL, а два разных libGL могут быть несовместимы с ABI. (Ну, гм, почему они должны быть несовместимы с ABI? И даже если они есть, почему загрузка их через dlopen решит эту проблему?)

В любом случае, предположив, что для этого есть веская причина, я бы тоже хотел это сделать. У кого-нибудь есть ссылка на код C / C ++ с открытым исходным кодом, который загружает все функции OpenGL через dlopen, который я могу включить в свой проект, не требуя слишком много настроек?

Answer 1

Это сделано для того, чтобы вам не приходилось статически ссылаться на реализацию GL, например, если ваш код использует glBindFragDataLocation, который доступен в OpenGL 3.0 и новее, он не сможет работать с загадочной ошибкой компоновщика в OpenGL 2.1 и более ранние реализации.

Таким образом, динамическое получение точек входа позволяет вам выбрать путь рендеринга apropiate во время выполнения.

Кроме того, это требуется в Windows для функций GL> 1.1.

GLEW делает это для вас, он не использует libGL, он использует glXGetProcAddress / wglGetProcAddress / aglGetProcAddress для получения указателей на функции GL из драйвера, и он кроссплатформенный.

Answer 2

Есть две основные причины, по которым люди делают это:

1. Вы можете выдать ощутимую ошибку для систем, в которых нет OpenGL
2. Поставщики предлагают множество различных расширений, и единственный разумный способ поддержки нескольких наборов расширений без разных двоичных файлов для каждого поставщика - использовать для их проверки dlsym. GLEW предлагает хороший способ сделать это для вас.