Вопросы по динамическим библиотекам

Evg · Регистрация: 30.03.2009

Студворк — интернет-сервис помощи студентам

Сообщение от niXman

можешь пояснить более популярно чем в куче манов, что конкретно выполняет флаг -fPIC при либковке .so файла?

Флаг -fPIC - это компиляция позиционно-независимого кода. Только из таких кодов можно сделать динамическую библиотеку с разделяемыми кодами. Если компилировать модули без -fPIC и потом собрать *.so, то формально у тебя динамическая библиотека получится, но код будет не разделяемым. Для каждого процесса, использующего этот модуль, будет создаваться копия кодов. Флаг -fPIC нужен для компиляции из исходника в объектник, для линковки не нужен. "Нормальный" процесс выглядит так:

Code
1
2
3
4
$ gcc t1.c -c -fPIC
$ gcc t2.c -c -fPIC
$ gcc t3.c -c -fPIC
$ gcc -shared t1.o t2.o t2.o -o libqqq.so

@niXman · 10.03.2011, 18:59

Сообщение от Evg

Для каждого процесса, использующего этот модуль, будет создаваться копия кодов.

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

g_u_e_s_t · 10.03.2011, 19:02

Добавлено через 2 минуты

Сообщение от niXman

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

Вы смешиваете в одну кучу PIC и COW

@niXman · 10.03.2011, 19:09

Evg, в этом мане, в главе 3.4, написано такое:

Using -fpic option usually generates smaller and faster code, but will have platform-dependent limitations, such as the number of globally visible symbols or the size of the code. The linker will tell you whether it fits when you create the shared library. When in doubt, I choose -fPIC, because it always works.

т.е. если моя библиотека не превышает какого-то размера, то мне все же логичнее использовать влаг -fpic ?

Добавлено через 2 минуты

Сообщение от g_u_e_s_t

COW

это что? ненашел таких опций компилятора/линкера.

g_u_e_s_t · 10.03.2011, 19:14

Сообщение от niXman

это что? ненашел таких опций компилятора/линкера.

это не опция) это Copy-on-Write. тобишь как только ваша программа испортит хоть байт данных в адресном пространстве библиотеки система выдаст вам индивидуальную копию этой страницы памяти. Собственно с PIC/Relocated code это никак не связанно

Там речь не о ограничениях на размер кода, а об аппаратных платформах (в основном антикварных) где PIC не возможен

Evg · 10.03.2011, 19:15 **[ТС]**

Сообщение от niXman

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

Да. И не только через dlopen. По умолчанию любая программа линкуется с динамическими библиотеками. Если ты компиляешь hello world, то он слинкуется с динамической libc.so. В виртуальной памяти какждого процесса, использующего динамическую библиотеку, имеется как бы своя копия (загруженная по разным виртуальным адресам), но в физической памяти находится один экземпляр билиотеки, а виртуальная память каждого из процессов отмапирована на одну и ту же физическую.

Разделяемым является только код (исполняемые фрагменты) и read-only данные (последнее зависит от компилятора). Read-write данные, понятное дело, в каждом процессе имеют свою копию. Любая среднестатистическая библиотека содержит глобальных данных на порядки меньше, чем кода, а потому за счёт дублирования данных потери памяти не такие уж и большие.

Когда ты генерируешь код через -fPIC, то все обращения к глобальным переменным строятся по косвенности. Грубо говоря, в каждом процессе в начале процедуры формируется некое значение, а все обращения к глобальным переменным делаются косвенными - через специальную табличку (которая является данными), в которой прописаны адреса всех глобальных переменных. Такой подход обеспечивает то, что код (исполняемые фрагменты) не содержат настройки на абсолютные адреса, а потому может свободно разделяться между процессами (ибо везде он побайтно совпадает). А если *.so собирать из модулей, собранных без -fPIC'а, то в таком коде будут настройки на абсолютные адреса (которые в разных процессах могут не совпадать) и потому такой код нельзя сделать разделяемым

Сообщение от niXman

и какое влияние на это оказывают флаги RTLD_GLOBAL и RTLD_LOCAL ?

