Библиотеки Linux/Win

2. Исполняемый файл присоединяется к адресному пространству процесса (mmap), так что никакие функции не выбираются.

3. Потому что extern - это к раздельной компиляции нескольких файлов, а не экспорт/импорт имён из разделяемой библиотеки. Аналог def-файлов для не-Windows систем - это атрибут visibility, поддерживаемый gcc. См. тут.

Доброго времени суток!

Где-то я это уже видел...

Да, я не меняюсь:)

спасибо. то, что надо!

2. А по скорости динамическая загрузка библиотек от линковки с этой библиотекой сильно отличается для linux/win систем?

Вот тебе одно из самых серьезных различий: под виндой разделяемые библиотеки не должны иметь неопределенных символов.

способ через extern

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

У меня тоже вопрос: а зачем это обсуждать, зачем пипирками мериться? Есть ли практическая польза от подобных сведений?

Ну мне интересно узнать, как оно внутри работает.

1) В чем отличие функций LoadLibrary+GetProcAddress от аналогичной dlopen+dlsym, кроме названия?

Если не учитывать различия в работе dynamic linker-а под разными системами, то эти пары функций семантически эквивалентны.

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

Библиотека грузится целиком через механизм memory mapped files, если ещё не была загружена.

3) .def-файлы под MSVS - это что за костыль и почему не понравился мелкомягким способ через extern?

extern недостаточно. Под вендой любой символ всегда определяется в рамках какого-то модуля, соответственно нужно как-то сопоставить сишное имя символа и пару (имя модуля, имя символа в модуле).

Нельзя загрузить из библиотеки только нужные функции, потому что не известно, как у неё внутри код устроен. Он может использовать явно или не очень другие части библиотеки, которые тоже необходимо загрузить. К тому же позиционнонезависимый код, как и релокации работают только в рамках секций. То есть ни в PE, ни в ELF недостаточно информации для того, чтобы вырезать кусок из секции. Секции можно перемещать только целиком.

def-файлы нужны, потому что в Windows каждая функция грузится из конкретной библиотеки. В Linux же есть только список библиотек, которые надо подгрузить, а пространство имён общее на все библиотеки. Это позволяет делать вкусные штуки типа подмены системных функций штатными средствами (используется всякими отладчиками) без костылей.

Есть альтернатива def-файлам. Например, в Pascal имеется синтаксическая конструкция, позволяющая указать, из какой библиотеки надо взять функцию, при описании прототипа.

Докину ещё про загрузку только необходимых функций. Как уже сказали выше, нельзя загрузить только необходимые функции, ибо неизвестно, как внутри устроена библиотека. Зато можно загрузить только необходимые библиотеки, если какие-то из прилинкованных библиотек вдруг оказались не нужны.

Динамическая линковка в целом работает как-то так: в ассемблерном коде вместо call f происходит call [linked_f], где f - это имя функции, а linked_f - ячейка памяти, куда линкер положит известный только ему адрес загруженной функции f. Если библиотека уже загружена, в linked_f лежит адрес загруженной функции. Если же нет, там лежит адрес некоторой «заглушки», которая вызывает линкер с нужными аргументами, и в итоге происходит загрузка нужной библиотеки. В реальности всё происходит чуть-чуть по-другому, но общая суть та же.

Таким образом, если ни одна функция из библиотеки не была ни разу вызвана, то и библиотека не загрузится. Это иногда даёт выигрыш, например, если загружаемые библиотеки весьма жирные, а программа по каким-то причинам завершилась очень быстро (например, ей передали некорректные аргументы при запуске, и она сразу определила это и завершилась с ошибкой). Но в целом это практически ничего не ускоряет.

Это я всё про линукс, если что. Не знаю, как оно там под виндой.

Linkers&Loaders by John R. Levine

Лет 10 назад .DEF-файл был нужен лишь в паре случаев:

• когда пишешь DLL и хочешь избавиться от декорирования имен (_foo@8) - например, если эта DLL будет использоваться не из C-программ.
• когда пишешь DLL и хочешь экспортировать функции только по ординалам, а не по именам (использовалось всякими кулхацкерами).

В остальных случаях __declspec(dllimport), __declspec(dllexport) - .DEF-файл не нужен.