make:***は「/usr/lib/x 86_64-linux-gnu/libGL.so」に必要なターゲット「XXX」を作成するルールがありません.ていし
5043 ワード
ダイナミックライブラリのリンクエラーによる血液事件
前にPCLのインストールのブログを書いたことがありますが、軽く運転すれば慣れると思っていたのに、誰が考えていたのか、車をひっくり返しました.
pcl makeはどうしてもあげなかったので、ヒント:
中国語のヒントは:
その後libGL.soファイルが存在することが分かった.ここでlsでこのディレクトリの下のすべてのファイルを表示するとlibGL.soファイル名が赤いことがわかります.
これもリンク切断の表現であり、右クリックするとその属性がリンク中断として表示されます.
どのように回復しますか?まず、正しいリンク方法を知るには、別のpclで利用可能なパソコンで確認します.
このように、libGL.soの正しいリンク方式はlibGL.so.1.0.0とリンクされていますが、実はここではこのファイルがどこにあるか分かりませんので、まずグローバル検索でディレクトリを見つけます.
ここでヒントを与えると
sudoは役に立たず、root権限を使っても役に立たない.参考にこれは公式のBUGで、このフォルダは空で、私たちはそれを削除するだけで正常にグローバルに検索することができます.
上の検索を続行すると、次の結果が得られます.
OK、libGL.so.1.0.0が見つかりました.手動でリンクすればいいです.コマンドは以下の通りです.
ヒントがシンボルリンクを作成できず、ファイルがすでに存在する場合は、すでに存在するファイルをsudormで削除し、
直接削除するのは不安ですが、まずはsudo cpバックアップ
/usr/lib/x 86_64-linux-gnuディレクトリの下でsudo cp libGL.so DestDirはエラーを発見しました:
これは、これらのシンボルリンクファイルには絶対パスが必要です.つまり、ディレクトリの下にいても./libGL.soではなく、おとなしく/urs/lib/x 86を持っていく必要があります.
OK、バックアップ後、手動リンク
ここの2つのファイルの間には順序の区別がないようです(不確定)
終了したら、ファイルのプロパティを右クリックしてリンクに成功したかどうかを確認する一方で、ls-n/usr/lib/x 86_64-linux-gnu/libGL.soは、そのリンクステータスを表示します.一方、lsディレクトリの下のすべてのファイルに赤い名前が存在するかどうかを確認できます.PはSになって、できるだけ自動リンクを使わないほうがいいです.
まとめてみると、正しい処理方法は次の通りです.
1.libxxx.soファイルが存在するかどうかを検索
2.ファイルリンクのステータスの表示
3.リンクのステータスを正しい形式に変更
これで、xxxを作成できるルールがないという問題が解決しました.pclも楽しくインストールできました~
BTWは、linuxでのlibファイルの欠落を解決するための不思議なツールapt-fileを発見しました.
これにより、このツールがインストールされ、本明細書のlibGL.soのようなlibを検索する場合は、次のように入力します.
結果は次のとおりです.
あなたがどんなかばんが欠けているかを見ることができて、それから入ればいいです.例えば、ここではlibglvnd-devが入っていないのではないかと疑っていましたが、入れてから上の問題があるのではないでしょうか.実は、このsoファイルが存在するかどうかを調べて、ハエのようにしないでください.
References: https://blog.csdn.net/fb_941219/article/details/83549720 https://blog.csdn.net/wuguangbin1230/article/details/77816299 https://www.jianshu.com/p/289205fae296 https://zhidao.baidu.com/question/306489700.html
前にPCLのインストールのブログを書いたことがありますが、軽く運転すれば慣れると思っていたのに、誰が考えていたのか、車をひっくり返しました.
pcl makeはどうしてもあげなかったので、ヒント:
make[2]: *** No rule to make target '/usr/lib/x86_64-linux-gnu/libGL.so', needed by'***'
中国語のヒントは:
make: *** “XXX.o” “***”。
これは動的ライブラリリンクの中断によるもので、対応するファイルディレクトリの下でファイルの状態を見てみましょう.cd /usr/lib/x86_64-linux-gnu/
その後libGL.soファイルが存在することが分かった.ここでlsでこのディレクトリの下のすべてのファイルを表示するとlibGL.soファイル名が赤いことがわかります.
これもリンク切断の表現であり、右クリックするとその属性がリンク中断として表示されます.
どのように回復しますか?まず、正しいリンク方法を知るには、別のpclで利用可能なパソコンで確認します.
wrx@wrx:/usr/lib/x86_64-linux-gnu$ ls -l libGL.so
lrwxrwxrwx 1 root root 14 5 10 20:17 libGL.so -> libGL.so.1.0.0
このように、libGL.soの正しいリンク方式はlibGL.so.1.0.0とリンクされていますが、実はここではこのファイルがどこにあるか分かりませんので、まずグローバル検索でディレクトリを見つけます.
sudo find / -iname "*libGL.so*"
ここでヒントを与えると
**find: ‘/run/user/1000/gvfs’: Permission denied**
sudoは役に立たず、root権限を使っても役に立たない.参考にこれは公式のBUGで、このフォルダは空で、私たちはそれを削除するだけで正常にグローバルに検索することができます.
umount /run/user/1000/gvfs
rm -rf /run/user/1000/gvfs
上の検索を続行すると、次の結果が得られます.
wrx@wrx:/usr/lib/x86_64-linux-gnu$ sudo find / -iname "*libGL.so*"
[sudo] wrx :
/snap/gnome-3-26-1604/90/usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
/snap/gnome-3-26-1604/90/usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0
/snap/gnome-3-26-1604/88/usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
/snap/gnome-3-26-1604/88/usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0
/snap/cloudcompare/200/usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
/snap/cloudcompare/200/usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0
/snap/electronic-wechat/7/usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
/snap/electronic-wechat/7/usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0
/snap/gnome-3-28-1804/67/usr/lib/x86_64-linux-gnu/libGL.so.1
/snap/gnome-3-28-1804/67/usr/lib/x86_64-linux-gnu/libGL.so.1.0.0
/snap/gnome-3-28-1804/71/usr/lib/x86_64-linux-gnu/libGL.so.1
/snap/gnome-3-28-1804/71/usr/lib/x86_64-linux-gnu/libGL.so.1.0.0
/usr/lib/x86_64-linux-gnu/libGL.so
/usr/lib/x86_64-linux-gnu/libGL.so.1
/usr/lib/x86_64-linux-gnu/libGL.so.1.0.0
/usr/lib/i386-linux-gnu/libGL.so.1
/usr/lib/i386-linux-gnu/libGL.so.1.0.0
OK、libGL.so.1.0.0が見つかりました.手動でリンクすればいいです.コマンドは以下の通りです.
sudo ln -s /usr/lib/x86_64-linux-gnu/libGL.so /usr/lib/x86_64-linux-gnu/libGL.so.1.0.0
ヒントがシンボルリンクを作成できず、ファイルがすでに存在する場合は、すでに存在するファイルをsudormで削除し、
直接削除するのは不安ですが、まずはsudo cpバックアップ
/usr/lib/x 86_64-linux-gnuディレクトリの下でsudo cp libGL.so DestDirはエラーを発見しました:
これは、これらのシンボルリンクファイルには絶対パスが必要です.つまり、ディレクトリの下にいても./libGL.soではなく、おとなしく/urs/lib/x 86を持っていく必要があります.
OK、バックアップ後、手動リンク
sudo ln -s /usr/lib/x86_64-linux-gnu/libGL.so /usr/lib/x86_64-linux-gnu/libGL.so.1.0.0
ここの2つのファイルの間には順序の区別がないようです(不確定)
終了したら、ファイルのプロパティを右クリックしてリンクに成功したかどうかを確認する一方で、ls-n/usr/lib/x 86_64-linux-gnu/libGL.soは、そのリンクステータスを表示します.一方、lsディレクトリの下のすべてのファイルに赤い名前が存在するかどうかを確認できます.PはSになって、できるだけ自動リンクを使わないほうがいいです.
sudo ln -s /usr/lib/x86_64-linux-gnu/libGL.so
後のパラメータを省くと自動リンクです.ここは自動的に別のsoファイルにリンクされているので、リンクが終わった後も赤い名前+リンクが切れている状態です(これも私が半日踏んだ穴です).まとめてみると、正しい処理方法は次の通りです.
1.libxxx.soファイルが存在するかどうかを検索
2.ファイルリンクのステータスの表示
3.リンクのステータスを正しい形式に変更
これで、xxxを作成できるルールがないという問題が解決しました.pclも楽しくインストールできました~
BTWは、linuxでのlibファイルの欠落を解決するための不思議なツールapt-fileを発見しました.
sudo apt-get install apt-file
sudo apt-file update
これにより、このツールがインストールされ、本明細書のlibGL.soのようなlibを検索する場合は、次のように入力します.
sudo apt-file search libGL.so
結果は次のとおりです.
wrx@wrx:/usr/lib/x86_64-linux-gnu$ sudo apt-file search libGL.so
[sudo] wrx :
libgl1: /usr/lib/x86_64-linux-gnu/libGL.so.1
libgl1: /usr/lib/x86_64-linux-gnu/libGL.so.1.0.0
libglvnd-dev: /usr/lib/x86_64-linux-gnu/libGL.so
nvidia-340: /usr/lib/i386-linux-gnu/libGL.so
nvidia-340: /usr/lib/i386-linux-gnu/libGL.so.1
nvidia-340: /usr/lib/i386-linux-gnu/libGL.so.340.106
nvidia-340: /usr/lib/i386-linux-gnu/libGL.so.340.107
nvidia-340: /usr/lib/x86_64-linux-gnu/libGL.so
nvidia-340: /usr/lib/x86_64-linux-gnu/libGL.so.1
nvidia-340: /usr/lib/x86_64-linux-gnu/libGL.so.340.106
nvidia-340: /usr/lib/x86_64-linux-gnu/libGL.so.340.107
primus-libs: /usr/lib/x86_64-linux-gnu/primus/libGL.so.1
virtualbox-guest-x11: /usr/lib/virtualbox/additions/libGL.so
virtualbox-guest-x11: /usr/lib/virtualbox/additions/libGL.so.1
virtualbox-guest-x11-hwe: /usr/lib/virtualbox/additions/libGL.so
virtualbox-guest-x11-hwe: /usr/lib/virtualbox/additions/libGL.so.1
あなたがどんなかばんが欠けているかを見ることができて、それから入ればいいです.例えば、ここではlibglvnd-devが入っていないのではないかと疑っていましたが、入れてから上の問題があるのではないでしょうか.実は、このsoファイルが存在するかどうかを調べて、ハエのようにしないでください.
References: https://blog.csdn.net/fb_941219/article/details/83549720 https://blog.csdn.net/wuguangbin1230/article/details/77816299 https://www.jianshu.com/p/289205fae296 https://zhidao.baidu.com/question/306489700.html