И снова про static linking

Но если пакетный менеджер умеет дельты, то это уже не кажется такой уж большой проблемой.

Ась?

Статически слинкованые дистры вообще существуют?

/me прикинул вдруг glibc статично запихать в каждый бинарь... У месье датацентр дома?

http://www.etalabs.net/compare_libcs.html

shared object — название говорит само за себя, файлы mmap'ятся и не занимают отдельной памяти в каждом процессе. Венда насколько я знаю так не может.

Венда насколько я знаю так не может.

В этом треде становится всё интереснее, давай, жги исчо!
http://en.wikipedia.org/wiki/Dynamic-link_library

Статически слинкованые дистры вообще существуют?

Линукса скорее всего нет, так как смысла особенного нет. Бинари размера просто огромного.

А вообще есть Plan9 :) там static by design.

Дабы предвосхитить вопросы - http://www.plan9.bell-labs.com/wiki/plan9/why_static/

http://sta.li/

Нет, он имеет в виду, все либы статически слинковать в libWorld и дальше линковаться только с ней

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

Про Plan9 вкурсе.

Топик не читай до конца @ ссылки кидай

$ du -cs $(find /lib/ /lib32 /usr/lib/ /usr/lib32 -type f -iname *.so*) |tail -1
1,1G total

Okay.

Я такого не имел в виду.

Умножь на два. Тебе гига места на диске жалко?

Умножь на два. Тебе гига места на диске жалко?

Два бинаря в системе. Ого! Да ты многозадачен!

Многое из этого будет в озу по многу раз, на каждую программу. Какая от этого выгода?

см. ссылку выше.

Ещё по этой ссылке есть Performance comparison.

Откуда дрова про огромные бинари?

Назову просто несколько проектов, которые в целях мазохизма, собирал статикой:

apache+all_plugins :) + php

Gimp 1.2

Давно это было, но линковка занимала с полчасика :) и бинари по нескольку десятков мегабайт.

Ты упоролся. Или ты реально считаешь, что при статической компиляции в бинарь суют всю либу в полном составе со всеми не используемыми функциями?

Апологеты статической линковки говорят, что при отсутствии динамики программы стартуют и шуршат быстрее + решаются проблемы типа DLL hell. + улучшается переносимость среди дистрибутивов.

Ага, вижу. Обычно при оптимизации приходится выбирать между размером и скоростью. И то и другое одновременно оптимизировать сложно.

При статической линковке суются объектники со всеми используемыми функциями и их зависимостями.

что при отсутствии динамики программы стартуют и шуршат быстрее

Оверхед динамического линкера довольно минимален и заметишь ты небольшую задержку лишь при первом запуске.

улучшается переносимость среди дистрибутивов

спорно.

Ммм, странно, мне казалось, что линковка процесс быстрый.

Десятки метров это не сотни, для программ уровня Gimp более чем acceptable :)

Ты упоролся. Или ты реально считаешь, что при статической компиляции в бинарь суют всю либу в полном составе со всеми не используемыми функциями?

При статической линковке в бинарник обычно попадает куча левого неиспользуемого дерьма. Линкер не умеет определять, какие символы реально используются, а какие — нет.

Простейший пример:

$ cat c.cc
#include <iostream>

main() {}


$ g++ -static-libstdc++ -O2 c.cc 

$ ls -sh a.out 
4,4M a.out

$ nm -C --defined-only a.out | wc -l
2894

Ну тогда такой дистрибутив в LiveCD не поместится

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

Но есть и существенный довод за. На суперкомпьтере из 50K узлов, попробуйте выполнить на каждом «dlopen» и наслаждайтесь IO трафиком. Часа три.

Статически слинкованые дистры вообще существуют?

Cray Linux.

спорно

почему?

Переносимость улучшается, да. Но http://stackoverflow.com/questions/3430400/linux-static-linking-is-dead

так вроде рано же еще для осеннего обострения. или тебе просто скучно?:)

Aren’t whole libraries linked into a static executable?

No. Good libraries implement each library function in separate object (.o) files, this enables the linker (ld) to only extract and link those object files from an archive (.a) that export the symbols that are actually used by a program.

