Ядро Linux было создано под впечатлением от операционной системы MINIX, которая не устраивала Линуса своей ограниченной лицензией.

Ядро 0.0.1 имело размер 62 Кб в сжатом виде и содержало около 10 тысяч строк исходного кода. Кодовая база последних версий насчитывает более 30 млн строк.

По данным исследования, проведённого в 2010 году по заказу Евросоюза, приблизительная стоимость разработки с нуля проекта, аналогичного современному ядру Linux, составила бы более миллиарда долларов США.

Динамика роста кодовой базы ядра Linux:

0.0.1 - сентябрь 1991, 10 тыс. строк;
1.0.0 - март 1994, 176 тыс. строк;
1.2.0 - март 1995, 311 тыс. строк;
2.0.0 - июнь 1996, 778 тыс. строк;
2.2.0 - январь 1999, 1.8 млн. строк;
2.4.0 - январь 2001, 3.4 млн. строк;
2.6.0 - декабрь 2003, 5.9 млн. строк;
2.6.28 - декабрь 2008, 10.2 млн. строк;
2.6.35 - август 2010, 13.4 млн. строк;
3.0 - август 2011, 14.6 млн. строк.
3.5 - июль 2012, 15.5 млн. строк.
3.10 - июль 2013, 15.8 млн. строк;
3.16 - август 2014, 17.5 млн. строк;
4.1 - июнь 2015, 19.5 млн. строк;
4.7 - июль 2016, 21.7 млн. строк;
4.12 - июль 2017, 24.1 млн. строк;
4.18 - август 2018, 25.3 млн. строк;
5.2 - июль 2019, 26.55 млн. строк;
5.8 - август 2020, 28.4 млн. строк;
5.13 - июнь 2021, 29.2 млн. строк;
5.19 - август 2022, 30.5 млн. строк;

Версионирование разделяемых библиотек:

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

В Linux у вас может быть несколько версий одной и той же библиотеки. Следование правилам версионирования и компановки позволяет сохранить работоспособность программ при обновлениях, которые нарушают совместимость (добавление дополнительного параметра в публичный метод: подробнее можно ознакомиться здесь).

Корректно спроектированная динамическая библиотека должна состоять из 3 имен:

1. Реальное имя - название самой библиотеки “lib<name>.so.<major>.<minor>.<patch>”. Напрямую при линковке не используется (разве что для дебага).

Major - меняется в случае, когда правки приводят к несовместимости с приложениями (изменение API).
Minor - меняется при расширении API (добавлении функционала).
Patch - багфиксы, оптимизации (изменение функционала внутри готового API).

2. SONAME - метка, которая записывается в файл библиотеки на этапе создания (DT_SONAME в терминологии формата ELF). Именно она встраивается статическим компоновщиком в программу и, как следствие, используется динамическим компоновщиком для поиска на этапе выполнения. Структура, обычно, следующая “lib<library name>.so.<major>”.

/* Создаем libdemo.so.1.0.0 с меткой libdemo.so.1 */
$ gcc -shared -Wl,-soname=libdemo.so.1 -o libdemo.so.1.0.0 module1.o

3. Компоновочное имя - используется на этапе статического связывания приложения и библиотеки (не содержит номеров версий).

/* В исполняемый файл prog будет записан soname, к которому приведет нас libdemo.so */
$ gcc -g -Wall -o prog main.o libdemo.so

Для того, чтобы корректно подключить зависимость, нужно создать 2 символьные ссылки:

1) связывает компоновочное имя и soname;
2) связывает soname и реальное имя библиотеки;

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

libdemo.so -> libdemo.so.1
libdemo.so.1 -> libdemo.so.1.0.0
libdemo.so.1.0.0

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

libdemo.so.1 -> libdemo.so.1.0.1

Если обновление меняет мажорную версию, то, при использовании утилиты ldconfig, автоматически будет создана ссылка, связывающая soname и имя библиотеки. При этом, приложение будет работать с последней совместимой версией (если не была удалена).

