共有ライブラリのロード中のLinuxエラー：共有オブジェクトファイルを開けません：そのようなファイルまたはディレクトリはありません
プログラムはXenomaiテストスイートの一部で、Linux PCからLinux + Xenomai ARMツールチェーンにクロスコンパイルされています。
# echo $LD_LIBRARY_PATH
/lib
# ls /lib
ld-2.3.3.so libdl-2.3.3.so libpthread-0.10.so
ld-linux.so.2 libdl.so.2 libpthread.so.0
libc-2.3.3.so libgcc_s.so libpthread_rt.so
libc.so.6 libgcc_s.so.1 libstdc++.so.6
libcrypt-2.3.3.so libm-2.3.3.so libstdc++.so.6.0.9
libcrypt.so.1 libm.so.6
# ./clocktest
./clocktest: error while loading shared libraries: libpthread_rt.so.1: cannot open shared object file: No such file or directory
編集： OK最後の.1がファイル名の一部であることに気づかなかった。とにかくそれはどういう意味ですか？
更新
共有ライブラリに関する一般的な答えとして、私が以下に書いていることは正しいのですが、この種のメッセージの最も一般的な原因は、パッケージをインストールしたのですが、そのパッケージ。
うそ、それは嘘ではありません - そのリストにはlibpthread_rt.so.1はありません。おそらくあなたが持っているライブラリに依存するようにそれを再設定して再構築するか、libpthread_rt.so.1を提供するものをインストールする必要があります。
一般的に、.soの後の数字はバージョン番号であり、それらが互いにシンボリックリンクであることがしばしばわかるでしょう。そのため、もしあなたがlibfoo.soのバージョン1.1を持っていれば、あなたは本当のファイルlibfoo.so.1.0を持つでしょう。 foo.soとfoo.so.1がlibfoo.so.1.0を指すようにシンボリックリンクしています。他のバージョンを削除せずにバージョン1.1をインストールすると、libfoo.so.1.1が作成され、libfoo.so.1とlibfoo.soが新しいバージョンを指すようになります。 libfoo.so.1.0ファイルを使用してください。バージョン1のAPIのみに依存するコードですが、1.0または1.1のどちらでlibfoo.so.1が指定されても構いません。 orip がコメントで指摘しているように、これは http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html でよく説明されています。
あなたの場合、あなたはmaylibpthread_rt.so.1からlibpthread_rt.soへのシンボリックリンクをやめることにします。それはあなたのコードを壊し、あなたのテレビの夕食を食べないという保証はありません、しかし。
あなたのライブラリは動的ライブラリです。あなたはそれが実行時にそれを見つけることができる場所をオペレーティングシステムに伝える必要があります。
そうするために、我々はそれらの簡単なステップをする必要があるでしょう：
（1）あなたがそれを知らないならば、図書館が置かれる場所を見つけてください。
Sudo find / -name the_name_of_the_file.so
（2）動的ライブラリパス環境変数（LD_LIBRARY_PATH）の存在を確認してください
$ echo $LD_LIBRARY_PATH
表示するものがない場合は、デフォルトのパス値を追加します（または、希望する場合はそうしないでください）。
$ LD_LIBRARY_PATH=/usr/local/lib
（3）希望のパスを追加してエクスポートし、アプリケーションを試します。
パスはpath.so.somethingがあるディレクトリにする必要があります。 path.so.somethingが/my_library/path.so.somethingに含まれている場合は、次のようになります。
$ LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/my_library/
$ export LD_LIBRARY_PATH
$ ./my_app
出典： http://www.gnu.org/software/gsl/manual/html_node/Shared-Libraries.html
これがあなたが試すことができるいくつかの解決策です：
ldconfig
AbiusXが指摘したように、ライブラリをインストールしたばかりの場合は、 ldconfig を実行する必要があります。
Sudo ldconfig
ldconfigは、コマンドラインで指定されたディレクトリ、ファイル/etc/ld.so.conf、および信頼できるディレクトリ（/ libと/ usr/lib）にある最新の共有ライブラリへの必要なリンクとキャッシュを作成します。
通常、新しいライブラリをインストールするときにパッケージマネージャがこれを引き受けますが、常にそうとは限らないので、ldconfigを実行しても問題ない場合でも問題ありません。
開発パッケージまたは間違ったバージョン
それでもうまくいかない場合は、 Paulの提案をチェックしてください そしてライブラリの "-dev"バージョンを探してください。多くのライブラリはdevパッケージとそれ以外のパッケージに分けられます。このコマンドを使って探すことができます。
apt-cache search <libraryname>
これは、間違ったバージョンのライブラリをインストールしただけの場合にも役立ちます。 Pythonなど、一部のライブラリは異なるバージョンで同時に発行されています。
図書館の場所
正しいパッケージがインストールされていて、ldconfigがそれを見つけられなかったと確信しているなら、それは単に非標準ディレクトリにあるかもしれません。デフォルトでは、ldconfigは/lib、/usr/lib、および/etc/ld.so.confと$LD_LIBRARY_PATHにリストされているディレクトリを調べます。ライブラリが他の場所にある場合は、ディレクトリを/etc/ld.so.confの専用の行に追加するか、ライブラリのパスを$LD_LIBRARY_PATHに追加するか、ライブラリを/usr/libに移動することができます。それからldconfigを実行してください。
ライブラリがどこにあるかを調べるには、これを試してください。
Sudo find / -iname *libraryname*.so*
（librarynameをあなたのライブラリの名前に置き換えてください）
もしあなたが$LD_LIBRARY_PATHルートを進んでいるのなら、あなたがそれをあなたの~/.bashrcファイルに入れたくなるでしょう。
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/library
私は同様のエラーがありました、私は与えることによってそれを解決することができました、
Sudo ldconfig -v
お役に立てれば。
.cファイルをコンパイルするときは、リンク時に必ずライブラリパスを指定してください。
gcc -I/usr/local/include xxx.c -o xxx -L/usr/local/lib -Wl、-R/usr/local/lib
-Wl、-R部分は、実行時に/ usr/lib /にあるライブラリを使用する前に、/ usr/local/libにあるライブラリも検索するようにバイナリに指示します。
お役に立てば幸いです。
Linux.orgのリファレンスページではメカニズムについて説明していますが、その背後にある動機については説明していません。
これについては、 『Sun Linker and Libraries Guide』 を参照してください。
さらに、シンボルバージョニング（GNU拡張子）を使用すると、同じライブラリに互換性のない複数のバージョンを単一のライブラリに含めることができるため、「外部バージョニング」はLinuxではほとんど使用されていません。この拡張により、過去10年間、glibcは同じ外部バージョンlibc.so.6を持つことができました。
検索パスを示すLD_LIBRARY_PATHを~/.bashrcファイルに追加してみてください
LD_LIBRARY_PATH=path_to_your_library
できます！
cd /home/<user_name>/
Sudo vi .bash_profile
最後にこれらの行を追加してください
LD_LIBRARY_PATH=/usr/local/lib:<any other paths you want>
export LD_LIBRARY_PATH
あなたの状況に応じてもう一つの可能な解決策。
Libpthread_rt.so.1がlibpthread_rt.soと同じであることがわかっている場合は、次の方法でシンボリックリンクを作成できます。
ln -s /lib/libpthread_rt.so /lib/libpthread_rt.so.1
それからls -l /libはシンボリックリンクとそれが指すものを表示するはずです。
Linux x86上でEclipse CDTを使用してアプリケーションを実行したときに、このエラーが発生しました。
これを修正するには
- Eclipseの場合：
実行 - >実行構成 - >環境
パスを設定
LD_LIBRARY_PATH=/my_lib_directory_path
アプリケーションをMicrosoft Windows上で実行している場合は、動的ライブラリへのパス（.dll）をPATH環境変数で定義する必要があります。
UNIX上でアプリケーションを実行している場合は、動的ライブラリへのパス（.so）をLD_LIBRARY_PATH環境変数で定義する必要があります。
私がしなければならなかったすべては走った：
Sudo apt-get install libfontconfig1
私は/usr/lib/x86_64-linux-gnuにあるフォルダーにいました、そしてそれは完全に働きました。
私は同様のエラーがあり、それは〜/ .bashrcでLD_LIBRARY_PATHを与えることで解決しませんでした。私の問題を解決したのは、.confファイルを追加してロードすることです。ターミナルに行き、suに入ってください。
gedit /etc/ld.so.conf.d/myapp.conf
このファイルにライブラリのパスを追加して保存します（例：/ usr/local/lib）。パスをアクティブにするには、次のコマンドを実行する必要があります。
ldconfig
新しいライブラリパスを確認します。
ldconfig -v | less
これがあなたのライブラリファイルを示しているなら、あなたは行ってもいいです。
sudo lib32z1をインストールしてみてください
Sudo apt - lib32z1のインストール
システムが上記のライブラリファイルを参照できないため、エラーが発生します。次の手順に従ってください。
locate libpthread_rt.so.1を実行すると、その名前のすべてのファイルのパスが一覧表示されます。パスが/home/user/locだとしましょう。- パスをコピーして
cd home/USERNAMEを実行してください。 USERNAMEを、ファイルを実行したい現在アクティブなユーザーの名前に置き換えます。 vi .bash_profileを実行し、LD_LIBRARY_PATHパラメータの最後の.の直前に、/lib://home/usr/loc:.という行を追加します。ファイルを保存してください。- 端末を閉じてアプリケーションを再起動してください。実行する必要があります。
同様の問題がここにあります： https://bugzilla.redhat.com/show_bug.cgi?id=1456202 上記のソリューションを試しましたが、実際に動作します。
前の質問の解決策が機能する場合があります。しかし、これはそれを修正する簡単な方法だと思います。 Fedoraでlibwbclientパッケージを再インストールしてみてください：
dnf reinstall libwbclient
私はこのエラーを得ました、そして、私はそれがあなたのものと同じ理由だと思います
error while loading shared libraries: libnw.so: cannot open shared object
file: No such file or directory
これを試して。 パーミッションを修正します files：
cd /opt/Popcorn (or wherever it is)
chmod -R 555 * (755 if not ok)
chown -R root:root *
あなたのファイルシステムに対する許可を得るための“ Sudo su”。
私はこのエラーを得ました、そして、私はそれがあなたのものと同じ理由だと思います
共有ライブラリのロード中にエラーが発生しました：libnw.so：共有オブジェクトファイルを開けません：そのようなファイルまたはディレクトリはありません
これを試して。ファイルに対する権限を修正します。
cd /opt/Popcorn (or wherever it is)
chmod -R 555 * (755 if not ok)