LINUX.ORG.RU

error while loading shared libraries


0

1

В убунту было все нормально, в дебиан (7) такая ошибка при запуске:

nww@nww:~$ SampleBrowser
SampleBrowser: error while loading shared libraries: libOgreMain.so.1.8.0: cannot open shared object file: No such file or directory
Хотя все библы установлены, я проводил make успешно и make install тоже. библы лежат /usr/local/lib и в /usr/local/lib/OGRE

Что не так?



Последнее исправление: vladmenshikov (всего исправлений: 1)
ldd $(which SampleBrowser)
LD_LIBRARY_PATH=«$(dirname »$(find / -name libOgreMain.so.1.8.0 | head -n1)"):$LD_LIBRARY_PATH" ldd $(which SampleBrowser)
AITap ★★★★★
()
Ответ на: комментарий от AITap

ldd $(which SampleBrowser)

nww@nww:~$ ldd $(which SampleBrowser)
	linux-gate.so.1 =>  (0xb76f7000)
	libOgreMain.so.1.8.0 => not found
	libOgreRTShaderSystem.so.1.8.0 => not found
	libOIS-1.3.0.so => /usr/lib/i386-linux-gnu/libOIS-1.3.0.so (0xb76bc000)
	libfreetype.so.6 => /usr/lib/i386-linux-gnu/libfreetype.so.6 (0xb7620000)
	libSM.so.6 => /usr/lib/i386-linux-gnu/libSM.so.6 (0xb7618000)
	libICE.so.6 => /usr/lib/i386-linux-gnu/libICE.so.6 (0xb75ff000)
	libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xb74c7000)
	libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0xb74b4000)
	libXt.so.6 => /usr/lib/i386-linux-gnu/libXt.so.6 (0xb7456000)
	libXaw.so.7 => /usr/lib/i386-linux-gnu/libXaw.so.7 (0xb73ec000)
	libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xb73d3000)
	libdl.so.2 => /lib/i386-linux-gnu/i686/cmov/libdl.so.2 (0xb73cf000)
	libboost_thread.so.1.49.0 => /usr/lib/libboost_thread.so.1.49.0 (0xb73b5000)
	libboost_date_time.so.1.49.0 => /usr/lib/libboost_date_time.so.1.49.0 (0xb73a6000)
	libfreeimage.so.3 => /usr/lib/libfreeimage.so.3 (0xb72b5000)
	libzzip-0.so.13 => /usr/lib/libzzip-0.so.13 (0xb72ae000)
	libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb7295000)
	libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb71a7000)
	libm.so.6 => /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xb7181000)
	libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb7164000)
	libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb7007000)
	libuuid.so.1 => /lib/i386-linux-gnu/libuuid.so.1 (0xb7001000)
	libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xb6fdd000)
	libXmu.so.6 => /usr/lib/i386-linux-gnu/libXmu.so.6 (0xb6fc4000)
	libXpm.so.4 => /usr/lib/i386-linux-gnu/libXpm.so.4 (0xb6fb3000)
	/lib/ld-linux.so.2 (0xb76f8000)
	librt.so.1 => /lib/i386-linux-gnu/i686/cmov/librt.so.1 (0xb6faa000)
	libjpeg.so.8 => /usr/lib/i386-linux-gnu/libjpeg.so.8 (0xb6f71000)
	libmng.so.1 => /usr/lib/i386-linux-gnu/libmng.so.1 (0xb6ee9000)
	libopenjpeg.so.2 => /usr/lib/libopenjpeg.so.2 (0xb6ec9000)
	libIlmImf.so.6 => /usr/lib/libIlmImf.so.6 (0xb6e10000)
	libImath.so.6 => /usr/lib/libImath.so.6 (0xb6e09000)
	libHalf.so.6 => /usr/lib/libHalf.so.6 (0xb6dc5000)
	libIex.so.6 => /usr/lib/libIex.so.6 (0xb6daa000)
	libIlmThread.so.6 => /usr/lib/libIlmThread.so.6 (0xb6da2000)
	libraw.so.5 => /usr/lib/i386-linux-gnu/libraw.so.5 (0xb6d13000)
	liblcms2.so.2 => /usr/lib/i386-linux-gnu/liblcms2.so.2 (0xb6cc6000)
	libpng12.so.0 => /lib/i386-linux-gnu/libpng12.so.0 (0xb6c9c000)
	libgomp.so.1 => /usr/lib/i386-linux-gnu/libgomp.so.1 (0xb6c8c000)
	libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xb6c88000)
	libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xb6c82000)
	liblcms.so.1 => /usr/lib/i386-linux-gnu/liblcms.so.1 (0xb6c47000)
	libjasper.so.1 => /usr/lib/i386-linux-gnu/libjasper.so.1 (0xb6bf0000)
