タグ付けされた質問 「ld」

現在、debian（wheezy / amd64）に奇妙な問題があります。 サーバーをインストールするためにchrootを作成しました（詳細については説明できませんが、申し訳ありません）。そのパスを呼び出しましょう/chr_path/。物事を簡単にするために、このchrootをdebootstrap（wheezy / amd64も）で初期化しました。 すべてはchroot内でうまく機能しているように見えましたが、サーバーのインストーラースクリプトを起動したとき、次のようになりました：（ zsh: Not found /some_path/perlインストーラーには何らかの理由でperlバイナリが含まれています） 当然、/some_path/場所を確認し、「perl」バイナリを見つけました。filechroot環境では以下を返します。 /some_path/perl ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped ファイルが存在し、問題ないようで、正しい権限があります。使用できますfileがls、vimそれを実行しようとするとすぐに- ./perl例えば-私は得る：zsh: Not found ./perl。 この状況は私にはかなり理解できます。さらに： エラーを発生させることなく、chrootで他の基本的なバイナリ（/ bin / ls、...）を実行できます。 プロジェクトに付属している他のバイナリにも同じ問題があります メインルート（/chr_path/some_path/perl）からバイナリを実行しようとすると、動作します。 私は私のバイナリのコピーでバイナリの1つを入れようとしましたls。アクセス権が同じであることを確認しましたが、これは何も変更しませんでした（1つは機能していましたが、もう1つは機能していませんでした）

70 executable  dynamic-linking  linker  ld 

リンクされたライブラリ（libz.so.1.2.7）を必要とする「alpha」という名前のバイナリ実行可能ファイルがあります。 /home/username/myproduct/lib/libz.so.1.2.7 次のコマンドを実行してバイナリ実行可能ファイルを生成する前に、同じものをターミナルインスタンスにエクスポートします。 export LD_LIBRARY_PATH=/home/username/myproduct/lib/:$LD_LIBRARY_PATH さて、同じライブラリを必要とするがバージョンが異なる別のアプリケーション「bravo」、つまりで使用可能な（libz.so.1.2.8）を生成すると /lib/x86_64-linux-gnu/libz.so.1.2.8、システムは次のエラーをスローします。 version `ZLIB_1.2.3.3' not found (required by /usr/lib/x86_64-linux-gnu/libxml2.so.2) の設定を解除するとLD_LIBRARY_PATH、「bravo」が正常に起動します。上記の動作は、リンクされたライブラリの検索中にLD_LIBRARY_PATH定義されたディレクトリパスよりも優先される/etc/ld.so.confため、上記のエラーが発生することを理解しています。ライブラリの最初のインスタンスが異なるバージョンである場合、UNIX / LINUXの開発者が、階層に従って他のディレクトリ内のリンクされたライブラリを検索するようにOSを設計しなかった理由に興味があります。 簡単に言えば、UNIX / LINUXシステムは、必要なライブラリが見つかるまで一連のディレクトリを走査します。しかし、バージョンに関係なくライブラリの最初のインスタンスを受け入れるのではなく、予想されるバージョンが見つかるまで同じことをしないのはなぜですか？

17 libraries  dynamic-linking  shared-library  ld 

偶然にも、私のDebian JessieにはLD_LIBRARY_PATH変数がありません（正確にprintenv | grep LDは、リンカに関連するものは何も表示されず、何echo "$LD_LIBRARY_PATH"も表示されません）。 これは、xターミナルエミュレータ（setgidによりクリアされる可能性があります）および基本ターミナル（Ctrl+Alt+F1）の場合です。 私はそれLD_LIBRARY_PATH が悪いと思われるかもしれないので、Debianはそれをどういうわけかブロックするかもしれませんが、その一方で/etc/ld.so.conf.d/、に追加されるディレクトリを含むいくつかのファイルがありますLD_LIBRARY_PATH。私のrcファイル（私が知っている）はどれも混乱しませんLD_LIBRARY_PATH。 LD_LIBRARY_PATH変数が表示されないのはなぜですか？

15 linux  environment-variables  ld 

ライブラリがインストールされていて、プログラムで使用できるかどうかをテストしたいとします。それがldconfig -p | grep mylibシステムにインストールされているかどうかを確認するために使用できます。しかし、ライブラリが設定によってのみ知られている場合はどうなりますLD_LIBRARY_PATHか？ その場合、プログラムはライブラリを見つけることができるかもしれませんが、できldconfigません。ライブラリが結合されたリンカーパスにあるかどうかを確認するにはどうすればよいですか？ 実際にプログラムが手元にない場合でも機能する解決策を探していることを追加します（たとえば、プログラムはまだコンパイルされていません）。特定のライブラリがld'に存在することを知りたいだけです。sパス。

13 linux  dynamic-linking  ld 

どちらも「リンカー」と呼ばれ、バイナリーをリンクするために使用されますが、それらが互いにどのように異なるのか本当にわかりません。誰か私にそれらの違いを教えてもらえますか？

8 linker  ld 

が他の何よりも先に検索されるという多くのガイダンスを読みましたLD_LIBRARY_PATHが、私の.soライブラリの1つはでリンクしlibtdc++.so.6てい/usr/lib64ます。 ldd mylib.so: ... libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f82abd18000) ... 次のような別の場所mylib.soにリンクしたいlibstdc++.so.6/apps/gcc_4.8.0/lib/libstdc++.so.6 その/apps/gcc_4.8.0/libためLD_LIBRARY_PATH、に追加しますが、には含まれていませんが/usr/lib64、まだ見つかりません。 追加する場合： setenv LD_PRELOAD /apps/gcc_4.8.0/lib/libstdc++.so.6 私の環境では、これ以上リンカーエラーはありません。ええ、しかしそれは問題を解決しません。下流のユーザーは、このライブラリが適切な場所にあることに依存したくないでしょう。ISN "T LD_LIBRARY_PATHが最初に検索される理由！？！

linux  gcc  linker  ld