Понятие global/local они разными в зависимости от контекста. Говоря о языке программирования, словом global называют переменную со статическим временем жизни (т.е. живёт всю программу), а local - переменную с автоматическим временем жизни (живёт внутри активации процедуры). Говоря о бинарном формате файла, global - означает метку, видимую из других модулей, а local - метку , не видимую из остальных модулей. Грубо говоря, global для бинарного формата соответствует global'у языка Си без модификатора static, а local бинарного формата - global'у языка Си с модификатором static

@niXman · 10.03.2011, 22:25

Добавлено через 3 часа 7 минут
Evg, скажи, а компилятор/линкер в .so файле не сохраняют версию компилятора/линкера/libc/libstdc++, которые использовались для линковки этой so`шки ?
каким-то образом эту информацию можно получить? или только предварительно сохранив?

Evg · 11.03.2011, 09:16 **[ТС]**

Версия компилятора и линкера никак не должна отражаться в бинарнике. Но компилятор может в коде создавать специфическую метку. gcc-2.95, например, в каждом объектнике создавал метку с именем что-то типа ".gcc2_compiled". Более поздние версии gcc при генерации ассемблерного файла пишут строку что-то типа ".ident gcc: <версия>", а куда оно попадает дальше в объектном файле - с ходу не знаю. Наверняка и у линкера есть подобные подпольные приблуды. Но все они носят чисто отладочный характер - т.е. чтобы глазками на них посмотреть и не должны ни к чему обязывать. Хотя где-то в коде линкера под какую-то архитектуру я видел затычки, что при наличии метки ".gcc2_compiled" линкер понимал, что код сгенерил gcc и обходил какую-то ошибку компилятора.

Касаемо версии динамической библиотеки тут немного сложнее. В стандарте elf в заголовке секции можно вклеить так называемые dynamic tags - какие-то вопсомогательные фичи, которые используются при динамической загрузке файла (*.so или исполняемого). Часть этих тэгов является стандартной (т.е. их поведение в спецификации elf'а записано), а часть - implementation defined.

Code
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
$ readelf -d /lib/libc-2.11.1.so 
 
Dynamic section at offset 0x143d7c contains 26 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [ld-linux.so.2]
 0x0000000e (SONAME)                     Library soname: [libc.so.6]
 0x0000000c (INIT)                       0x16a30
 0x0000001a (FINI_ARRAY)                 0x1431c8
 0x0000001c (FINI_ARRAYSZ)               4 (bytes)
 0x00000004 (HASH)                       0x13e604
 0x6ffffef5 (GNU_HASH)                   0x1b8
 0x00000005 (STRTAB)                     0xceb0
 0x00000006 (SYMTAB)                     0x3db0
 0x0000000a (STRSZ)                      23085 (bytes)
 0x0000000b (SYMENT)                     16 (bytes)
 0x00000003 (PLTGOT)                     0x144ff4
 0x00000002 (PLTRELSZ)                   64 (bytes)
 0x00000014 (PLTREL)                     REL
 0x00000017 (JMPREL)                     0x168d0
 0x00000011 (REL)                        0x13ed0
 0x00000012 (RELSZ)                      10752 (bytes)
 0x00000013 (RELENT)                     8 (bytes)
 0x6ffffffc (VERDEF)                     0x13b00
 0x6ffffffd (VERDEFNUM)                  26
 0x0000001e (FLAGS)                      STATIC_TLS
 0x6ffffffe (VERNEED)                    0x13e90
 0x6fffffff (VERNEEDNUM)                 1
 0x6ffffff0 (VERSYM)                     0x128de
 0x6ffffffa (RELCOUNT)                   1250
 0x00000000 (NULL)                       0x0

Всё, что с большими номерами - это implementation defined. Среди этого списка есть SONAME - так называемый идентификатор динамической библиотеки. Когда мы теперь линкуем бинарник с такой динамической библиотекой, то в бинарнике появляются тэги NEEDED, в которых записаны значения полей SONAME тех динамических библиотек, которые участвовали в линковке (но в бинарник, ясным образом, не вклеивались)

Code
1
2
3
4
5
6
$ gcc t.c -lm
$ $ readelf -d a.out
...
 0x00000001 (NEEDED)                     Shared library: [libm.so.6]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
...

Таким образом, хотя бинарник и отвязан от динамических библиотек, но тем не менее имеются зацепки на предмет того, которая из версий нужна. Если я ничего не путаю, то поле NEEDED трактуется как имя файла (хотя формируется на основании поля SONAME).

Если посмотреть, какие из файлов присутсвуют в файловой системе (в каталогах /lib и /usr/lib), то можно увидеть 3 файла для glibc. В моём случае имеются:

Code
1
2
3
/lib/libc-2.11.1.so
/lib/libc.so.6: символьная ссылка на libc-2.11.1.so 
/usr/lib/libc.so: типа скрипт, содержащий /lib/libc.so.6

Файл libc-2.11.1.so представляет собой сами коды библиотеки и под таким именем нигде не используется (ни при линковке, ни при динамической загрузке). Файл libc.so используется только при линковке. То, что он скрипт, это некая особенность именно glibc, но условно можно считать, что это символьная ссылка на libc.so.6 (но не libc-2.11.1.so). Файл для линковки содержит только имя (libc.so) без каких-бы то ни было номеров версий, потому как компилятор подаёт в линкер опцию -lc, дабы не привязываться ни к каким номерам версий. В момент исполнения загружается файл libc.so.6 на основании поля NEEDED.

Для чего нужна такая наносистема. Допустим, на машине установили более позднюю версию glibc, принципиально отличающуюся интерфейсами (и, стало быть, имеющие бинарную НЕсовместимость со старой glibc). При таком раскладе все свежескомпилированные программы должны настраиваться на новую версию glibc, однако старые бинарники должны работать со старой версией glibc, потому как с новой они не смогут работать. В этом случае файлы будут такими (новые и изменённые помечаю звёздочкой):

Code
1
2
3
4
5
  /lib/libc-2.11.1.so
* /lib/libc-2.18.1.so
  /lib/libc.so.6: символьная ссылка на libc-2.11.1.so 
* /lib/libc.so.7: символьная ссылка на libc-2.18.1.so
* /usr/lib/libc.so: типа скрипт, содержащий /lib/libc.so.7

Таким образом при компиляции свежих программ будет использоваться файл libc-2.18.1.so через ссылку libc.so.7 и скрипт libc.so. В поле NEEDED у бинарника скопируется SONAME со значением libc.so.7, а потому на исполнении будет подцепляться libc.so.7 (который указывает на libc.2.18.1). А старые бинарники по прежнему при исполнении будут загружать старую lib.so.6

При таком объяснении на первый взгляд кажется, что схема из трёх файлов избыточная и достаточно двух. Т.е. казалось бы, что вполне достаточно иметь файлы (а не ссылки) libc.so.6 и libc.so.7. Но на самом деле эти указанные файлы олицетворяют собой версию интерфейса (а не библиотеки). Т.е. может выйти библиотека libc-2.11.5.so (т.е. изменение минорной цифры версии) или libc-2.13.1.so (изменение второй цифры версии, но при этом коды остаются бинарно совместимыми). В этом случае копируется файл libc-2.13.1.so и перенастраивается существующая ссылка libc.so.6, после чего старые программы начинают работать с новой библиотекой (потому что новая бинарно совместима со старой), а не со старой, как в предыдущем примере

Добавлено через 7 минут

Сообщение от niXman

Evg, в этом мане, в главе 3.4, написано такое:

т.е. если моя библиотека не превышает какого-то размера, то мне все же логичнее использовать влаг -fpic ?

Вчера забыл ответить на вопрос. Есть две опции -fpic и -fPIC. Для большинства архитектур они делают одно и то же. Но некоторые архитектуры позволяют "укороченные" варианты косвенного доступа. Что-то из разряда того, что если расстояние между сегментами кода и данных не превышает 64 килобайта, то вместо 32-битного относительного смещения можно использовать 16-битное, что может укоротить (и, соответсвенно, ускорить) исполнение кода. В этом случае можно использовать опцию -fpic (маленькие буквы олицетворяют укороченный вариант). Но если при дальнейшем формировании динамической библиотеки постфактум окажется, что в эти ограничения не уложились, то линкер выдаст ошибку. И надо будет пересобрать всё с опцией -fPIC (в этом случае всё будет работать без ограничений). Что-то из разряда того. Я точно знаю, что сия фича используется на sparc'е и дико подозреваю, что возможно использовать на i386.

Реальное убыстрение ты заметишь только тогда, когда есть обращение к глобальной переменной в цикле с большим количеством итераций. А при "обычном" доступе к глобалу вне цикла этого не почувствовать: т.е. ускорение в 2 такта для кода длиной в 10000 тактов - это экономия на спичках. Лучше пользуйся -fPIC'ом - меньше проблем будет

g_u_e_s_t · 11.03.2011, 10:42

Evg, Спасибо, подробно и интересно.

Если я ничего не путаю, то поле NEEDED трактуется как имя файла (хотя формируется на основании поля SONAME).

Т.е. для каждой DT_NEEDED записи должна быть своя запись DT_SONAME?
Из прочитанного мной когда-то описания ELF-формата это не очевидно, но если это так, то зачем такой дубль?
И еще я бы все таки добавил, что возможность слинковать программу с конкретной версией библиотеки есть. В смысле DT_SONAME вполне может содержать и полную версию, или как вариант есть возможность подсунуть библиотеку не из /usr/lib через DT_RPATH (ключик rpath у линкера)

Evg · 11.03.2011, 13:18 **[ТС]**

Сообщение от g_u_e_s_t

Т.е. для каждой DT_NEEDED записи должна быть своя запись DT_SONAME?Из прочитанного мной когда-то описания ELF-формата это не очевидно, но если это так, то зачем такой дубль?

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

Сообщение от g_u_e_s_t

И еще я бы все таки добавил, что возможность слинковать программу с конкретной версией библиотеки есть. В смысле DT_SONAME вполне может содержать и полную версию, или как вариант есть возможность подсунуть библиотеку не из /usr/lib через DT_RPATH (ключик rpath у линкера)

3 раза прочитал мысль но ничегоне понял. Никто не говорит про физическую невозможность слинковать что-то с чем-то. Способов совместить несовместимое - миллион. Только работать оно не будет. А вся эта магия с NEEDED и SONAME по большому счёту нужна только ради того, чтобы сразу же было понятно, что есть два несовместимых бинарника (напиример, a.out и libc.so). Чтобы это было понятно на этапе линковки или загрузки, а не на этапе исполнения, когда-то программа на ровном месте ломается и причины совершенно непонятны

g_u_e_s_t · 11.03.2011, 14:33

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

А вы уверенны???
Это не совсем линукс но вполне честный ELF:

Code
1
2
puffy:~$ for f in /usr/lib/*; do readelf -d $f 2>/dev/null; done|grep SONAME
puffy:~$

Т.е. записи типа DT_SONAME отсутсвуют как класс - кругом DN_NEEDED.
Система (это netbsd) при этом умеет ругаться на не ту версию .so.

Если я вас не так понял, то поясните пожалуйста подробнее, ну или ссылку (предпочтительнее) на первоисточник инфы.

Добавлено через 25 минут

Сообщение от Evg

3 раза прочитал мысль но ничегоне понял. Никто не говорит про физическую невозможность слинковать что-то с чем-то

B посте №22 вы, как мне показалось (возможно ошибочно) особо подчеркнули тот факт, что в SONAME не указанна конкретная версия требуемой библиотеки.
Совмещать, что-то с чем-то и не надо, а вот возможность линковать с конкретной версией бывает нужна.

А вся эта магия с NEEDED и SONAME по большому счёту нужна только ради того, чтобы сразу же было понятно, что есть два несовместимых бинарника (напиример, a.out и libc.so).

Я б сказал чуть иначе. Это не магия, а способ указания системе в лице ld.so мест где искать требуемые программе символы.

Evg · 11.03.2011, 14:56 **[ТС]**

Сообщение от g_u_e_s_t

А вы уверенны???

Уверен. По твоей строке у меня выдаётся портянка на несколько экранов. Если SONAME нет, то линкер в качестве этого SONAME использует имя файла. Оно нужно тогда, когда файл, например, называется libc-2.11.1.so, но при этом SONAME=libc.so.6

Сообщение от g_u_e_s_t

ну или ссылку (предпочтительнее) на первоисточник инфы

Ссылку не знаю. Просто я работал с этим в своё время

Сообщение от g_u_e_s_t

что в SONAME не указанна конкретная версия требуемой библиотеки

В SONAME можно писать что угодно. Но пишут обычно номер версии. Причём не версии библиотеки, а версии некоторого программного соглашения. Две разные версии библиотеки могут иметь один и тот же SONAME: они имеют один и тот же набор интерфейсов, просто реализованы по разному.

Как правило более поздня библиотека имеет более широкий набор интерфейсов, но бинарно совместим с более ранней библиотекой. В этом случае у них одинаковый SONAME. И типичный случай - это когда прямая совместимость (от ранней версии к поздней) есть, а обратной (от поздней версии к ранней) - нет. При таком раскладе можно бинарник скомпилировать с более поздней версией библиотеки, а потом попробовать запустить с более ранней. Такие случаи рулятся немного по другому - версии приклеиваются ещё и к меткам (именам функций или переменных). Выглядит оно типа того:

Code
1
2
$ readelf --symbol /lib/libc.so.6 | grep -w printf
   603: 000477a0    56 FUNC    GLOBAL DEFAULT   11 printf@@GLIBC_2.0

Запуском

Code
1
$ readelf -V /lib/libc.so.6

можно увидеть длинную портянку. Детальный смысл портянки я не знаю. Но суть в следующем. Допустим, в printf внесли ещё како-нибудь спецификатор (какой-нибудь %y, например). В этом случае совместимость со старой версией остаётся - старые коды с новым printf'ом будут работать. Но вот новые коды со старым printf'ом могут и не работать, если они используют %y. В этом случае в новой версии библиотеки лепится символ printf и приклеивается в нему версия типа "@@GLIBC_2.0.1". В этоге если новый код, скомпиленный с новой библиотекой, запустить со старой, то динамический загрузчик выругается на несоответсвие версий. Но если новый код printf не использует, то со старой библиотекой он сможет работать. Реально используется немного не так, но для объяснения "на пальцах" сойдёт.

Добавлено через 36 секунд

Сообщение от g_u_e_s_t

Я б сказал чуть иначе. Это не магия, а способ указания системе в лице ld.so мест где искать требуемые программе символы

Нет. ГДЕ искать - за это отвечает RPATH, а NEEDED отвечает за то, ЧТО искать

g_u_e_s_t · 11.03.2011, 15:19

Честно говоря, вы меня совсем запутали...
Выше в посте 22 вы пишете:

SONAME записывается динамической библиотеке. NEEDED, грубо говоря, записывается в исполняемом файле, требующем эту динамическую библиотеку.

Я удивляюсь, и показываю вам систему где это вовсе не обязательно: SONAME ни в exe ни в .so не присутствует. (Или вы скажите что там ELF кривой и надо бежать писать багрепорт?)
Т.е. NEEDED без SONAME возможно и работает. А наоборот SONAME без NEEDED возможно?

опус про совместимость чего-то с чем-то поскипан

Нет. ГДЕ искать - за это отвечает RPATH, а NEEDED отвечает за то, ЧТО искать

Да верно, за исключением случаев когда в NEEDED/SONAME есть слэш, тогда RPATH, LD_LIBRARY_PATH и прочие должны игнорироваться.

Evg · 11.03.2011, 16:41 **[ТС]**

NEEDED в момент загрузки говорит о том, какие библиотеки нужны (ибо как по другому понять, что требуется, к примеру libm.so). Список этих NEEDED формируется в момент линковки (линкеру явно задаются все библиотеки, с которыми вдальнейшем на исполнении должна линковаться программа). В качестве этих NEEDED пишется то, что записано в SONAME подаваемой библиотеки. Если SONAME нет, то прописывается имя файла подаваемой библиотеки

g_u_e_s_t · 11.03.2011, 16:58

В качестве этих NEEDED пишется то, что записано в SONAME подаваемой библиотеки. Если SONAME нет, то прописывается имя файла подаваемой библиотеки

О теперь более-менее ясно)
А каким ключиком линкера задать желаемый SONAME при линковке свой .so'шки?
UP: сам нашел -soname как ни странно)

Evg · 11.03.2011, 17:14 **[ТС]**

Сообщение от g_u_e_s_t

UP: сам нашел -soname как ни странно)

Да, но реально, как правило ручками запускается компилятор, а он уже запускает линкер. Из-под gcc эта опция выглядит как "-Wl,-soname=qqq". Для контроля подаётся дополнительно -v и глазками наблюдается, что опция передалась линкеру

@niXman · 12.03.2011, 14:10

такой мануальчик нарыл: http://www.akkadia.org/drepper/dsohowto.pdf
очень много инфы по созданию .so

Evg · 12.03.2011, 14:28 **[ТС]**

Что-то документ не скачивается. Может его приаттачить сюда?

@niXman · 12.03.2011, 14:31

Сообщение от Evg

Может его приаттачить сюда?

легко

Evg · 12.03.2011, 14:46 **[ТС]**

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

Новые блоги и статьи Все статьи Все блоги /
PhpStorm 2025.3: WSL Terminal всегда стартует в ~ and_y87 14.12.2025 PhpStorm 2025. 3: WSL Terminal всегда стартует в ~ (home), игнорируя директорию проекта Симптом: После обновления до PhpStorm 2025. 3 встроенный терминал WSL открывается в домашней директории. . .	Access VikBal 11.12.2025 Помогите пожалуйста !! Как объединить 2 одинаковые БД Access с разными данными.	Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro	Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .
Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .	Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .	Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .	Мысли в слух kumehtar 18.11.2025 Кстати, совсем недавно имел разговор на тему медитаций с людьми. И обнаружил, что они вообще не понимают что такое медитация и зачем она нужна. Самые базовые вещи. Для них это - когда просто люди. . .	Создание Single Page Application на фреймах krapotkin 16.11.2025 Статья исключительно для начинающих. Подходы оригинальностью не блещут. В век Веб все очень привыкли к дизайну Single-Page-Application . Быстренько разберем подход "на фреймах". Мы делаем одну. . .

@niXman 3211 / 1459 / 74 Регистрация: 09.08.2009 Сообщений: 3,441 Записей в блоге: 2
	10.03.2011, 22:25
	Добавлено через 3 часа 7 минут Evg, скажи, а компилятор/линкер в .so файле не сохраняют версию компилятора/линкера/libc/libstdc++, которые использовались для линковки этой so`шки ? каким-то образом эту информацию можно получить? или только предварительно сохранив? 0

