Przejdź do głównej zawartości

Program nie może się uruchomić, bowiem brakuje jakiejś biblioteki

Osoby użytkujące Arch Linux w stabilnej wersji nigdy nie powinny się spotkać z omawianym tu "błędem". Niemniej jednak tylko wówczas, gdy ograniczą się do stosowania programów znajdujących się w oficjalnych repozytoriach. Tu bowiem osoby odpowiedzialne za utrzymywanie paczek, z chwilą, gdy dochodzi do zmian jakichś bibliotek dbają o przebudowanie paczek i dostosowanie ich do nowych wersji. Niemniej jednak wielu z używających Archa buduje paczki także z AUR. Najczęściej to właśnie programy pochodzące z AUR nagle zaprzestaną działać. Przypomnę, albowiem szczególnie dla osób, które zmieniły dystrybucję z *buntupochodnych na Archa, czy - częściej - Manjaro: w AUR nie znajdują się żadne paczki. Tu są wyłącznie "przepisy" na podstawie których następuje lokalne budowanie paczki i jej instalacja. Jeśli jednocześnie opiekun takiej aplikacji w AUR "nie zauważy", że dokonane zostały jakieś zmiany w repozytoriach, które wymagają jego reakcji lub nawet pomimo tego, my nie przebudujemy takiej paczki, to spotkać się możemy z sytuacją, w której wczoraj jeszcze działająca aplikacja nagle przestała działać. Uruchamiając taką aplikację w środowiskach graficznych najczęściej po prostu nic się nie wydarzy. Klikniemy na nazwę aplikacji, ta jakby się uruchamiała, ale po chwili nie ma jej śladu.
W takiej sytuacji najlepiej jest wywołać program z konsoli. Wówczas - być może - czegoś się dowiemy. Bardzo często będzie to informacja typu ("foo" jest tu dowolną nazwą):
(...) /usr/lib/foo.so.1 don't exist
Jeśli zobaczymy, że jest to jakiś plik, którego rozszerzenie to so, so.CYFRA, to chodzi o to, że program, który uruchamiamy - jeśli wcześniej się uruchamiał - nie jest przeznaczony do działania z wersją biblioteki, jaką mamy aktualnie w systemie. Jeśli w konsoli nie uzyskamy informacji o miejscu położenia biblioteki, to w pierwszej kolejności lokalizujemy ją. Skorzystamy z polecenia locate (jeśli ktoś w systemie nie ma, to można zainstalować paczkę mlocate, bądź posłużyć się jakimkolwiek innym programem przeszukującym dysk za plikami, np. na pewno zainstalowanym find).
locate foo.so.1
W ten sposób uzyskamy lokalizację tej biblioteki. Teraz korzystamy z pacmana:
pacman -Qo /usr/lib/foo.so.1
W wyniku uzyskamy informację do jakiej paczki należy /usr/lib/foo.so.1. Powiedzmy, że jest to paczka foo w wersji 1.2.3.
Przydałoby się dowiedzieć jaką wersję tej paczki oferuje Arch w repozytorium stabilnym i pozostałych. Znów skorzystamy z pacmana bądź yaourta:
pacman -Ss foo
lub jeśli mamy ją z AUR np.:
yaourt foo
Powinno nas to naprowadzić na to, skąd mamy zainstalowaną paczkę. Możemy jeszcze sprawdzić informacje o tym czyją jest zależnością, czy też w jaki sposób została ona zainstalowana:
pacman -Qi foo
Możemy przeglądnąć również dziennik logów pacmana, by dowiedzieć się kiedy, przy jakiej okazji tę paczkę zainstalowaliśmy. Znajduje się on w pliku /var/log/pacman.log. Jest to plik tekstowy, zatem przeglądać można go w dowolny sposób. W AUR znajduje się jednak wygodna przeglądarka tego pliku o nazwie pacmanviewer.
Wyposażeni w taką wiedzę powinniśmy teraz zadecydować, czy:
- cofnąć paczkę do działającej wersji (ale uwaga, wówczas inny program, który ściągnął właśnie tę bibliotekę w obecnej wersji może przestać działać),
- spróbować skompilować niedziałający program w oparciu o nową bibliotekę,
- (tak są jeszcze inne rozwiązania, ale na tyle ryzykowne i niepolecane, że nie będę o nich pisać; część z nas je zna, jeśli zna, to te rozwiązania są wyłącznie do nich adresowane, albowiem trzeba być bardzo mocno świadomym, co robimy i dlaczego; w związku z tym nie będę ich tu polecać).
Pierwsze dokonujemy - najwygodniej - narzędziem downgrade (jest w AUR). W drugim przypadku polecam następujące działanie:
yaourt -G foo && cd foo
Ściągnęliśmy "przepisy" umożliwiające budowę paczki i przeszliśmy do katalogu, w którym się one znajdują.
Teraz trzeba przeglądnąć PKGBUILD, albowiem, być może będzie on wymagać właśnie określonej wersji biblioteki. Jeśli tak jest możemy spróbować z wersjami rozwojowymi (git, svn, bzr itp.), albo udać się na stronę programu, gdzie być może uzyskamy jakieś informacje. Po ewentualnym dostosowaniu PKGBUILDu wydajemy polecenie:
makepkg -si
To oczywiście pewien schemat działania. Nie zawsze pomoże. Nie jest nawet w 100% polecany (albowiem niekiedy programy są przeznaczone do pracy z określonymi wyłącznie bibliotekami). Jeśli się powiodło - fajnie. Jeśli nie - trzeba szukać jakiegoś innego rozwiązania.

