> Вполне возможно, что такое есть. > Вполне возможно, что оно быстрее работает. Никто с этим не спорит.

Всё достаточно просто: при статической линковке прилинковываются только те функции, которые нужны. То есть, если ты свято уверен, что одна отдельно взятая библиотека будет использоваться одной-двумя софтинами, при этом не полностью а процентов эдак на 40, можно смело линковать статически.

А насчет быстрее работает... Я бы сказал, быстрее *грузится*, а не работает. Потому как не дёргаются всякие там /lib/ld-elf.so и прочее. Вот и всё. Экспериментально проверено на сборке Midnight Commander'а под OSX для клиента, которого задолбали пакеты с прилинкованными туда неизвестно зачем X11. MC из gtk-шной glib пару функций юзает в любом случае -- так почему бы не прилинковать их статически, особенно если учесть что под OSX этот самый glib больше вообще ни для чего использоваться не будет?

> Двоешник, если бы ты не прогуливал занятия по программированию, то > наверное смог бы понять, почему ескплоит для .so либы, в большинстве > случаев не работает при стат. линковке.

Хм. Интересно. Аргументы?

>> Прикинь, сколько копий libc и прочей муйни будет висеть у тебя в >> памяти при хотя бы 100 запущенных статических процессах >а какая разница? они всё равно занимают совершенно тот же объём RSS >надеюсь, понятно почему?

Нет, непонятно. Аргументы?

С so-шкой все понятно, ее можно отобразить в пространство нескольких процессов (r/o, разумеется :) ). Получаем выигрышь по памяти. А как со статически слинкованным бинарником? Хинт: а при запуске 10 прог, слинкованные с разными (чуть-чуть :), буквально самый минорные изменения ) версиями некой либы? Тут-то уже никак не получится делить код либы между несколькими процессами?

>> Двоешник, если бы ты не прогуливал занятия по программированию, то > наверное смог бы понять, почему ескплоит для .so либы, в большинстве > случаев не работает при стат. линковке.

> Хм. Интересно. Аргументы?

Типа, шаренные либы мапятся в адресное пространство процесса предсказуемее, чем прилинкованные статически.

> Типа, шаренные либы мапятся в адресное пространство процесса > предсказуемее, чем прилинкованные статически.

Да, точно. Не подумал. Это может сыграть свою роль.

> Хм, а у меня

> sh, as, gcc, gdb, ld, make - все статические, интересно зачем?

Вспоминается классический анекдот про деятелей, первым делом после установки FreeBSD ставящих руту в качестве шелла динамически слинкованный /usr/local/bin/bash. Когда у них /usr отдельным разделом... ;-)

Гм. Ладно, а нафига тогда прелинку -R?

P.S. Это я не издеваюсь, а серьезно спрашиваю.

Насколько я понимаю, именно для избавления от этого эффекта.

мдямс.... ALT Linux не страдает такими проблемами =) Хотя давно переименовать альт в Russian debian :)

so

> пусть вспомнит древнюю историю со статически линкованным
я хбз как но у меня работал и на asp 7.2 и на 9ке.
вообще, с трудом себе представляю условия когда статика не работает. не зря же говорят что статически слинкованной с libc проге в принципе только kernel нужен для работы.
а гораздо чаще от динамических линковок проблемы - это когда набор exported меняется.

so

> Неа, объясняй ;)
потому что ядро всё равно отмапит примерно в один и тот же объём памяти и so и static (мапятся-то блоки с диска а у одних и тех же экземпляров бинарника они 100% совпадают)
поэтому никакого выигрыша для основного процесса на сервере делать so а не статиком нет в разрезе memory. Болеее того, может даже уйти меньше памяти за счёт отсутствия reloc table.
гон про то что so проги грузятся быстрей пропущен.
я замерял time - so апачи медленней стартуют (но разница крайне маленькая). даже понятно почему. dso ещё медленее...

Чорт. За давностью лет все забыл (склероз, однако). Там была проблема (so 5.0) с тем, что они использовали неопубликованные символы в glibc 2.0, которые исчезли в glibc 2.1. Так что дело было не в статической линковке, а в неправильной динамической:)

so

