LINUX.ORG.RU
ФорумTalks

Дистры для development


0

0

Возникла ситуевина, когда клиент попросил собрать заказ статиком, на Fedora, Mandriva, SuSE этого сделать не удалось. Удалось только на Slackware, Kubuntu не удалось поставить ибо диск битый оказался. Собственно вопрос, почему так сделано - исключена возможность линковать все статиком в вышеупомянутых дистрах?

★★★

возьми кноппикс, засунь туда нужную прогу и жги.

lester_dev ★★★★★
()

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

troorl ★★
()

Чтобы не создавать себе лишние security-holes и дистры не разбухали до невообразимого состояния.

JackYF ★★★★
()

а lib*-static ставить религия не позволила?

redgremlin ★★★★★
()

%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
%

saahriktu ★★★★★
()
Ответ на: комментарий от Lee_Noox

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

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

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

devinull ★★
()
Ответ на: комментарий от devinull

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

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

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от devinull

> так ты можешь пояснить, что значить "не гарантируется"?

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

--libc ;)

sS ★★★★★
()
Ответ на: комментарий от sS

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

> --libc ;)

?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

devinull ★★
()
Ответ на: комментарий от devinull

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от devinull

И что легче по вашему пересобрать ? Программу под новое ядро и библиотеки или таки libc на целевой платформе ?

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

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

sS ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

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

И ?

sS ★★★★★
()
Ответ на: комментарий от sS

>И что легче по вашему пересобрать ? Программу под новое ядро и библиотеки или таки libc на целевой платформе ?

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

devinull ★★
()
Ответ на: комментарий от sS

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

> И ?

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

tailgunner ★★★★★
()
Ответ на: комментарий от sS

+1
Клиент не умеет решать зависимости не системе и ставить требуемые либы, в слове ldd он умудрился сделать 4 ошибки, написав ж**а :)

Lee_Noox ★★★
() автор топика
Ответ на: комментарий от devinull

>Ядро и libc так и так пересобирать

???

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

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

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

sS ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

sS ★★★★★
()

>SuSE этого сделать не удалось.

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

sS ★★★★★
()
Ответ на: комментарий от anonymous

>В русском языке нет перевода для слова "сабж"?

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

sS ★★★★★
()
Ответ на: комментарий от sS

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

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

Не путаю.

tailgunner ★★★★★
()
Ответ на: комментарий от sS

>>redhat

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

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

sS ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda

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

Там локалей (по крайней мере русских) больше чем в 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

 

sS ★★★★★
()
Ответ на: комментарий от sS

NSS и прочая чепуха грузится неявно. Статически не собирается по определению. Так что если вдруг будет какая то несовместимость с ABI все завалится к чертям. Надо таскать тогда всю помойку либ вместе с прогой.

vasily_pupkin ★★★★★
()
Ответ на: комментарий от vasily_pupkin

>Статически _не_собирается_(!) по определению

О чём и речь ;)

sS ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.