Amarok 1.4.10 static build

[АПП]

Кто-нибудь смог собрать статически Amarok 1.4.10? Я сегодня весь день потратил, но нужного результата так и не добился.

Например, вот такая проблема сборки имеет место:

[vuohi@mandriva loader]$ /bin/sh ../../../libtool --tag=CXX --mode=link g++ -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -O2 -static -r -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -L/opt/kde3/lib -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -o amarok loader.o -lqt-mt -ljpeg -lz -lpng -lz -lm -lXext -lX11 -lSM -lICE -lpthread -lkdeui

g++ -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -O2 -r -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -Wl,--as-needed -Wl,--no-undefined -Wl,-z -Wl,relro -o amarok loader.o -L/opt/kde3/lib -L/usr/lib -lm /opt/kde3/lib/libkdeui.a /opt/kde3/lib/libkdecore.a -L/usr/kerberos/lib /opt/kde3/lib/libDCOP.a -lutil /usr/lib/libart_lgpl_2.a /usr/lib/libidn.a /opt/kde3/lib/libkdefx.a /usr/lib/libqt-mt.a /usr/lib/libmng.a /usr/lib/liblcms.a /usr/lib/libjpeg.a /usr/lib/libXrandr.a /usr/lib/libXcursor.a /usr/lib/libXfixes.a /usr/lib/libXinerama.a /usr/lib/libXft.a /usr/lib/libfontconfig.a /usr/lib/libfreetype.a /usr/lib/libxml2.a -lpng -lz /usr/lib/libXext.a /usr/lib/libSM.a /usr/lib/libICE.a -lpthread /usr/lib/libXrender.a /usr/lib/libX11.a /usr/lib/libxcb.a /usr/lib/libXau.a /usr/lib/libXdmcp.a /usr/lib/libldap.a /usr/lib/liblber.a /usr/lib/libsasl2.a -ldl -lssl -lcrypto -lresolv

/opt/kde3/lib/libkdecore.a(ltdl.o): In function `sys_dl_open':
/home/vuohi/rpm/BUILD/kdelibs-3.5.10/libltdl/ltdl.c:614: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

/usr/bin/ld: cannot find -lgcc_s

collect2: выполнение ld завершилось с кодом возврата 1

Не пойму, в чём именно проблема. Явно не в том, что на самом деле надо линковать amarok с libgcc_s.

[rpk]

Кто-нибудь смог собрать статически Amarok 1.4.10? Я сегодня весь день потратил, но нужного результата так и не добился.

Ы. А нафига сие?

Не пойму, в чём именно проблема.

Ну дыr все сказали же:

/usr/bin/ld: cannot find -lgcc_s

[АПП]

Ы. А нафига сие?

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

Ну дыr все сказали же:

/usr/bin/ld: cannot find -lgcc_s

Полагаю, он и не должен искать libgcc_s.a. И если собирать с ключом -static-libgcc, то на -lgcc_s линковщик больше не ругается, но в конце концов получаются бинарники, которые не запускаются по причине "невозможно найти файл или каталог".

Попробую из спортивного интереса сгенерировать Makefile'ы таким образом, чтобы статически линковались только библиотеки kde3. Видимо, простое использование "-static -r" - это неправильный способ статической сборки.

[АПП]

Собрал его статически (вышел 70-меговый бинарник), но пользоваться всё равно нельзя - как оказалось, ему нужны запущенные dcopserver и ksycoca, без них работать не желает.

[l1feh4ck3r]

Собрал его статически (вышел 70-меговый бинарник)

Фигасебе. Да он половину кед в себя втянул...

[АПП]

Фигасебе. Да он половину кед в себя втянул...

Ага. Поначалу у меня была мысль начать переписывать его так, чтобы постепенно отвязать от KDE вообще (какие-то куски кода выкинуть, какие-то переписать, какие-то скопипастить из kde-шных исходников). Но даже чтения исходников по диагонали хватило для того, чтобы понять, что переписывать там нечего, можно только с нуля писать, потому что там всё завязано на KDE. Даже там, где это нафиг не надо (например, для генерации имени файла вида 00008ccfb6ae80e4ead2d88ea5f079c2, в который сохраняется обложка альбома, используется kmdcodec).

[rpk]

Полагаю, он и не должен искать libgcc_s.a. И если собирать с ключом -static-libgcc, то на -lgcc_s линковщик больше не ругается, но в конце концов получаются бинарники, которые не запускаются по причине "невозможно найти файл или каталог".

Нуууу, если нет файла который ему требуется открыть это вполне все объясняет.

`sys_dl_open':
/home/vuohi/rpm/BUILD/kdelibs-3.5.10/libltdl/ltdl.c:614: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

Если ему требуется .so, то неважно как оно скомпилено - ему всеравно при вызове dlopen потребуется открывать эту библиотеку

[АПП]

Если ему требуется .so, то неважно как оно скомпилено - ему всеравно при вызове dlopen потребуется открывать эту библиотеку

Ну libgcc_s.so на месте, просто с ключами "-static -r" с .so ничего не линкуется, всё линкуется с .a. Libtool не умеет гибко определять, что динамически линковать, а что статически. В итоге там по зависимостям доходит до библиотек, для которых просто нет статических вариантов (krb5 1.6, например) и всё стопорится.