Overhead от динамической линковки
http://harmful.cat-v.org/software/dynamic-linking/
http://harmful.cat-v.org/software/dynamic-linking/versioned-symbols
https://sta.li/faq/
В комментарии http://blog.stargrave.org/russian/
71870b1510dfc2727093f2767b994b8596f9b163#comment1
я запускал convert, в котором ldd на полэкрана, в течении 165мс. Когда
руками собрал с нуля, то у меня на полтора экрана вывод ldd и утилита
запускается более чем в два раза дольше. Всё таки 200мс это очень и
очень заметное на глаз время, тем более для long-live утилиты.
Когда я только начал в этом году программировать на C, то задавался
вопросом какие библиотеки мне делать (static vs shared). И все хакеры
говорят в один голос о статической линковке. Есть даже целый "stali"
(static linux) дистрибутив, целью которого является только статическая
линковка, musl и всякое такое. В котором много ссылок на конкретные
примеры всяких размеров программ, времени их запуска и тому подобного.
Plan9 и Go -- имеют только такую линковку.
И вот, судя по ImageMagick, я однозачно теперь тоже за статическую.
Во-первых, если использовать всякие -ffunction-sections+-Wl,--gc-sections,
то в итоговом исполняемом файле не останется лишнего кода в виде
неиспользуемых функций. Во-вторых, даже если размер будет и больше, то
он всё равно при этом будет быстро (быстрее) загружаться, что куда
важнее чем место на диске.
Основной аргумент за динамическую линковку у людей: типа если нужно
обновить OpenSSL, то можно только его обновить, не трогая остального. Но
даже я на своей практике с чистой совестью могу заявить что это брехня
только изредка работающая, ибо регулярно *на практике* несовместимости в
версиях библиотеки, которые препятствуют обновлению и по факту
приходится всё равно пересобирать зависимый от неё софт. Да и в чём
проблема пересборки всего что зависит от неё, пускай это даже и libc?
Отсутствие исходников? Не аргумент, ибо они должны быть в свободном ПО.
Проприетарное -- идёт нафиг. Время сборки/пересборки -- а вот это повод
задумываться над скоростью компилирования. C-компиляторы вполне себе
шустрые например. Go -- аналогично, пересобрать ВЕСЬ Go софт, сколько бы
его не было -- вопросы нескольких минут, как мне представляется на
практике. C++/Rust/etc -- теперь я ещё больше понимаю насколько важно
время сборки. А в идеальной и прекрасной системе со свободным ПО (значит
и исходники будут) на C/Go проблем нет никаких. Скорость,
производительность, простота, безопасность (куча ссылок касающаяся
недостатков динамической линковки про безопасность как-раз),
эффективность! Плюс никаких проблем с тем чтобы иметь софт с самыми
разносторонними по версиям зависимостями, ибо они всё равно вшиваются.
Я однозначный поклонник этого подхода!