Ленивое связывание shared library?

я вижу lGl.

Я тоже вижу, и? Почему ее нет в NEED?

Почему ее нет в NEED?

Просто забыли. Библиотеки же собираются и с отсутствующими символами. Если не озаботиться шагом сборки, который проверяет, что библиотека сама по себе загружаемая, будут вот такие проколы.

Возможно это проприетарный шлачок который якобы можно использовать с разными версиями libGL.

А LDFLAGS += -Wl,--as-needed не мог привести к такому побочному эффекту? В Дебиане кое-где отключают.

не мог привести к такому побочному эффекту?

В man'е написано, что именно в этом и есть его эффект.

Если glVertexPointer(),.. слабые символы, да. Но я в приведенном выводе не вижу «w».

Не обязательно слабые. Достаточно, чтобы libGL в параметрах ld шла перед объектником, использующим её символы. Ld радостно выбросит libGL, и не вернёт её обратно. Что ушло, то ушло.

Пока не вижу, где же это сказано.

--as-needed --no-as-needed

This option affects ELF DT_NEEDED tags for dynamic libraries mentioned on the command line after the --as-needed option. Normally the linker will add a DT_NEEDED tag for each dynamic library mentioned on the command line, regardless of whether the library is actually needed or not. --as-needed causes a DT_NEEDED tag to only be emitted for a library that at that point in the link satisfies a non-weak undefined symbol reference from a regular object file or, if the library is not found in the DT_NEEDED lists of other needed libraries, a non-weak undefined symbol reference from another needed dynamic library. Object files or libraries appearing on the command line after the library in question do not affect whether the library is seen as needed. This is similar to the rules for extraction of object files from archives. --no-as-needed restores the default behaviour.

«that at that point in the link satisfies» - вот это я не распарсил.

ленивое связывание - это просто заглушка вместо внешней функции, которая при первом вызове заглушки будет динамически грузить библиотеку и заменять адреса заглушки на адрес функции в библиотеке.
Рекомендуется и применяется в случае редко вызываемой функции, но абсолютно ненужно для системных или часто вызываемых библиотек.

Пример - графический просмотрщик с поддержкой нескольких форматов. Есть смысл редко используемые форматы декодировать через ленивое связывание.

походу перевод ответов первых ссылок из гугла на СО по запросу «лд лейзи биндинг», очередной пример как секундный гуглеж делает из рандомного лоровца эксперта по сравнению с вопрошающей дичью.

«that at that point in the link satisfies» - вот это я не распарсил.

ld обрабатывает параметры слева направо. Начинает с пустого множества, потом перебирает параметры. Видит объектник — линкует его к тому, что есть. Видит разделяемую библиотеку — указывает её в зависимостях. Обратно не возвращается, так как это увеличит сложность до O(N^2).

С as-needed на этапе обработки разделяемой библиотеки ld проверяет, удовлетворяет ли она какие-то символы в текущем рабочем объекте. Если да — оставляет, если нет — пропускает. С as-needed порядок стал важен.

Рекомендуется и применяется в случае редко вызываемой функции, но абсолютно ненужно для системных или часто вызываемых библиотек.

Так оно же по дефолту сейчас для всех функций.

Рекомендуется и применяется в случае редко вызываемой функции, но абсолютно ненужно для системных или часто вызываемых библиотек.

Так оно же по дефолту сейчас для всех функций.

тормоза по дефолту значит будут...

тормоза по дефолту значит будут...

Почему?

В одном варианте адреса функций проставляются во время запуска. Во втором варианте адреса функций проставляются заглушкой во время первого вызова. В случае использования общее время то же, но запуск быстрее. В случае, когда вызовов функций из библиотеки не было вообще, дополнительное время не тратится, запуск быстрее.

Я не ыксперд, но, насколько я понимаю, разработчики musl считают, что ленивое связывание is overrated и ненужно. В их лоадере его нет. На время запуска вроде не жалуются.

добавляется дополнительное время на переадресацию функций, хотя для нынешней аппаратуры это совсем не критично. Но как говорится «курочка по зернышку клюет». Иначе, за чем бы городили костыли: prelink, статической линковки библиотек, SSD в конце концов.

Есть в NEED, но в то же время UND

$ objdump -TC lib/x86/libAndroidGame.so  | grep glEnableVertexAttribArray
00000000      DF *UND*  00000000 glEnableVertexAttribArray
$ objdump -x lib/x86/libAndroidGame.so  | grep NEED
  NEEDED               libopenal.so
  NEEDED               liblog.so
  NEEDED               libEGL.so
  NEEDED               libandroid.so
  NEEDED               libGLESv2.so
  NEEDED               libstdc++.so
  NEEDED               libm.so
  NEEDED               libc.so
  NEEDED               libdl.so
$ grep glEnableVertexAttribArray /usr/include/GLES2/*                     
/usr/include/GLES2/gl2.h:GL_APICALL void GL_APIENTRY glEnableVertexAttribArray (GLuint index);