Как установить программу со всеми её зависимостями статически?

В общем случае - никак. Конкретно у ffmpeg есть USE-флаг static-libs

у ffmpeg есть USE-флаг static-libs

не работает. его я и пробовал. /исправил

В общем случае - никак

почему? гента разве не рулит?

http://linux.die.net/man/3/dlopen

Ни на какие мысли не наводит?

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

блин, я всё-таки тебя не понимаю

в /111/lib64 создаются динамические библиотеки и в /111/bin динамически слинкованные программы.

а почему не должны?

блин, я всё-таки тебя не понимаю

Нужно скомпмилировать статически, чтобы потом /111 можно было перенести в другой дистр и там работало.
В старом минте ffmpeg кривой. В гентушном чруте хочу как-то скомпилировать, чтобы можно было использовать в минте.

а почему не должны?

разве при статической линковке не должны создаваться *.a?

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

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

ну всё упрётся в libc, не получится же запустить в память две разные версии libc?
а разве нет связи? статические не более переносимые и независимые?
честно говоря о линковке я вообще нихера не понимаю.
вот пытался нагуглить ответ на вопрос почему в LFS libc нужно при первом проходе статически, так и не нашёл.
может есть хорошая статья, которая всё разъяснит?

Короче, ты, всё-же почитай про библиотеки. Если хочешь сделать сборку софта с полностью статическими библиотеками, тебе, вероятно, придётся переписывать этот софт.

ну подгони годную статью. чтоб я получил ответ по компиляции первого прохода в LFS

Если хочешь сделать сборку софта с полностью статическими библиотеками, тебе, вероятно, придётся переписывать этот софт.

а что тогда юзфлаг static-libs меняет, если всё-равно получается динамически?

в /111/lib64 создаются динамические библиотеки и в /111/bin динамически слинкованные программы.

пруф?

пруф?

нет это не пруф, пруф это такая фигня которая начинается с http://

Да я юморист :))

Он генерит статические либы. Не факт, что сам бинарь ffmpeg будет их использовать, для этого есть USE флаг «static» и используется он далеко не везде.

ладно, а получится ли после компиляции перетащить /111 в другой дистр, чтобы он работал именно из /111/usr/bin? что для этого нужно? какой-нить PREFIX=/111 указать emergу или что-то ещё?

сделал так.
в чруте работает, а в другом дистре:
/111/usr/bin/ffmpeg: error while loading shared libraries: libavdevice.so.54: cannot open shared object file: No such file or directory

как скомпилять в /111 со ВСЕМИ зависимостями зависимостей?

/111/usr/bin/ffmpeg: error while loading shared libraries: libavdevice.so.54: cannot open shared object file: No such file or directory

странно, libavdevice.so.54 лежит в /111/usr/lib64/

самый простой сбособ таскать so-шки и указывать LD_PRELOAD

можно поподробней? куда тпскать? libavdevice.so.54 в /111/usr/lib64 лежит, но не видится почкему-то.

./configure --prefix=$HOME/bin

запускай от юзера, потом затарь /bin/

а вот статически не нужно, ибо обычно и так работает. Если не работает, то это специальный случай, и нужно конкретно разбираться.

почему? гента разве не рулит?

для ТАКОЙ хотелки — не рулит. Тебе маздай нужен. Не хочешь готовый, делай маздай из слаки. Быстрее получается, я проверял.

Нужно скомпмилировать статически, чтобы потом /111 можно было перенести в другой дистр и там работало. В старом минте ffmpeg кривой. В гентушном чруте хочу как-то скомпилировать, чтобы можно было использовать в минте.

скомпилируй динамически, и тащи либу вместе с программой. Хотя я очень сомневаюсь, что у тебя это получится. Вангую, что тебе ещё придётся glibc с ядром тащить с ТАКИМ подходом.

статические не более переносимые и независимые?

наоборот. Статические только на твоём локалхосте будут работать.

чтоб я получил ответ по компиляции первого прохода в LFS

это специфический случай. Ты собираешь систему Б в системе А. Причём с нуля. Потому первым твоим шагом будет сборка glibcБ, а потом сборка компилятора с glibcБ(а не с glibcА, по религиозным соображениям).

Gentoo Prefix, хотя это немного не то. Конкретнее - ~amd64-linux или ~x86-linux.