> классический анекдот про.../usr/local/bin/bash
это не анекдот...быль;-(
и я даже таких знавал лично.:-(

> у одних и тех же экземпляров бинарника они 100% совпадают

А если бинарники разные, а сошка одна? Типа, запустил я гномовскую сессию, все гномовские сошки замапились - будет ли запускаемый gedit использовать уже отмапленные сегменты кода libgtk.so? Насколько я представляю, в статическом случае - нет, в динамическом - да.

Нет, бывают часто очень удачные моменты. Например, блендер. Динамический бинарник - 1.5 метра и работает хз как, статический - примерно 2.5 и работает нормально.

Игрушки статикой пускать - милое дело. heretic2 работает и работает.

>> "Вспоминается классический анекдот про деятелей, первым делом после установки FreeBSD ставящих руту в качестве шелла динамически слинкованный /usr/local/bin/bash. Когда у них /usr отдельным разделом... ;-)"

А в чём анекдот-то? Один хрен, если придёцца по boot -s грузицца, то у тебя спросят какой шелл запустить.

>потому что ядро всё равно отмапит примерно в один и тот же объём памяти и so и static (мапятся-то блоки с диска а у одних и тех же экземпляров бинарника они 100% совпадают)

Дык речь идет не о 100 экземплярах одной программы а о _различных_ кусках статических библиотек в _различных_ программах

>Ну, что сказать? Ещё один отвалился по причине тонкости кишки. 
>Ладно, будем считать, что с пионерами спорить на деньги нельзя. 
>Показываю статически собранный gcc-3.2.2, который меньше, быстрее и 
>т.д. ftp://ftp.freenet.de/pub/lart.info/42/gcc-3.2.2.tbz2 
> 
>Что скажет пионерская дружина и прочие "нормальные" люди?

Ты бы еще кинул пример со статически прилинкованной libc4...
Не помню точно, давно было, но dietlibc име(ла/ет) кучу ограничений,
и совершенно точно могу сказать, что многие вещи с ним работать
не будут и даже не собируться, напильник нужен будет громадной 
величины, к тому же, могу быть уверенным, что таким gcc ты очень 
много насобираешь...:)))

P.S. Тебя просили привести пример без dietlibc и прочих ухищрений...
 

> Хм, а у меня

> sh, as, gcc, gdb, ld, make - все статические, интересно зачем?

> FreeBSD 5.2

Эх, Саныч...

FreeBSD 5.2-CURRENT

ldd `which sh` /bin/sh: libedit.so.4 => /lib/libedit.so.4 (0x48091000) libncurses.so.5 => /lib/libncurses.so.5 (0x480a4000) libc.so.5 => /lib/libc.so.5 (0x480e1000)

Какая-то у вас Фря неправильная :>

> А в чём анекдот-то? Один хрен, если придёцца по boot -s грузицца, то у тебя спросят какой шелл запустить.

Во! Я тоже что-то не просек, в чем шутка юмора... И вообще, cd shells/bash; make install PREFIX=/ :)))

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

В линуксе не гарантируется работа статически собранных программ от версии к версии ядра. Динамические работают. Я сам с этим лично сталкивался. Да это и в высказываниях высокопоставленных товарищей пролетало.

An utter flame. RPM is good for the purpososes it was created for. Why the fuck does the author tries to represent RPM as a panacea for all his mental deseases? Definately he's bad at handling Unix and he'll be completely happy with reinstalling his Windows box twice a month.

2 birdie:
> An utter flame. RPM is good for the purpososes it was created for.
> Why the fuck does the author tries to represent RPM as a panacea for
> all his mental deseases? Definately he's bad at handling Unix and
> he'll be completely happy with reinstalling his Windows box twice a
> month.

Why do you speak this fucking language, you bloody motherfucker?
Go suck your dead american dick, idiot!
Or maybe tou suck the troops dicks for a nickel, baby?

сразу видно грязного слакварщика который даже русифицировать систему не может

>сразу видно грязного слакварщика который даже русифицировать систему не может

Те кто могут вероятно являются "чистыми слакварщиками" ;)

Кстати, в тех RPM, которые MySQL раздаёт, сплошная статика:

http://dev.mysql.com/downloads/mysql/4.0.html

(см. пакеты из подраздела Linux x86 RPM downloads)


$ for exec in `rpm -ql MySQL-server | grep bin`; do file $exec; done |
grep -v -E "(script|symbolic)"
/usr/bin/isamchk: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, statically linked, stripped
/usr/bin/isamlog: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, statically linked, stripped
/usr/bin/my_print_defaults: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, statically linked, stripped
/usr/bin/myisamchk: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, statically linked, stripped
/usr/bin/myisamlog: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, statically linked, stripped
/usr/bin/myisampack: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, statically linked, stripped
/usr/bin/mysqltest: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, statically linked, stripped
/usr/bin/pack_isam: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, statically linked, stripped
/usr/bin/perror: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, statically linked, stripped
/usr/bin/replace: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, statically linked, stripped
/usr/bin/resolve_stack_dump: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, statically linked, stripped
/usr/bin/resolveip: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, statically linked, stripped
/usr/sbin/mysqld: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, statically linked, stripped

$ ldd /usr/sbin/mysqld
not a dynamic executable

не, "чиста слакварщиками \m/ \m/" ;)

static

> Дык речь идет не о 100 экземплярах одной программы
панацеи не бывает...
я веду речь лишь о случае работы сервера с ярко выраженным лидирующим процессом (apache, named, MTA) где основной объём памяти занимает одна и та же программа - так что 90-95% RSS используется совместно по-любому.
btw, это объясняет и почему мускул собирают по умолчанию статиком: проблем меньше а производительность больше с ориентацией на загруженные серваки с большим кол-вом мускулей как основного процессса.

Видимо у него 5.2-RELEASE. Переход на динамически собраные /bin/* начался относительно недавно, но товаришь BaT этого не знает.