OpenGL на Linux: dlopen libGL.so

Question

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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