vladmenshikov
() автор топика
Ответ на: комментарий от anonymous

В любом случае, там только плагины, не относятся к либе из-за которой ошибка, libOgreMain.so.1.8.0 находится тут /usr/local/lib

vladmenshikov
() автор топика
Ответ на: комментарий от AITap

Как вообще правильно компилить приложения в линуксе, что бы библы находились там откуда был запуск, а не геморрой вроде добавления LD_LIBRARY_PATH ? Почему в гребаной виндовс, один и тот же проект компилится нормально, и достает либы из той же папки, а в линуксе этот же проект эклипсовый, после компиляции рвется хрен знает куда в /usr/local/lib

vladmenshikov
() автор топика
Ответ на: комментарий от anonymous

Потому, что с вендой песдуй на винфак, а в линуксе читай man ld.so ldconfig

У меня в дебиане ldconfig вообще не установлен, и вы предлагаете помимо моей проги что бы пользователь устанавливал какой то там ldconfig? Что за идиотиз.

vladmenshikov
() автор топика
Ответ на: комментарий от vladmenshikov

хотел ответить, но тут такая толстота, что все желание пропало.

CryAngel
()
Ответ на: комментарий от vladmenshikov

У меня в дебиане ldconfig вообще не установлен

Наркоман штоле?

и вы предлагаете помимо моей проги что бы пользователь устанавливал какой то там ldconfig?

Да, наркоман.

anonymous
()
Ответ на: комментарий от vladmenshikov

ld.so у тебя установлен — дальнейшие действия для тебя я описа́л.

anonymous
()
Ответ на: комментарий от anonymous

Наркоман штоле?

nww@nww:~$ ldconfig -p | grep ogre
bash: ldconfig: команда не найдена
nww@nww:~$ ldconfig --help
bash: ldconfig: команда не найдена
nww@nww:~$
vladmenshikov
() автор топика
Ответ на: комментарий от vladmenshikov

libOgreMain.so.1.8.0 => not found
libOgreRTShaderSystem.so.1.8.0 => not found

Где лежат эти библиотеки?

Почему тогда в убунте работало без всяких добавлений?

А как ставили в убунте?

Как вообще правильно компилить приложения в линуксе, что бы библы находились там откуда был запуск, а не геморрой вроде добавления LD_LIBRARY_PATH ?

Устанавливать в те места, где их предполагает найти система. Обычно это --prefix=/usr и т.п.

Почему в гребаной виндовс, один и тот же проект компилится нормально, и достает либы из той же папки

В винде (образно) PATH=. и LD_LIBRARY_PATH=.
Можете сделать у себя то же самое. Так часто делают, когда распространяют программы в виде бинарников.

AITap ★★★★★
()
Ответ на: комментарий от anonymous

Дубина, у тебя /sbin не в $PATH.

Автору этогой статьи это скажи http://handynotes.ru/2007/05/linux.html
И вообще, ты давно с людьми общался? Видать давно, ибо разучился парсить с кем общаешься, с продвинутым во всей этой линуксовой хрени, или с новичком - сказал обрывком «/sbin не в $PATH», а то что это распарсят лишь те, кто знает и без тебя, а остальным фенькина грамота, до тебя не доходит.

vladmenshikov
() автор топика
Ответ на: комментарий от vladmenshikov

Добавьте эти пути в LD_LIBRARY_PATH, /etc/ld.so.conf или /etc/ld.so.conf.d/ogre.conf (создайте файл) и выполните ldconfig. Или установите Ogre в /usr, а не в /usr/local. Вы выполняли ldconfig после установки ogre?

На всякий случай, ldd /usr/local/lib/libOgreMain.so.1.8.0

AITap ★★★★★
()
Ответ на: комментарий от CryAngel

Ага, эклипс например, очень «нехорошая» программа - толстеете на глазах.

vladmenshikov
() автор топика
Ответ на: комментарий от vladmenshikov

Видать давно, ибо разучился парсить с кем общаешься