Komentarze

Popularne posty z tego bloga

Na prostej drodze do wysypania Manjaro

Do napisania dzisiejszego wpisu zainspirował mnie jeden z wątków na forum manjaro.pl. Otóż jeden z użytkowników Manjaro chciał zainstalować spotify, którego PKGBUILD dostępny jest w AUR. Akurat ta paczka powstaje przez przebudowanie udostępnianej przez Spotify paczki deb na paczkę Archa. Niestety od pewnego czasu spotify z udostępnionego PKGBUILDu gdyż wersja to 1.0.92.x, która nie jest już dłużej udostępniana przez Spotify. Obecnie udostępniane są 3 paczki, przy czym dla wspieranej architektury w Archu to wyłącznie 1.0.80.x oraz najnowsza 1.0.94.x. Instalacja zatem z takiego PKGBUILDu nie ma najmniejszych szans powodzenia.
Autor wątku chce zaktualizować paczkę, stąd też domniemuję, że jakąś wersję spotify ma.
Inny forumowicz poleca zatem... dodanie repozytorium nexus do systemu (uwaga - poleca dodanie repozytorium budowanego dla Archa do Manjaro!!!), albowiem w tym repozytorium jest najnowsza wersja spotify.
Autor zastanawia się jednak, czy jest to bezpieczne i dochodzi do wniosku, ż…

Plasma i Strażnik Krypt

W czasach, gdy nasza prywatność jest wystawiana na ciężką próbę, jeden z deweloperów KDE postanowił dodać do Plasmy możliwość dość łatwej obsługi szyfrowanych, wirtualnych "katalogów" - krypt, jak je nazywa. Sam projekt nazywa się plasma-vault i po około 3 miesiącach rozwijania pojawiła się w repozytorium unstable KDE najpierw jego wersja 5.9.95, a obecnie 5.9.96. Jak wskazuje numer wersji (choć ten został nadany nie przez opiekuna, ale przez wszędobylskiego Jonathana Riddella), aplikacja była planowana jako część Plasma 5.10. Tak się jednak z jakichś przyczyn nie stało. Obecnie jest ona planowana, jako część nadchodzącego wydania 5.11. Sam program w Archu dostępny jest w AUR. Buduje się całkiem żwawo i działa na tyle, by można zaryzykować jeśli nie używanie, to przynajmniej sprawdzenie działania i zgłoszenie ewentualnych błędów deweloperom. Pamiętajcie by czytać to co po pacman pisze przy instalacji. Program do prawidłowej funkcjonalności potrzebuje bądź encfs bądź cryfs. …

MEGA a sprawa Arch Linux

Mniejsza o to, czy MEGA to popularny, czy godny zaufania itd. itp. dostarczyciel przestrzeni w chmurze. Fakt, że po moich doświadczeniach z dropboksem nie chcę mieć więcej z nim nic wspólnego. Może zatem MEGA, do którego mam dostęp niemal od samego początku? Miłym dodatkiem do MEGA może okazać się uruchomione repozytorium oferujące sam program synchronizujący (megasync) oraz dodatki dla trzech, chyba najpopularniejszych, menedżerów plików: Dolphin, Nautilus i Thunar, umożliwiające synchronizację z plików z ich poziomu. Jest to o tyle miłe, że do tej pory musieliśmy kompilować te programy z AUR, a nadto w przypadku megasync wersja oferowana w repozytorium jest nowsza, zaś dolphin-megasync obecnie w ogóle się nie kompiluje. Chcąc dodać repozytorium MEGA do pacmana, edytujemy plik /etc/pacman.conf i gdzieś na końcu listy dodajemy: [DEB_Arch_Extra]SigLevel = Optional TrustAllServer = https://mega.nz/linux/MEGAsync/Arch_Extra/x86_64/ Nadto musimy jeszcze dodać klucz: gpg --receive-keys BF…