[rpmbuild] Smplayer Na X86_64 (athlon)

[@WalDo]

Przesiadłem się niedawno na nowszy nieco sprzęt: Athlon X2 BE-2350, więc i F8 64-bit.

Ponieważ w repozytoriach nie ma wciąż mojej ulubionej nakładki na mplayer (smplayer.sf.net) postanowiłem sam przebudować paczkę. W smplayer-0.6.0rc2.tar.bz2 jest plik .spec, więc nie przerabiając go wrzuciłem do podkatalogu SPEC, paczka ze źródłami do SOURCE i dalej standardowo jadę sobie

rpmbuild -bb SPECS/smplayer.spec

No i na wersji 32-bit wszystko chodziło ładnie (po instalacji qt4 i qt4-devel oraz ustawieniu ścieżek do qmake) a obecnie wyrzuca mi w którymś momencie

/usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory
make[1]: *** [.obj/version.o] Error 1
make[1]: Leaving directory `/home/waldo/rpm/BUILD/smplayer-0.6.0rc2/src'
make: *** [src/smplayer] Error 2
błąd: Błędny stan wyjścia z /var/tmp/rpm-tmp.70017 (%build)

No i tu ściana. Oczywiście pliku stubs-32.h nie ma. Jest stubs-64.h, do tego stubs.h o treści sugerującej umiejętność rozróżnienia pomiędzy 32-bit a 64-bit

[...]
#if __WORDSIZE == 32
# include <gnu/stubs-32.h>
#elif __WORDSIZE == 64
# include <gnu/stubs-64.h>
[...]

ale mimo to kompilacja szuka stubs-32. Nie sądzę, żeby dobrym pomysłem była podmiana glibc-devel dla x86_64 na paczkę dla i386

Próbowałem w rpmbuild wskazywać target i386 oraz x86_64, ale za każdym razem wysypywało się w tym samym miejscu.

W końcu próbowałem oszukiwać wpisując w stubs.h zamiast stubs-32.h - stubs-64.h. Efektu można się było domyślić jeszcze przed rozpoczęciem kompilacji...

 

Mam oczywiście paczkę *.rpm skompilowaną jeszcze na starym systemie 32-bitowym i spokojnie ją instaluję i działa, ale chciałbym wiedzieć jak mógłbym sobie poradzić z takim błędem w przyszłości

[ecik__]

Ja też mam komputer 64-bitowy i po poprawieniu sprawy z qt4 u mnie kompiluje sie bez problemu. Wygląda na to, że powinieneś wkleić większy fragment kodu, gdy się wywala kompilacja. Najlepiej od linijki, gdy smplayer wywołuje ostatnie g++ do błędu. To powinno rozjaśnić sytuację.

[@WalDo]

Wywala się włąściwie na samym początku. Rozpakowuje źródła do BUILD i zaraz potem pierwsze polecenie g++

cd src && qmake  && DATA_PATH=\\\"/usr/share/smplayer\\\" CONF_PATH=\\\"/usr/etc/smplayer\\\" TRANSLATION_PATH=\\\"/usr/share/smplayer/translations\\\" DOC_PATH=\\\"/usr/share/doc/packages/smplayer\\\" THEMES_PATH=\\\"/usr/share/smplayer/themes\\\" SHORTCUTS_PATH=\\\"/usr/share/smplayer/shortcuts\\\" make
make[1]: Entering directory `/home/waldo/rpm/BUILD/smplayer-0.6.0rc2/src'
/usr/lib/qt4/bin/uic inputdvddirectory.ui -o .ui/ui_inputdvddirectory.h
/usr/lib/qt4/bin/uic logwindowbase.ui -o .ui/ui_logwindowbase.h
/usr/lib/qt4/bin/uic filepropertiesdialog.ui -o .ui/ui_filepropertiesdialog.h
/usr/lib/qt4/bin/uic eqslider.ui -o .ui/ui_eqslider.h
/usr/lib/qt4/bin/uic seekwidget.ui -o .ui/ui_seekwidget.h
/usr/lib/qt4/bin/uic inputurl.ui -o .ui/ui_inputurl.h
/usr/lib/qt4/bin/uic preferencesdialog.ui -o .ui/ui_preferencesdialog.h
/usr/lib/qt4/bin/uic prefgeneral.ui -o .ui/ui_prefgeneral.h
/usr/lib/qt4/bin/uic prefdrives.ui -o .ui/ui_prefdrives.h
/usr/lib/qt4/bin/uic prefinterface.ui -o .ui/ui_prefinterface.h
/usr/lib/qt4/bin/uic prefperformance.ui -o .ui/ui_prefperformance.h
/usr/lib/qt4/bin/uic prefinput.ui -o .ui/ui_prefinput.h
/usr/lib/qt4/bin/uic prefsubtitles.ui -o .ui/ui_prefsubtitles.h
/usr/lib/qt4/bin/uic prefadvanced.ui -o .ui/ui_prefadvanced.h
/usr/lib/qt4/bin/uic about.ui -o .ui/ui_about.h
/usr/lib/qt4/bin/uic inputmplayerversion.ui -o .ui/ui_inputmplayerversion.h
g++ -c -pipe -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Wall -W -D_REENTRANT -DDATA_PATH=\"/usr/share/smplayer\" -DDOC_PATH=\"/usr/share/doc/packages/smplayer\" -DTRANSLATION_PATH=\"/usr/share/smplayer/translations\" -DCONF_PATH=\"/usr/etc/smplayer\" -DTHEMES_PATH=\"/usr/share/smplayer/themes\" -DSHORTCUTS_PATH=\"/usr/share/smplayer/shortcuts\" -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -I/usr/lib/qt4/mkspecs/linux-g++ -I. -I/usr/include/QtCore -I/usr/include/QtCore -I/usr/include/QtNetwork -I/usr/include/QtNetwork -I/usr/include/QtGui -I/usr/include/QtGui -I/usr/include -I.moc -I.ui -o .obj/version.o version.cpp
In file included from /usr/include/features.h:359,
                from /usr/include/string.h:26,
                from /usr/include/QtCore/qbytearray.h:43,
                from /usr/include/QtCore/qstring.h:41,
                from /usr/include/QtCore/QString:1,
                from version.h:22,
                from version.cpp:19:
/usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory
make[1]: *** [.obj/version.o] Error 1
make[1]: Leaving directory `/home/waldo/rpm/BUILD/smplayer-0.6.0rc2/src'
make: *** [src/smplayer] Error 2
błąd: Błędny stan wyjścia z /var/tmp/rpm-tmp.39083 (%build)


Błędy budowania RPM-a:
   Błędny stan wyjścia z /var/tmp/rpm-tmp.39083 (%build)

[Adi1981]

Może spróbuj po prostu oszukać kompilator? Np

#if __WORDSIZE == 32
# include <gnu/stubs-64.h>
#elif __WORDSIZE == 64
# include <gnu/stubs-64.h>

[ecik__]

g++ -c -pipe -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 (...)

Jak widać, próbuje budować dla i386. Oznacza to, że są podane niepoprawne flagi. Zobacz co wypisuje

rpm --eval "%{optflags}"

Jeżeli wypisze coś innego niż -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic to zobacz czy przypadkiem nie masz flag zdefiniowanych w ~/.rpmmacros. Jeśli masz to usuń wpis z flagami. Jeśli nie - to zobacz wynik polecenia

rpm --eval "%{_arch}"

Jeśli w tym miejscu będzie wynik inny x86_64, to chyba trzeba sprawdzić co wychodzi z

uname -mp

 

EDIT:

Może spróbuj po prostu oszukać kompilator?

Podany fragment kodu pochodzi z pliku /usr/include/gnu/stubs.h czyli należącego do paczki glibc-headers. Naprawdę - lepiej tego nie zmieniać

[@WalDo]

No to mi tak odpowiedziało:

[waldo@localhost rpm]$ rpm --eval "%{optflags}"
-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
[waldo@localhost rpm]$ uname -ap
Linux localhost.localdomain 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:03:13 EST 2008 x86_64 x86_64 x86_64 GNU/Linux

 

@Adi1981 - pisałem, że próbowałem tak zrobić (przywróciłem teraz oczywiście oryginalną kopię pliku).

 

[EDIT]oczywiście dałem opcję "-a" zamiast "-m", ale wynik widać - "x86_64 x86_64"

[ecik__]

Jest jeszcze jedna możliwość. Pisałeś, że zmieniałeś coś ze ścieżkami z qmake. Co konkretnie zrobiłeś? Na jaką ścieżkę wskazałeś?

[@WalDo]

Przed wydaniem polecenia rpmbuild ustawiłem ścieżkę:

 export PATH=$PATH:/usr/lib/qt4/bin

Inaczej miałem błędy - brak qmake, lrelease

[EDIT]

Może powinienem wskazać na inną ścieżkę albo na qmake-qt4?

[waldo@localhost smplayer-0.6.0rc2]$ locate qmake
/usr/bin/qmake-qt4
/usr/lib/qt4/bin/qmake
/usr/lib/qt4/bin/qmake-qt4
[...]
[waldo@localhost smplayer-0.6.0rc2]$ locate lrelease
/usr/bin/lrelease-qt4
/usr/lib/qt4/bin/lrelease
/usr/lib/qt4/bin/lrelease-qt4
/usr/lib64/qt4/bin/lrelease
/usr/lib64/qt4/bin/lrelease-qt4

 

[EDIT2]Poszło dalej. Tym razem nie dodawałem ścieżki /usr/lib/qt4/bin a zamiast tego zrobiłem linki

ln -s /usr/bin/qmake-qt4 /usr/bin/qmake
ln -s /usr/bin/lrelease-qt4 /usr/bin/lrelease

Zobaczymy czy jak to się skończy

[ecik__]

Przed wydaniem polecenia rpmbuild ustawiłem ścieżkę:

 export PATH=$PATH:/usr/lib/qt4/bin

Inaczej miałem błędy - brak qmake, lrelease

Zauważ, że wskazujesz na /usr/lib. A chcesz to mieć na 64 bity. To wskaż na /usr/lib64/qt4/bin. I powinno działać

EDIT

Poszło dalej. Tym razem nie dodawałem ścieżki /usr/lib/qt4/bin a zamiast tego zrobiłem linki

ln -s /usr/bin/qmake-qt4 /usr/bin/qmake
ln -s /usr/bin/lrelease-qt4 /usr/bin/lrelease

Zobaczymy czy jak to się skończy

W tym przypadku skończy się pewnie dobrze, ale w innych niekoniecznie... Wciąż sporo aplikacji pisanych jest pod qt3, więc nie możesz wymuszać wszystkim kompilowalność na qt4. Najlepszym rozwiązaniem wszystkich problemów z tą paczką jest prosta zmiana w specu.

W miejsce:

make PREFIX=/usr

wystarczyło wpisać:

make PREFIX=/usr QMAKE=qmake-qt4

I działa

[@WalDo]

To wskaż na /usr/lib64/qt4/bin. I powinno działać

O, rany ... Dzięki

Ale z tymi linkami, o których wspomnialem powyżej poszło i utworzyło RPM w RPMS/x86_64. Oczywiście zaraz sprawdzę "po Bożemu", bo lepiej jednak mieć porządek w systemie

 

[EDIT]OK Usunąłem te dwa dowiązania do qmake-qt4 i lrelease-qt4, dodałem do ścieżki wskazanie na poprawne binaria z lib64 i mam paczuszkę

Dzięki ecik__ za pomoc.

[matlas]

O, rany ... Dzięki

Ale z tymi linkami, o których wspomnialem powyżej poszło i utworzyło RPM w RPMS/x86_64. Oczywiście zaraz sprawdzę "po Bożemu", bo lepiej jednak mieć porządek w systemie

 

[EDIT]OK Usunąłem te dwa dowiązania do qmake-qt4 i lrelease-qt4, dodałem do ścieżki wskazanie na poprawne binaria z lib64 i mam paczuszkę

Dzięki ecik__ za pomoc.

 

Moze bys ja wystawil dla 64 bit?

 

Dla 32bit ładnie śmiga ta: http://www.deadbabylon.de/fedora/repositor...rc2.fc8.src.rpm

[@WalDo]

Moze bys ja wystawil dla 64 bit?

Jest tutaj → http://www.wrzucaj.com/150875

To jakis darmowy hosting, więc

Jak pobierać pliki?

Po wejściu na stronę z plikiem należy odczekać 45 sekund, po czym wyświetli się link do pobierania. Klikamy na wygenerowany link i zapisujemy plik na naszym komputerze.

 

[EDIT - Off Topic]

Znacie może jakieś fajne hostingi plików. Tylko żeby nie było jakichś tam ograniczeń jak na RapidShare, MegaUpload czy innych tego typu gdzie darmowe konta wymagają odczekania kilka godzin albo instalowania jakiegoś badziewia typu MegaUpload Toolbar. Znalazlem listę takich miejsc → http://www.diromo.com ale sporo tego żeby przetestować, więc jakby ktoś miał jakiś wypróbowany, to podawajcie od razu jaka jest max. wielkość plików, jakie są ograniczenia (jak na wrzucaj.com te 45 sek. na przykład) itp.

[gregor_szczecin]

To tak tylko dla tych, co nie lubią czekać. Plik mozna pobrać stąd bez obraniczeń.

Oczywiście to ten plik od WalDo

pozdrawiam

[ecik__]

Znacie może jakieś fajne hostingi plików. Tylko żeby nie było jakichś tam ograniczeń jak na RapidShare, MegaUpload czy innych tego typu gdzie darmowe konta wymagają odczekania kilka godzin albo instalowania jakiegoś badziewia typu MegaUpload Toolbar. Znalazlem listę takich miejsc → http://www.diromo.com ale sporo tego żeby przetestować, więc jakby ktoś miał jakiś wypróbowany, to podawajcie od razu jaka jest max. wielkość plików, jakie są ograniczenia (jak na wrzucaj.com te 45 sek. na przykład) itp.

Polecam http://nonlogic.org. Konto shellowe, dwa giga quoty, ale nie wolno używać np. do IRC-a. W każdym razie za hosting plików, nadaje się idealnie

[@WalDo]

Polecam http://nonlogic.org.

Myślałem raczej o czymś łatwodostępnym, niewymagającym rejestracji, z możliwością łatwego wrzucenia pliku i przekazania komuś linku - coś w rodzaju wrzucaj.com właśnie, ale z jak najmniejszymi utrudnieniami dla ściągających pliki (chociaż w sumie oczekiwanie 45 sekund na możliwość pobrania pliku da się przeżyć).