Не разучился.

с новичком

С жирным троллем. Тон дискуссии ты задал сам, так что не ной.

anonymous
()
Ответ на: комментарий от AITap

Вы выполняли ldconfig после установки ogre?

Нет, не выполнял, но и в убунту я так же устанавливал, только там от чего-то заработало.

Или установите Ogre в /usr, а не в /usr/local.

А кидать прям все скопом в /usr, или /usr/OGRE тоже отыщет?

vladmenshikov
() автор топика
Ответ на: комментарий от anonymous

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

vladmenshikov
() автор топика
Ответ на: комментарий от vladmenshikov

Вы выполняли ldconfig после установки ogre?

Нет, не выполнял, но и в убунту я так же устанавливал, только там от чего-то заработало.

Возможно, там заранее сделаны настройки для поиска в /usr/local/lib/. Впрочем, в /usr/local/lib/OGRE ни тот, не другой сами по себе искать не могут, а в Debian 7 такая настройка тоже есть.

Кстати, расскажите, как ставили OGRE.

А кидать прям все скопом в /usr, или /usr/OGRE тоже отыщет?

Кидать? Префикс указывается на этапе компиляции.
Нет, в /usr/OGRE не отыщет. Используйте checkinstall, чтобы собрать пакет.

AITap ★★★★★
()
Ответ на: комментарий от AITap
nww@nww:~$ ldd /usr/local/lib/libOgreMain.so.1.8.0
	linux-gate.so.1 =>  (0xb76e9000)
	libfreetype.so.6 => /usr/lib/i386-linux-gnu/libfreetype.so.6 (0xb70cd000)
	libSM.so.6 => /usr/lib/i386-linux-gnu/libSM.so.6 (0xb70c5000)
	libICE.so.6 => /usr/lib/i386-linux-gnu/libICE.so.6 (0xb70ab000)
	libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xb6f73000)
	libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0xb6f61000)
	libXt.so.6 => /usr/lib/i386-linux-gnu/libXt.so.6 (0xb6f03000)
	libXaw.so.7 => /usr/lib/i386-linux-gnu/libXaw.so.7 (0xb6e99000)
	libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xb6e7f000)
	libdl.so.2 => /lib/i386-linux-gnu/i686/cmov/libdl.so.2 (0xb6e7b000)
	libboost_thread.so.1.49.0 => /usr/lib/libboost_thread.so.1.49.0 (0xb6e62000)
	libboost_date_time.so.1.49.0 => /usr/lib/libboost_date_time.so.1.49.0 (0xb6e53000)
	libfreeimage.so.3 => /usr/lib/libfreeimage.so.3 (0xb6d62000)
	libzzip-0.so.13 => /usr/lib/libzzip-0.so.13 (0xb6d5a000)
	libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb6d41000)
	libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb6c54000)
	libm.so.6 => /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xb6c2e000)
	libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb6c11000)
	libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb6ab3000)
	libuuid.so.1 => /lib/i386-linux-gnu/libuuid.so.1 (0xb6aad000)
	libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xb6a8a000)
	libXmu.so.6 => /usr/lib/i386-linux-gnu/libXmu.so.6 (0xb6a71000)
	libXpm.so.4 => /usr/lib/i386-linux-gnu/libXpm.so.4 (0xb6a60000)
	/lib/ld-linux.so.2 (0xb76ea000)
	librt.so.1 => /lib/i386-linux-gnu/i686/cmov/librt.so.1 (0xb6a56000)
	libjpeg.so.8 => /usr/lib/i386-linux-gnu/libjpeg.so.8 (0xb6a1d000)
	libmng.so.1 => /usr/lib/i386-linux-gnu/libmng.so.1 (0xb6996000)
	libopenjpeg.so.2 => /usr/lib/libopenjpeg.so.2 (0xb6976000)
	libIlmImf.so.6 => /usr/lib/libIlmImf.so.6 (0xb68bd000)
	libImath.so.6 => /usr/lib/libImath.so.6 (0xb68b5000)
	libHalf.so.6 => /usr/lib/libHalf.so.6 (0xb6871000)
	libIex.so.6 => /usr/lib/libIex.so.6 (0xb6856000)
	libIlmThread.so.6 => /usr/lib/libIlmThread.so.6 (0xb684f000)
	libraw.so.5 => /usr/lib/i386-linux-gnu/libraw.so.5 (0xb67c0000)
	liblcms2.so.2 => /usr/lib/i386-linux-gnu/liblcms2.so.2 (0xb6772000)
	libpng12.so.0 => /lib/i386-linux-gnu/libpng12.so.0 (0xb6748000)
	libgomp.so.1 => /usr/lib/i386-linux-gnu/libgomp.so.1 (0xb6738000)
	libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xb6735000)
	libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xb672f000)
	liblcms.so.1 => /usr/lib/i386-linux-gnu/liblcms.so.1 (0xb66f3000)
	libjasper.so.1 => /usr/lib/i386-linux-gnu/libjasper.so.1 (0xb669c000)