$ sudo ldconfig -v | grep libdemo
libdemo.so.2 -> libdemo.so.2.0.0 (changed)

/* Выводим диинамические зависимости программы */
$ ldd prog
libdemo.so.1 => ./libdemo.so.1 (0x0000ffff8f870000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffff7ff50000)

Разбор пакетов: build-essential

Метапакет в Linux, который включает в себя все основные зависимости и инструменты, необходимые для создания debian сборок из исходного кода. Пакет является Debian-специфичным, поэтому отсутствует в репозиториях для Fedora/RedHat/CentOS и т.д.

Сам по себе не является программой, он всего лишь содержит список зависимостей, которые менеджер apt считывает и устанавливает в систему. Так как готовый пакет может включать бинарь программы, build-essential ставит соответствующие инструменты для компиляции и компоновки.

Главное - не считать его супер решением, которое магическим образом установит все необходимое рабочее окружение для Ruby, Go, Python и т.д. В первую очередь, пакет содержит список базовых инструментов для сборки (.deb) образов.

Некоторыми компонентами являются:

1. gcc/g++: стандартные C/C++ компиляторы в среде разработки Linux.
2. libc6-dev: заголовочные и объектные файлы, необходимые для сборки приложений, использующих стандартную библиотеку C.
3. util-linux: различные утилиты командной строки (chroot, fdisk, mount).
4. dpkg-dev: инструменты, необходимые для создания и управления пакетами в формате (.deb).
5. make: универсальный инструмент для автоматизации сборки программ.

sudo apt install build-essential

Динамические библиотеки

Для устранения недочетов статических библиотек были придуманы динамические (разделяемые).

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

Разделяемые библиотеки обладают следующими преимуществами:

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

2. Объектные модули не копируются в исполняемые файлы, поэтому можно изменять исходный код библиотеки без необходимости выполнения повторной компоновки. Полностью осознать данное преимущество поможет вымышленный пример, где стандартная библиотека C (libc) является статической. Если кто-нибудь найдёт и исправит баг в printf, то каждая программа должна будет заново пройти компоновку для того, чтобы заполучить исправленный код.

Использование динамических библиотек действительно полезно в случае, когда они являются необходимыми для большинства программ и имеют внушительный размер (QT/GTK).

Однако за эти дополнительные возможности приходится платить:

1. Динамические библиотеки более сложные по сравнению со статическими - как с точки зрения самой концепции, так и в плане создания и компоновки внутри программ.

2. Излишняя зависимость: если в библиотеку было внесено изменение, нарушающее ее совместимость с приложением, запуск будет невозможен. Со статически собранным вариантом такой проблемы не наблюдается, т.к. в нем все необходимые объектные файлы хранятся в виде копий.

3. Перемещение символов должно выполняться во время работы программы: этот процесс требует дополнительных работ, в том числе, выгрузки ядром разделяемой библиотеки динамического линковщика ld-linux.so для связывания на этапе выполнения. Все это приводит к затратам по времени, поэтому программа может работать немного медленнее статически скомпонованного аналога.

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

/* -Wall - выводит предупреждения, вызванные потенциальными ошибками в коде, не препятствующими компиляции программы, но способными привести, по мнению компилятора, к тем или иным проблемам на этапе выполнения. */

// -fPIC - завставляет компилятор сгенерировать адресно-независимый код.
$ gcc -c -fPIC -Wall module1.c module2.c module3.c

/* -shared - указывает gcc, что в результате должен быть собран не исполняемый файл, а разделяемый объект - динамическая библиотека. */
$ gcc -shared -o libdemo.so module1.o module2.o module3.o

Компоновка с динамическими библиотеками [1]

Перед применением библиотеки необходимо выполнить 2 дополнительных шага, которые не требуются для работы со статическими аналогами:

1. Поскольку исполняемый файл не содержит копии необходимых объектных модулей, он должен иметь возможность определять, какая разделяемая библиотека требуется для работы. Для этого, на этапе статической компоновки, в ELF файл программы внедряется метка DT_NEEDED с именем библиотеки.

