Próbuję zaimportować pycurl
:
$ python -c "import pycurl"
Traceback (most recent call last):
File "<string>", line 1, in <module>
ImportError: libcurl.so.4: cannot open shared object file: No such file or directory
Teraz libcurl.so.4
jest w /usr/local/lib
. Jak widać, jest to sys.path
:
$ python -c "import sys; print(sys.path)"
['', '/usr/local/lib/python2.5/site-packages/setuptools-0.6c9-py2.5.egg',
'/usr/local/lib/python25.zip', '/usr/local/lib/python2.5',
'/usr/local/lib/python2.5/plat-linux2', '/usr/local/lib/python2.5/lib-tk',
'/usr/local/lib/python2.5/lib-dynload',
'/usr/local/lib/python2.5/sitepackages', '/usr/local/lib',
'/usr/local/lib/python2.5/site-packages']
Każda pomoc będzie bardzo mile widziana.
LD_LIBRARY_PATH
poprawnie (myślałem, że w Twoim komentarzu brakuje dwukropka).Odpowiedzi:
sys.path
jest przeszukiwany tylko pod kątem modułów Pythona. W przypadku dynamicznie połączonych bibliotek przeszukiwane ścieżki muszą znajdować się wLD_LIBRARY_PATH
. Sprawdź, czyLD_LIBRARY_PATH
zawiera/usr/local/lib
, a jeśli nie, dodaj go i spróbuj ponownie.Więcej informacji ( źródło ):
Aktualizacja: aby ustawić
LD_LIBRARY_PATH
, użyj jednego z następujących, najlepiej w swoim~/.bashrc
lub równoważnym pliku:lub
Użyj pierwszej formy, jeśli jest pusta (odpowiednik pustego ciągu lub w ogóle go nie ma), a drugiej, jeśli nie jest. Zwróć uwagę na wykorzystanie eksportu .
źródło
Upewnij się, że moduł libcurl.so znajduje się w ścieżce biblioteki systemowej, która jest odrębna i oddzielna od ścieżki biblioteki Pythona.
„Szybkim rozwiązaniem” jest dodanie tej ścieżki do zmiennej LD_LIBRARY_PATH. Jednak ustawienie tego systemu dla całego systemu (lub nawet konta) jest ZŁYM POMYSŁEM, ponieważ można to ustawić w taki sposób, że niektóre programy znajdą bibliotekę, której nie powinny, a co gorsza, otwierać luki w zabezpieczeniach.
Jeśli Twoje „biblioteki zainstalowane lokalnie” są zainstalowane na przykład w / usr / local / lib, dodaj ten katalog do /etc/ld.so.conf (jest to plik tekstowy) i uruchom „ldconfig”
Polecenie uruchomi narzędzie buforujące, ale utworzy również wszystkie niezbędne „dowiązania symboliczne” wymagane do działania systemu ładującego. Zaskakujące jest, że polecenie „make install” dla libcurl jeszcze tego nie zrobiło, ale możliwe, że nie mógł, gdyby / usr / local / lib nie znajdowało się już w /etc/ld.so.conf.
PS: możliwe, że plik /etc/ld.so.conf zawiera tylko „include ld.so.conf.d / *. Conf”. Nadal możesz dodać ścieżkę do katalogu po nim lub po prostu utworzyć nowy plik w katalogu, z którego jest dołączany. Nie zapomnij uruchomić po nim "ldconfig".
Bądź ostrożny. Złe popełnienie tego błędu może zepsuć system.
Dodatkowo: upewnij się, że Twój moduł Pythona jest skompilowany w TEJ wersji libcurl. Jeśli właśnie skopiowałeś jakieś pliki z innego systemu, to nie zawsze zadziała. W razie wątpliwości skompiluj swoje moduły w systemie, w którym zamierzasz je uruchomić.
źródło
Możesz również ustawić LD_RUN_PATH na / usr / local / lib w swoim środowisku użytkownika podczas kompilowania pycurl w pierwszej kolejności. Spowoduje to osadzenie / usr / local / lib w atrybucie RPATH modułu rozszerzającego C, dzięki czemu automatycznie będzie wiedział, gdzie znaleźć bibliotekę w czasie wykonywania, bez konieczności ustawiania LD_LIBRARY_PATH w czasie wykonywania.
źródło
python setup.py build_ext --rpath=/usr/local/lib
przy budowie modułu rozszerzenia piec w rpathMiał dokładnie ten sam problem. Zainstalowałem curl 7.19 to / opt / curl /, aby upewnić się, że nie wpłynę na bieżące curl na naszych serwerach produkcyjnych. Po połączeniu libcurl.so.4 z / usr / lib:
sudo ln -s /opt/curl/lib/libcurl.so /usr/lib/libcurl.so.4
Nadal mam ten sam błąd! Durf.
Ale uruchomienie ldconfig stworzyło powiązanie dla mnie i to zadziałało. W ogóle nie ma potrzeby ustawiania LD_RUN_PATH ani LD_LIBRARY_PATH. Wystarczy uruchomić ldconfig.
źródło
LD_LIBRARY_PATH
metody zmiennej środowiskowej opisanej powyżej. Jeśli nie chcesz go ustawiać w swoim~/.bashrc
(dodawanie tego ustawienia nie jest dobrym pomysłem IMO), możesz napisać skrypt powłoki, który ustawia tę zmienną, a następnie uruchamia Pythona, a następnie wywołać ten skrypt.Jako uzupełnienie powyższych odpowiedzi - po prostu wpadam na podobny problem i pracuję całkowicie z domyślnie zainstalowanym Pythonem.
Kiedy wywołuję przykład udostępnionej biblioteki obiektów, której szukam
LD_LIBRARY_PATH
, otrzymuję coś takiego:Warto zauważyć, że nawet nie narzeka na import - narzeka na plik źródłowy!
Ale jeśli wymuszę załadowanie obiektu za pomocą
LD_PRELOAD
:... od razu otrzymuję bardziej znaczący komunikat o błędzie - o brakującej zależności!
Pomyślałem, że zapiszę to tutaj - na zdrowie!
źródło
Używam
python setup.py build_ext -R/usr/local/lib -I/usr/local/include/libcalg-1.0
i skompilowany plik .so znajduje się w folderze kompilacji. możesz wpisać,python setup.py --help build_ext
aby zobaczyć wyjaśnienia dotyczące -R i -Iźródło
Dla mnie to, co tutaj działa, to użycie menedżera wersji, takiego jak pyenv , który zdecydowanie polecam, aby środowiska projektu i wersje pakietów były dobrze zarządzane i oddzielone od systemu operacyjnego.
Miałem ten sam błąd po aktualizacji systemu operacyjnego, ale został łatwo naprawiony w
pyenv install 3.7-dev
(używanej wersji).źródło