vladmenshikov
() автор топика
Ответ на: комментарий от AITap

Кстати, расскажите, как ставили OGRE.


1. cmake-gui
2. указал папку с исходниками ($HOME/ogre_source), указал папку билда ($HOME/ogre_build)
3. Нажал конфигурацию, прошла успешно, поставил галки установки эксемплов, опять нажал конфигурацию, прошла успешно, нажал генерацию макфайла.
4. cd ogre_build
5. make, make install (прошли успешно)
6. Запускаю SampleBrowser и эта ошибка, а если зайти в папку ogre_build/bin и там запустить SampleBrowser то все нормально.

vladmenshikov
() автор топика
Ответ на: комментарий от vladmenshikov

На будущее скажу, что не следует огрызаться, а нужно было сделать which <имя_программы>, чтобы узнать, где она лежит. Еще можно использовать ldd: ldd <имя_программы> выдаст все пути библиотеки, на которые ссылаетс программа

anonymous
()
Ответ на: комментарий от anonymous

Да потому что этот пакет не содержит туеву кучу нужных компонентов, тотже плагин Plugin_CgProgramManager.so.1.8 получить который можно лишь откомпилив вручную с установленным nvidia-cg-toolkit

vladmenshikov
() автор топика
Ответ на: комментарий от vladmenshikov

Да потому что этот пакет не содержит туеву кучу нужных компонентов

А что тебе мешает сделать apt-get source ogre, поправить параметры и собрать пакет?

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

А какая разница, между компиляцией вручную и установкой пакета? Либы лижат там где нужно, что еще надо непонятно. Я ранее устанавливал пакет собранного огра (версия 1.7 кажись была тогда), так вот либы после его установки лежали там же, где сейчас лежат откомпилинного мной вручную, так что разници не вижу.

vladmenshikov
() автор топика
Ответ на: комментарий от vladmenshikov

Либы лижат там где нужно

Что ж ты вопросы-то пришёл спрашивать, раз всё сам знаешь? Раз не подцепились, значит не там, где нужно.

i-rinat ★★★★★
()
Ответ на: комментарий от vladmenshikov

Нажал конфигурацию, прошла успешно,

На этом этапе можно было выставить префиксы

Запускаю SampleBrowser и эта ошибка, а если зайти в папку ogre_build/bin и там запустить SampleBrowser то все нормально.

SampleBrowser точно бинарник? Что в данный момент в конфиге ld.so? В переменных окружения?

AITap ★★★★★
()
Ответ на: комментарий от AITap

SampleBrowser точно бинарник? Что в данный момент в конфиге ld.so? В переменных окружения?

Точно бинарник, как его посмотреть то? Этож либа.