Если говорить чуть более точно, то в поле DT_NEEDED записывается полный путь до библиотеки. Если зависимость находится в неизвестном компоновщику каталоге, то лучше указать дорогу через флаг -L, иначе потом может возникнуть вопрос "Почему зависимость находится корректно при ее локальном размещении?" - потому что ее полый путь записан в поле NEEDED.

$ gcc -Wall -o prog main.o -L=./libs/ -ldemo

// Выводим содержимое динамической секции ELF файла
$ readelf -d ./prog
    
Dynamic section at offset 0xd88 contains 28 entries:
   Tag        Type                         Name/Value
    0x0000000000000001 (NEEDED)             Shared library: [libdemo.so]
    0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

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

Компоновщик, сам по себе, является разделяемой библиотекой “/lib/ld-linux.so.2” и используется всеми исполняемыми файлами формата ELF, которые содержат динамические зависимости.

На самом деле, Id-linux.so.2 представляет собой обычную символическую ссылку на библиотеку динамического компоновщика “Id-<version>.so” (например, ld-2.11. so), где version - это версия glibc, которая установлена в системе.

Если на данном этапе попробовать запустить программу, выведется следующее сообщение об ошибке:

$ ./prog

./prog: error in loading shared libraries: libdemo.so: 
    cannot open shared object file: No such file or directory

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

Часть этих правил основывается на списке стандартных каталогов, в которых обычно хранятся разделяемые библиотеки (lib и /usr/lib). Причина ошибки выше заключается в том, что библиотека находится в текущем каталоге, который не учитывается при поиске.

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

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

Следовательно, можно запустить программу с помощью следующей команды:

$ LD_LIBRARY_PATH=./libs ./prog

Компоновка с динамическими библиотеками [2]

Мы уже познакомились с двумя способами оповещения динамического компоновщика о местоположении разделяемых библиотек:

1. Определение переменной среды LD_LIBRARY_РАТН.
2. Установка библиотеки в один из стандартных каталогов (lib, /usr/lib).

Но есть и третий путь: на этапе статической сборки в исполняемый файл (приложение либо разделяемую библиотеку) можно встроить список каталогов, по которым требуется производить поиск. Для этого можно воспользоваться параметром компоновщика -rpath:

/* определяем путь "./lib/demo/", как значение для поля DT_RPATH/DT_RUNPATH в исполняемом файле prog */
$ gcc -Wl,-rpath=./lib/demo/ -o prog prog.c -L=./lib/demo/ -ldemo

$ gcc -Wl,rpath=./demo2/ -shared -o libdemo.so mod1.o -L=./demo2 -ldemo2

Результатом компоновки будет запись метки RUNPATH в ELF файле:

$ readelf -d prog

Dynamic section at offset 0xd78 contains 29 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libdemo.so]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000001d (RUNPATH)            Library runpath: [./lib/demo/]
 
 $ ldd prog
 libdemo.so => ./lib/demo/libdemo.so (0x0000ffffb7790000)

Данный способ бывает полезен:

1. На этапе локальных сборок приложений. Вместо того, чтобы всегда указывать переменную окружения LD_LIBRARY_PATH, можно прописать 2 сценария сборки (debug/release) - в последнем сборка происходит без -rpath и все библиотеки устанавливаются в директории, о которых динамический компоновщик в курсе.

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

Разница между DT_RPATH и DT_RUNPATH:

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

Разница между двумя указанными записями заключается в их приоритете относительно переменной среды LD_LIBRARY_PATH: DT_RPATH переопределяет LD и обрабатывается с наибольшим приоритетом, DT_RUNPATH имеет меньший вес и рассматривается сразу после LD.

По умолчанию современные версии компоновщика записывают значение -rpath в метку DT_RUNPATH. Чтобы задействовать вместо этого DT_RPATH, следует дополнительно указать параметр --disable-new-dtags:

$ gcc -g -Wall -Wl,--disable-new-dtags,-rpath=./lib/demo \
   -o prog main.c -L=./lib/demo/ -ldemo
    
$ objdump -p prog | grep PATH
RPATH ./lib/demo/

Использование переменной $ORIGIN в списке rpath:

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

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

Для решения данной проблемы динамический компоновщик позволяет указать в параметре -rpath специальную строку, $ORIGIN, которую он умеет анализировать и интерпретировать как «каталог, содержащий приложение». Это значит, что поиск динамических зависимостей будет происходить по пути, относительно тому, в котором приложение установлено:

$ gcc -Wl,-rpath,'$ORIGIN'/lib/demo ...

$ objdump -p prog | grep PATH
RPATH $ORIGIN/lib/demo/

Теперь можно предоставить пользователю простой установочный пакет с программой и необходимыми библиотеками, который он сможет установить в любое место и успешно запуститься. Как говориться, "Дело сделано" - принимайте работу под ключ.

Компоновка с динамическими библиотеками [3]

Последним из основных способов оповестить динамический компоновщик о местонахождении библиотек является набор соответствующих записей в файле "/etc/ld.so.conf". Как мы знаем, из коробки компоновщику известно несколько путей, по которым могут лежать библиотеки (lib, /usr/lib).

Для того, чтобы расширить этот список, можно внести набор соответствующих записей в конфиг (ld.so.conf), который используется программой ldconfig для того, чтобы создать необходимый компоновщику бинарный кэш "/etc/ld.so.cache" с информацией о всех зависимостях, найденных по заданным путям. Анализируя данный кэш, загрузчику станет понятно, какая библиотека требуется приложению на этапе выполнения.

Почему компоновщик не читает ld.so.conf напрямую? Чтение кэша - более быстрая процедура, относительно анализа файла конфигурации: нужно проверить инклуды, пройтись по файловой системе, открыть каждый файл, считать его содержимое, найти зависимости. С таким подходом потребовалось бы значительное количество дополнительных операций на этапе выполнения для того, чтобы связаться с библиотекой - лишние тормоза и задержки нам ни к чему.

Если посмотреть внутрь ld.so.conf, можно увидеть следующее:

$ cat ld.so.conf
include /etc/ld.so.conf.d/*.conf
/usr/lib/mysql

Это значит, что содержимое всех файлов с сигнатурой <filename>.conf в каталоге "/etc/ld.so.conf.d/" будет рассмотрено при формировании итогового кэша:

$ ls /etc/ld.so.conf.d/
libc.conf

$ cat /etc/ld.so.conf.d/libc.conf
/usr/local/lib

Соответственно, для того, чтобы компоновщик смог найти библиотеку, с которой ваше приложение связано, необходимо записать полный путь до директории либо в ld.so.conf, либо в отдельный файл, который следует включить в список поиска через ключевое слово include.

После внесения изменений в конфиг, необходимо обязательно обновить кэш, иначе пути, которые вы прописали, останутся без внимания компоновщика:

$ sudo ldconfig

Подводя черту, можно сказать, что динамические библиотеки, необходимые программе, ищутся в нескольких местах со следующим приоритетом:

1. (только для ELF) Если исполняемый файл содержит запись DT_RPATH с какими-либо каталогами, то поиск будет выполнен по ним.

2. Если определена переменная среды LD_LIBRARY_РАТH, то поиск будет выполнен последовательно по каждому каталогу, который в ней указан. Если исполняемый файл устанавливает пользовательский (SUID) или групповой (SGID) идентификатор, то переменная игнорируется. Это делается в целях безопасности, чтобы не дать пользователю обмануть динамический компоновщик, заставив его загрузить вместо требуемой библиотеки ее приватную версию с тем же именем.

3. (только для ELF) Если исполняемый файл содержит запись DT_RUNPATH с какими-либо каталогами, то они будут использованы во время поиска.

4. Проверяется файл /etc/ld.so.cache на наличие записи для соответствующей зависимости. Если бинарный файл был связан с опцией компановщика "-z nodeflib", библиотеки в путях по умолчанию (lib и /usr/lib), будут пропущены.

5. Выполняется поиск по каталогам lib и /usr/lib (именно в таком порядке). Если бианрный файл был связан с опцией компановщика "-z nodeflib", данный шаг будет пропущен.

Контент план по разделяемым библиотекам:

1. Общая информация про разделяемые библиотеки
2. Компоновка с динамическими библиотеками [1]
3. Компоновка с динамическими библиотеками [2]
4. Компоновка с динамическими библиотеками [3]
5. Версионирование разделяемых библиотек
6. Отложенное связывание символов (Lazy Binding)
7. Ускорение работы библиотек: отключение ленивого связывания
8. Использование флага компоновщика -Bsymbolic
9. Ускорение работы библиотек: отключение перехвата функций
10. Ускорение загрузки библиотек: отключение неиспользуемых библиотек
11. Команды ldconfig, ldd, objdump, readelf, nm
12. Отложенная загрузка библиотек (dlopen, dlclose, dlerror, dlsym, dladdr)
13. Управление видимостью символов (attribute: visibility)
14. Ускорение работы библиотек: сокращение интерфейса библиотеки
15. Версионирование символов
16. Инициализация и финализация функций (attribute: constructor, destructor)
17. Мониторинг работы загрузчика (LD_DEBUG)

Отложенное связывание символов (Lazy Binding)

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

Как мы знаем, в динамической секции ELF файла содержатся названия всех разделяемых библиотек, от которых наше приложение зависит:

$ readelf -d prog
Dynamic section at offset 0xd78 contains 29 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libdemo.so]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

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

./prog: error in loading shared libraries: libdemo.so: 
    cannot open shared object file: No such file or directory

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

Для связывания в ELF существует специальная секция .dynsym, в которой ключевым словом UND (undefined) помечены названия всех символов, которые необходимо определить:

$ readelf --dyn-syms ./prog

Symbol table '.dynsym' contains 13 entries:
Num:    Value          Size Type    Bind   Vis      Ndx Name
 6: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND calculate_smth

Как и когда происходит разрешение имен?

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

$ readelf -SW ./prog
Section Headers:
  [Nr] Name              Type            Address          
  [12] .plt              PROGBITS        00000000000006a0 
  [21] .got              PROGBITS        0000000000010f78 

При статическом связывании программы, все вызовы динамически подгружаемых символов записываются компоновщиком следующим образом "<name>@plt". Это говорит о том, что в рантайме будет выполнена не сама функция, а определенная заглушка, которая, по таблице GOT выяснит, найден ли соответствующий адрес. Вот так выглядит команда на уровне ассемблера:

call 0x401060 <puts@plt>

Если адрес неизвестен, код внутри заглушки попросит загрузчик его определить и записать в соответствующее поле таблицы GOT, после чего будет выполнена команда jump на адрес и начнется выполнению кода. При последующих вызовах функции заглушка проверит адрес в таблице GOT и так как он будет определен, пропустит вызов компоновщика и сразу перейдет на jump до функции:

jump 0x404018 <puts@got.plt>

Так вот, что же такое Lazy Binding?

Это процесс определения адресов на этапе выполнения. Такой подход призван ускорить старт программы, так как не требуется при загрузке ее в память полностью заполнять все точки входа таблицы GOT: проходиться по всем библиотекам из секции .dynamic и определять адреса для каждого символа секции .dynsym.

Это не значит, что библиотеки, от которых зависит исполняемый файл, не будут загружены в память. Отложенная загрузка библиотек - это чуть другая история (Lazy Loading). В Linux, к сожалению, данный функционал отсутствует и реализован только сторонними утилитами, допустим, imlib.so.

Lazy binding обладает как плюсами, так и минусами. С одной стороны, ускоряется старт программы, с другой, приложение может неожиданно упасть, если на этапе выполнения не будет найден какой-то символ (как мы помним, это может произойти из-за того, что таблица GOT инициализируется не сразу, а по мере необходимости).