http://sta.li/faq

Судя по всему, это проблема С++ и его стандартной библиотеки в исполнении GNU.

Шикарный довод :)

Good libraries implement each library function in separate object (.o) files

Ох, лол. Список этих good libraries — в студию! :D

Судя по всему, это проблема С++ и его стандартной библиотеки в исполнении GNU.

Боюсь, что в реальности это проблема 90% популярных библиотек.

Линкер не умеет определять, какие символы реально используются, а какие — нет.

[kosyak@knetbook ~]$ g++ -static-libstdc++ -O2 c.cc
[kosyak@knetbook ~]$ ls -sh a.out
728K a.out
[kosyak@knetbook ~]$ g++ -static-libstdc++ -ffunction-sections -fdata-sections -Wl,--gc-sections -O2 c.cc
[kosyak@knetbook ~]$ ls -sh a.out
384K a.out

Тоже не сахар. Для этой фичи нужно, чтобы все линкованные библиотеки были собраны с -ffunction-sections -fdata-sections

С flto результат должен быть ещё лучше.

Прежде чем на размер смотреть, нужно быть сделать «strip --strip-debug». Это я облажался.

-ffunction-sections -fdata-sections

Это не панацея. https://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Optimize-Options.html «When you specify these options, the assembler and linker will create larger object and executable files and will also be slower.»

Статически слинкованые дистры вообще существуют?

http://www.alpinelinux.org/

Где у них на сайте об этом написано? Не нашел.

У них не все собрано статикой (и все не соберется). Но с musl можно собирать многое на что плюется glibc/eglibc (ааа, вам нужна рантайм библиотека! вы же собираетесь украсть наш код, аааарррр :)

вы же собираетесь украсть наш код

Лицензия типа «с раздвинутыми булками» напрочь отбивает всякое желание поучаствовать в разработке этой вашей musl.

Мне как-то пофиг на твое высокое мнение. Ибо, исторически сложилось так, что если бы не Unix, MIT и BSD, ни Minix, ни Linux не было вообще. Было бы что-то другое, но это мы никогда не узнаем.

Без обид.

Без обид.

Та я не про историко-философию, а про то, чтобы пройти на http://www.openwall.com/lists/musl/ и включиться в решение их проблем.

И? Что мешает? Зашел, подписался, пишешь код, шлешь патчи :)

Что мешает?

Чувство, что убиваю свободные прошивки.

Надо мыслить позитивно. Сейчас musl, потом кто-то сделает форк и выпустит под GPL. Тебе какая разница? Настоящая конкуренция, вот прям чуваки из соседнего офиса клепают прошивки на musl и делают бешенные деньги? А сам так не хочешь из-за религии? :)

То есть /sbin можно выносить ? Его идея умерла ?

Статически слинкованые дистры вообще существуют?

Gentoo с LDFLAGS=-static и USE=static static-libs пойдёт? Единственное, так могут возникнуть проблемы с разными бинарными плагинами.

Тебе какая разница?

Говорю же: я пользуюсь свободными прошивками, в основном из-за их высокой стабильности и из-за какого-никакого независимого аудита. Вендоры и сейчас-то исходники от своей стоковой фирмвари выдают под угрозой судебных исков, а если появится возможность заменить glibc / busybox / и.т.д. на софт с пермиссивными лицензиями, то исходников мы не увидим как своих ушей. И свободных прошивок не станет; вместо них придётся жрать продукты копроэкономики, давиться и жрать, без альтернатив.

Какая мне разница? Как-то глупо пилить сук, на котором сидишь.

Не распарсил, причём здесь /sbin?

http://www.linfo.org/sbin.html

The sbin in /sbin is short for system binaries. A binary, or binary file, is a type of file that contains some non-text data. Executable files are a type of binary file.

вот прям чуваки из соседнего офиса клепают прошивки на musl и делают бешенные деньги? А сам так не хочешь из-за религии?

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

Qt не соберётся в статику. Точнее соберётся, но без WebKit'а. GTK+ скорее всего тоже.