сборка компилятора с glibcБ(а не с glibcА

кажется понял.

В линуксе давно убили понятие «статически» благодаря усилиям Столлмана и его сподвижников. Все жестко упрется в glibc даже для статичских программ.

Потому первым твоим шагом будет сборка glibcБ, а потом сборка компилятора с glibcБ(а не с glibcА, по религиозным соображениям).

и всё-таки я не понял, почему если два раза подряд скомпилировать динамически, эффект не будет тот же? разве во втором проходе компилятор не будет в любом случае использовать glibcБ?

и всё-таки я не понял, почему если два раза подряд скомпилировать динамически, эффект не будет тот же? разве во втором проходе компилятор не будет в любом случае использовать glibcБ?

ну откуда компилятор узнает, что ты новую glibcБ собрал? Тебе нужно собирать gccБ с glibcБ используя gccА с glibcA. Проще всего это статически сделать. (я точно сам не помню, лет 5 назад LFS собирал. В районе Xorg забил, надоело)

В линуксе давно убили понятие «статически» благодаря усилиям Столлмана и его сподвижников. Все жестко упрется в glibc даже для статичских программ.

ну и что в этом плохого? На кой ляд нужно Over9000 вариантов одной и той же memcpy(3)? (их и в одной glibc немало, кстати).

Плохо то, что ТС хочет получить то, что некоторые дяди загубили на корню. Для него ответ один: собирай на целевой машине и нии..т

ну можно ещё в chroot'е собрать. Вот firefox у меня как-то работает? Скачал с сайта tar.gz, распаковал в $HOME, УМВР, ЧЯДНТ?

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

В твоем случае что показывает file firefox?

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

я так думаю, что glibc должна быть ОЧЕНЬ старой, что-бы возникли проблемы. Даже УГ мамонта вроде unrar'а/скайпа работает без проблем. Только не говори мне, что там libc статикой.

$ ldd /usr/bin/unrar 
	linux-gate.so.1 (0xffffe000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb76d5000)
	libm.so.6 => /lib/libm.so.6 (0xb7693000)
	libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb7677000)
	libc.so.6 => /lib/libc.so.6 (0xb74ec000)
	/lib/ld-linux.so.2 (0xb77d6000)

$ file ~/bin/firefox/firefox
/home/drb/bin/firefox/firefox: ELF 32-bit LSB  executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), BuildID[sha1]=af1a44bd835acdf2064a9c82c58c3eff2aa21449, stripped

ну откуда компилятор узнает, что ты новую glibcБ собрал?

а если ститически, а потом второй раз ведь всё-равно будет динамически, как он узнает?

а потом второй раз ведь всё-равно будет динамически

не. Статика она безусловная. Если у тебя статически, то динамические оно никогда не увидит. И даже смотреть не будет.

У тебя все собрано «динамикой», о чем спорим? :)

P.S. Ты попутал rar vs unrar ;)

P.S.II. Скайп содержит внутри питон ;)

ЯННП

У тебя все собрано «динамикой», о чем спорим?

я и говорю: статика не нужна. Я не понимаю, почему ты страдаешь?

P.S. Ты попутал rar vs unrar ;)

нет, я про unrar.

P.S.II. Скайп содержит внутри питон ;)

не только.

so ищутся и включаются ПОСЛЕ запуска программы. А статика ДО запуска вкомпилливается. Т.е. если программа юзает memcpy(3) из glibc, то эта функция будет В САМОЙ программе забита. А если so, то в программе её не будет, и система будет загружать свою glibc. Список системных so можно посмотреть так: ldd /usr/bin/программа Если всё в статике, там будет почти пусто.

Я не понимаю, почему ты страдаешь?

:D

Ты топик читал?

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

топики я читаю. Всегда читаю. Но обычно мне до☣. Иногда даже путаю, куда отвечаю. Получается кстати весело.

если честно, я не помню, на каком там проходе новый gcc.

и всё же почему оно не увидело libavdevice.so.54?
надо было EPREFIX=, а не PREFIX=?

и как-то можно одной строкой установить в /111 все зависимости вместе с их зависимостями? Gentoo Prefix разве не новый stage создаёт? и будет ли оно потом работать из /111 в новой системе?

на каком там проходе новый gcc

ну на первом создаётся статически.
на втором — статическим собирается динамический gcc, и вся система.
или всё же там новый динамический gcc как-то используется? он же не сможет подгрузить новый динамический libc без перезагрузки в эту новую системе, верно?

или всё же там новый динамический gcc как-то используется? он же не сможет подгрузить новый динамический libc без перезагрузки в эту новую системе, верно?

может. Из другого каталога. Причём даже с другой архитектурой (32х битный gcc может загрузить 32х битные либы в 64х битной ОС)

может

тогда я опять ЯННП. зачем мы сначала статически gcc собираем, а потом динамически?

если я ничего не путаю, то на втором проходе мы уже в chroot'е, и брать можно только ту glibc, что мы на первом проходе собирали. Выбора нет.

Ну а на первом проходе выбор есть, причём нам хочется, что-бы оно брало либы из /lib(как обычно), а там системные уже лежат. Не, ну можно настроить выбор из какой-нить /lib_lfs, но потом пересобирать надо будет. Или в нашем lfs так и будут либы в /lib_lfs, а не как у всех, в /lib.

если я ничего не путаю, то на втором проходе мы уже в chroot'е, и брать можно только ту glibc, что мы на первом проходе собирали. Выбора нет.

да, но для первого прохода

может. Из другого каталога

можно использовать динамическую линковку с тем же результатом?

может. Из другого каталога

можно использовать динамическую линковку с тем же результатом?

можно. Два варианта: перестроить ldconfig в хосте. Другой вариант — другой каталог, не такой как в хосте. Но если хочется такой же потом получить, придётся третий раз пересобирать ☺