共有ライブラリのロード中の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がファイル名の一部であることに気づきませんでした。とにかくそれはどういう意味ですか？

更新
以下の記述は共有ライブラリに関する一般的な回答として当てはまりますが、この種のメッセージの最もよくある原因は、パッケージをインストールしたが、そのパッケージの "-dev"バージョンをインストールしていないためです。

まあ、それは嘘ではありません- libpthread_rt.so.1そのリストにはありません。おそらく、ライブラリに依存するように再構成および再構築するか、提供されるものをインストールする必要がありますlibpthread_rt.so.1。

一般に、.soの後の番号はバージョン番号であり、それらが相互にシンボリックリンクであることがよくあります。そのため、libfoo.soのバージョン1.1がある場合、実際のファイルlibfoo.so.1.0があります。 libfoo.so.1.0を指すfoo.soおよびfoo.so.1のシンボリックリンク。他のバージョンを削除せずにバージョン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。

あなたの場合、へのシンボリックリンクで逃げるかもしれません。ただし、コードが壊れてテレビの夕食が食べられないという保証はありません。libpthread_rt.so.1libpthread_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パッケージとnon-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のライブラリも検索するように指示します。

それがあなたを助けることを願っています。

LD_LIBRARY_PATH検索パスを示すを~/.bashrcファイルに追加してみてください

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path_to_your_library

できます！

linux.orgのリファレンスページでは、メカニズムについて説明していますが、その背後にある動機については説明していません:-(

そのためには、Sun Linker and Libraries Guideを参照してください。

さらに、シンボルのバージョン管理（GNU拡張）を使用すると、同じ関数の互換性のない複数のバージョンを1つのライブラリに含めることができるため、「外部バージョン管理」はLinuxではほとんど使用されていないことに注意してください。この拡張により、glibcは同じ外部バージョンを持つことができました。libc.so.6過去10年間。

cd /home/<user_name>/
sudo vi .bash_profile

これらの行を最後に追加します

LD_LIBRARY_PATH=/usr/local/lib:<any other paths you want>
export LD_LIBRARY_PATH

同様のエラーが発生し、〜/ .bashrcにLD_LIBRARY_PATHを指定しても修正されませんでした。私の問題を解決したのは、.confファイルを追加してロードすることです。ターミナルに移動し、suを実行します。

gedit /etc/ld.so.conf.d/myapp.conf

このファイルにライブラリパスを追加して保存します（例：/ usr / local / lib）。パスをアクティブにするには、次のコマンドを実行する必要があります。

ldconfig

新しいライブラリパスを確認します。

ldconfig -v | less

これでライブラリファイルが表示される場合は、問題ありません。

あなたの状況に応じて別の可能な解決策。

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を使用してアプリケーションを実行すると、このエラーが発生しました。
これを修正するには：

1. Eclipseの場合：

   実行->実行構成->環境

2. パスを設定する

   LD_LIBRARY_PATH=/my_lib_directory_path
   

私がしなければならなかったすべては実行されました：

sudo apt-get install libfontconfig1

私はにあるフォルダーにいて/usr/lib/x86_64-linux-gnu、それは完全に機能しました。

Microsoft Windowsでアプリケーションを実行している場合は、動的ライブラリ（.dll）へのパスをPATH環境変数で定義する必要があります。

UNIXでアプリケーションを実行している場合は、動的ライブラリ（.so）へのパスをLD_LIBRARY_PATH環境変数で定義する必要があります。

sudo lib32z1をインストールしてみてください

sudo apt-get install lib32z1

システムが言及されたライブラリファイルを参照できないため、エラーが発生します。次の手順を実行します。

1. 実行locate libpthread_rt.so.1すると、その名前のすべてのファイルのパスが一覧表示されます。パスがであるとしましょう/home/user/loc。
2. パスをコピーして実行しcd home/USERNAMEます。USERNAMEを、ファイルを実行する現在アクティブなユーザーの名前に置き換えます。
3. を実行vi .bash_profileし、LD_LIBRARY_PATHパラメータの最後の直前に.行を追加します/lib://home/usr/loc:.。ファイルを保存します。
4. 端末を閉じて、アプリケーションを再起動します。実行する必要があります。

私はこのエラーを受け取りました、そしてあなたと同じ理由だと思います

error while loading shared libraries: libnw.so: cannot open shared object 
file: No such file or directory

これを試して。ファイルの権限を修正します。

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) 

同様の問題がここにあります：https : //bugzilla.redhat.com/show_bug.cgi?id=1456202 上記の解決策を試してみましたが、実際に機能します。

前の質問の解決策が機能する場合があります。しかし、これはそれを修正する簡単な方法だと思います。libwbclient fedoraにパッケージを再インストールしてみてください：

dnf reinstall libwbclient

Ubuntu 18.04を使用しています

対応する「-dev」パッケージをインストールするとうまくいきました、

sudo apt install libgconf2-dev

上記のパッケージをインストールするまで、以下のエラーが発生しました。

turtl: error while loading shared libraries: libgconf-2.so.4: cannot open shared object file: No such file or directory