Evg 21281 / 8305 / 637 Регистрация: 30.03.2009 Сообщений: 22,660 Записей в блоге: 30
	11.03.2011, 16:41 [ТС]
	NEEDED в момент загрузки говорит о том, какие библиотеки нужны (ибо как по другому понять, что требуется, к примеру libm.so). Список этих NEEDED формируется в момент линковки (линкеру явно задаются все библиотеки, с которыми вдальнейшем на исполнении должна линковаться программа). В качестве этих NEEDED пишется то, что записано в SONAME подаваемой библиотеки. Если SONAME нет, то прописывается имя файла подаваемой библиотеки 0

@niXman 3211 / 1459 / 74 Регистрация: 09.08.2009 Сообщений: 3,441 Записей в блоге: 2
	12.03.2011, 14:10
	такой мануальчик нарыл: http://www.akkadia.org/drepper/dsohowto.pdf очень много инфы по созданию .so 1

Evg 21281 / 8305 / 637 Регистрация: 30.03.2009 Сообщений: 22,660 Записей в блоге: 30
	12.03.2011, 14:28 [ТС]
	Что-то документ не скачивается. Может его приаттачить сюда? 0

Evg 21281 / 8305 / 637 Регистрация: 30.03.2009 Сообщений: 22,660 Записей в блоге: 30
	12.03.2011, 14:46 [ТС]
	Уж очень специфичный документ. Начинающий его не осилит. Это скорее техническая спецификация, чем мануал по созданию динамических объектов 0

Вопросы по динамическим библиотекам

Решение