vladmenshikov
() автор топика
Ответ на: комментарий от AITap
nww@nww:~$ grep -r . /etc/ld.so*
Двоичный файл /etc/ld.so.cache совпадает
/etc/ld.so.conf:include /etc/ld.so.conf.d/*.conf
/etc/ld.so.conf.d/i486-linux-gnu.conf:# Multiarch support
/etc/ld.so.conf.d/i486-linux-gnu.conf:/lib/i386-linux-gnu
/etc/ld.so.conf.d/i486-linux-gnu.conf:/usr/lib/i386-linux-gnu
/etc/ld.so.conf.d/i486-linux-gnu.conf:/lib/i486-linux-gnu
/etc/ld.so.conf.d/i486-linux-gnu.conf:/usr/lib/i486-linux-gnu
/etc/ld.so.conf.d/libc.conf:# libc default configuration
/etc/ld.so.conf.d/libc.conf:/usr/local/lib
nww@nww:~$
vladmenshikov
() автор топика
Ответ на: комментарий от vladmenshikov

А какая разница, между компиляцией вручную и установкой пакета?

Ну вот у меня собрался пакет сейчас, правил я только одну строчку в debian/control. Поставил из реп ­— пример с CelShading не заработал, ругнулся на отсутствующий плагин. Поставил самосборные пакеты ­— работает.

$ dpkg -L libogre-1.8.0 | grep Cg
/usr/lib/x86_64-linux-gnu/OGRE-1.8.0/Plugin_CgProgramManager.so.1.8.0
/usr/lib/x86_64-linux-gnu/OGRE-1.8.0/Plugin_CgProgramManager.so

Вот она, разница.

i-rinat ★★★★★
()
Ответ на: комментарий от vladmenshikov

Попробуйте написать /usr/local/lib/OGRE в /etc/ld.so.conf.d/ogre.conf. Сравните ldd бинарника в ogre_build/bin и установленного.

AITap ★★★★★
()
Ответ на: комментарий от vladmenshikov

У меня в дебиане ldconfig вообще не установлен

Когда ж ты уже последуешь единственно правильному совету и сделаешь вдоль?!

anonymous
()
Ответ на: комментарий от vladmenshikov

Зависимость от создателей пакета меня не устраивает.

NIH-синдром. А зависимость от автора и разработчиков OGRE тебя устраивает? Может свой движок написать? Потом возьмёшься за стандартную библиотеку C++, перепишешь boost, потом компилятор, новый язык, операционная система, ядро, аппаратная платформа, архитектура процессора, фон Нейман, схемные решения, используемые полупроводники... Когда-то придётся остановиться.

мне нужно разобраться

Для начала: выбор дистрибутива это своего рода выбор отношения к совокупности используемых программ. Если выбрал Debian, то и программы устанавливай debian-way, собирай пакет. В крайнем случае есть checkinstall.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat
--- ogre-1.8-1.8.0.orig/debian/control	2012-06-07 03:52:06.000000000 +0400
+++ ogre-1.8-1.8.0/debian/control	2012-08-07 21:29:51.687465544 +0400
@@ -17,6 +17,7 @@
                libfreeimage-dev,
                libfreetype6-dev,
                libzzip-dev,
+               nvidia-cg-toolkit,
                zlib1g-dev,
                libz-dev,
                libglu1-mesa-dev | libglu-dev,
i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Если выбрал Debian, то и программы устанавливай debian-way, собирай пакет.

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

vladmenshikov
() автор топика
Ответ на: комментарий от anonymous

Проблема не в говно-кодерстве, проблема в линуксе, уж слишком не очевидно тут это решено, в отличии от той же винды.

vladmenshikov
() автор топика
Ответ на: комментарий от vladmenshikov

Можно конечно и разом решить проблемы как выше предлагали - установкой префикса /usr/lib вместо /usr/lib/local, но меня куда больше интересует почему эти либы лежащие /usr/lib/local не находятся, хотя там лежат, и проект настроен на эти пути.

vladmenshikov
() автор топика
Ответ на: комментарий от vladmenshikov

Добавлять что-то через консоль, тоже не вариант, ибо убунта работает и без этого, тут очевидно что косяк в дебиан, и класть мне в чем он, либы лежащие в /usr/lib/local должны находится без хитроумных правок пользователем, по стандарту, если этого нет - это косяк.

vladmenshikov
() автор топика
Ответ на: комментарий от vladmenshikov

Потому-что ВСЕ программы должны лежать в пакетах.

но меня куда больше интересует почему эти либы лежащие /usr/lib/local не находятся, хотя там лежат, и проект настроен на эти пути.

Выше уже объясняли.

Deleted
()
Ответ на: комментарий от vladmenshikov

Проблема в том, что, перед залезанием в чужой монастырь читается указ. Либы, лежащие по произвольному пути (а /usr/lib/local именно абы какой произвольный путь), никем не должны подхватываться. Читай про rpath и man ldconfig

Deleted
()
Ответ на: комментарий от vladmenshikov

проблема в линуксе

«на твоём месте я бы потребовал возврат денег» :)

но меня куда больше интересует почему эти либы лежащие /usr/lib/local не находятся, хотя там лежат

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

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

Если ты не в курсе, ubuntu регулярно синхронизируется с debian/sid и использует абсолютно тот же пакетный менеджер и ту же систему сборки пакетов.

i-rinat ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.