Дистры для development

%cat dummy.c
main(){}
%gcc -o dummy dummy.c
%ldd dummy
        linux-vdso.so.1 =>  (0x00007fffa75ff000)
        libc.so.6 => /lib/libc.so.6 (0x00007f8e9f1dc000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f8e9f416000)
%du -b dummy
6311    dummy
%gcc -static -o dummy dummy.c
%ldd dummy
        не является динамическим исполняемым файлом
%du -b dummy
709885  dummy
%

>> и это правильно

> Умный, да? Наверное от того, что знаешь все. Или ни фига....

Он прав. Работоспособность программ, которые статически линкуют libc, не гарантируется.

А можно поподробнее с этого места?

PS: Если честно, работоспособность никаких программ не гарантируется, с этого GPL начинается.

>А можно поподробнее с этого места?

Читал об этом у Дреппера, но точного линка под рукой нет.

> Если честно, работоспособность никаких программ не гарантируется, с этого GPL начинается.

Не умничай. GPL тут ни при чем совершенно.

Это значит, что следующие изменения в системе ядро+libc могут привести к неработоспособности программы. Каким образом - спроси Дреппера.

--libc ;)

> --libc ;)

?

Если слинкуешь libc динамически, тебе не придется пересобирать приложение, это же очевидная вещь. Но речь не только об этом - сама glibc уже некоторое время рассчитана на то, что ее линкуют динамически, и в статическом варианте может не работать.

Найду статью - зашлю сюда ссылку.

Отож... еще один решил прикидываться шлангом %)

Если смотреть шире то иногда для заказчика как раз статически собранное поделие получается менее геморройным (не нужно ставить кучу левых библиотек)

По опыту статически собранный софт живёт дольше (если он изначально работает на целевой платформе). Проблемы возникают только при использовании ну очень древнего статически собранного софта.

>Отож... еще один решил прикидываться шлангом %)

ss@hyperblade-master:/mnt/pvfs2/BackUp/RFFI2007/OMP> ldd OpenCFD-0.111-icc-x86_64-OMP
        not a dynamic executable

Работает на любых современных (>2.6.9 точно) ядрах

И ?

Ядро и libc так и так пересобирать, а насколько геморойна будет сборка программы зависит от авторов.

> И ?

И славненько.

s/2.6.9/2.6.4/ ;)

???

То есть поставляя софт заказчику вы ещё ему и систему пересобираете ?

Вы ничего нигде не спутали ?

hint: Обычно в ТЗ чётко оговаривается система на которой _должен_ работать софт. Статическая сборка просто слегка расширяет диапазон поддерживаемых платформ. Но не до бесконечности и это надо понимать (и указывать это в документации).

Ты путаешь "не будет работать" с "не сможешь собрать" ;)

Странно. Вышеприведённая мною бинарь собрана в SLES10 с помощью icc 9.1

Никак от ЕГЭ по русскому не отойдёте ? ;)

> Ты путаешь "не будет работать" с "не сможешь собрать" ;)

Не путаю.

glibc сейчас где то явно зовёт dlopen() ? ;))

Для труЪ: "all kinds of features in the libc (locale (through iconv), NSS, IDN, ...) require dynamic linking to load the appropriate external code."

С этого и нужно было начинать ;)

RH давно уже вещь в себе ...

>С этого и нужно было начинать ;)

Ну я с самого начала ссылался на Дреппера ;)

> RH давно уже вещь в себе ...

а на Слаке другая libc, которая реализует упомянутые features без динамической загрузки? :)

ХЗ какая она по сравнению с RH (не держу).

>ну видимо на слаке нет локали - нет и проблем :) 

Там локалей (по крайней мере русских) больше чем в SLES10

SLES10:

locale -a | grep ru
ru_RU
ru_RU.koi8r
ru_RU.utf8
ru_UA
ru_UA.utf8

Slackware 12.1:

locale -a | grep ru
ru_RU
ru_RU.cp1251
ru_RU.koi8r
ru_RU.utf8
ru_UA
ru_UA.utf8

 

О чём и речь ;)