タグ付けされた質問 「dynamic-linking」

コンピューティングでは、動的リンクとは、実行時に実行可能ファイルに必要な共有ライブラリをロード(永続ストレージからRAMにコピー)およびリンク(ジャンプテーブルを埋め、ポインタを再配置)するオペレーティングシステム(OS)のプロセスです。実行されたとき。

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

2
`file`によって報告されるように、動的リンカー/ローダー自体をどのように動的にリンクできますか?
(ダイナミックリンカー/ローダー)/bin/bashを含むの共有オブジェクトの依存関係を考慮します/lib64/ld-linux-x86-64.so.2。 ldd /bin/bash linux-vdso.so.1 (0x00007fffd0887000) libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007f57a04e3000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f57a04de000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f57a031d000) /lib64/ld-linux-x86-64.so.2 (0x00007f57a0652000) 検査/lib64/ld-linux-x86-64.so.2すると、それが次へのシンボリックリンクであることがわかり/lib/x86_64-linux-gnu/ld-2.28.soます。 ls -la /lib64/ld-linux-x86-64.so.2 lrwxrwxrwx 1 root root 32 May 1 19:24 /lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.28.so さらに、それ自体へのfileレポート/lib/x86_64-linux-gnu/ld-2.28.soは動的にリンクされます。 file -L /lib64/ld-linux-x86-64.so.2 /lib64/ld-linux-x86-64.so.2: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, …

1
Linuxの動的リンカーがパスを検索する順序は何ですか?
これは私が使用するときに気づいた特異性を扱っているため、複製ではありません/etc/ld.so.conf。 動的リンカーがライブラリを検索するパスを取得するには、コマンドを実行しldconfig -v | grep -v "^"$'\t' | sed "s/:$//g"ます。に/etc/ld.so.confパスがリストされていない場合。前のコマンドからの出力は /lib /usr/lib /lib最初に検索し、それから検索すると考えました/usr/lib。私のような新しいパスを追加するとき/usr/local/libに、/etc/ld.so.confリメイク、その後と/etc/ld.so.cache、出力からはldconfig -v | grep -v "^"$'\t' | sed "s/:$//g"なり /usr/local/lib /lib /usr/lib リストされたディレクトリが検索される順序が上から下であることが正しい場合、追加のディレクトリが/libとの前に検索されるため、これは奇妙です/usr/lib。信頼できるディレクトリの前に追加のディレクトリが検索されること自体は奇妙ではありませんが、/libが前/usr/libに検索されると、/bin&/sbinは/usr/bin&/usr/sbininの後に検索されるため、奇妙PATHです。 によってリストされたパスldconfig -v | grep -Ev "^"$'\t' | sed "s/:$//g"が下から上に検索された場合でも、信頼できるディレクトリの後に追加のディレクトリが検索され、の後に検索されるため、順序が歪ん/libでい/usr/libます。 では、ld.soライブラリのパスを検索する順序は何ですか?なぜ/lib以前に検索されるの/usr/libですか?そうでない場合、追加のディレクトリが検索されるのはなぜ/libですか?

2
NixOSでバイナリを実行できません-そのようなファイルまたはディレクトリはありません
NixOSを実行しているVMに現在のOracle jreをインストールしようとしました。 次のことが起こります: [michas@cc:~]$ tar xvzf jre-7u40-linux-x64.tar.gz |grep bin/java jre1.7.0_40/bin/javaws jre1.7.0_40/bin/java_vm jre1.7.0_40/bin/java [michas@cc:~]$ ls -l ./jre1.7.0_40/bin/java -rwxr-xr-x 1 michas nogroup 7750 Aug 27 09:17 ./jre1.7.0_40/bin/java [michas@cc:~]$ ./jre1.7.0_40/bin/java bash: ./jre1.7.0_40/bin/java: No such file or directory WTF?指定されたファイルは明らかにそこにあります。何が起こっている? さらに分析しようとしています: [michas@cc:~]$ strace ./jre1.7.0_40/bin/java execve("./jre1.7.0_40/bin/java", ["./jre1.7.0_40/bin/java"], [/* 53 vars */]) = -1 ENOENT (No such …

2
ELF共有ライブラリ-PLTの動機
自己変更コードを使用して、動的にリンクされたライブラリでの関数呼び出しを高速化できますか? 私が理解している限り、ELF共有ライブラリは、一種の間接ジャンプテーブル(プロシージャリンケージテーブル、またはPLT)を使用して、ライブラリ関数の遅延バインディングを有効にします。目的は、最初の呼び出しで関数位置の遅延解決を有効にしながら、コードセグメントのテーブルを変更する必要を回避することです。 ロード時に、または場合によっては最初の関数呼び出しでさえ、そのテーブルのコードを動的に作成する方が高速ではないでしょうか? プロセス間でコードセグメントをできるだけ共有できるようにしますか(動的テーブルはプロセス専用になります)?セキュリティ上の理由からですか(書き込み可能なコードは実行可能であってはなりません -しかし、JITは常にそうしているので、実際にプログラムを起動する前に、ローダーが書き込み権限を追加および削除できます)。 それともそれらの組み合わせであり、関数呼び出しごとの小さなパフォーマンスの向上は努力の価値がないでしょうか?


1
ELF実行可能ファイルのどの部分がメモリに読み込まれますか?
私がすでに知っていること: ELF実行可能ファイルにはいくつかのセクションがあり、.textセクションと.dataセクションはプログラムの主要な部分であるため、メモリにロードされます。しかし、プログラムが機能するためには、特に動的にリンクされている場合、より多くの情報が必要です。 私が興味を持っているのは、.plt、.got、.dynamic、.dynsym、.dynstrなどのセクションです。関数とアドレスのリンクを担当するELFの部分。 私がこれまでに理解できたことから、.symtabや.strtabなどのものがメモリにロードされない(またはとどまらない)ことです。しかし、リンカは.dynsymと.dynstrを使用していますか?彼らは記憶に残っていますか?プログラムコードからそれらにアクセスできますか? そして、カーネルメモリに常駐する実行可能ファイルの部分はありますか? これに対する私の関心は主に法医学ですが、このトピックに関する情報があれば役立ちます。これらのテーブルと動的リンクについて私が読んだリソースはより高レベルであり、それらは動作を説明するだけであり、メモリの内容について実用的なものは何もありません。 質問について不明な点がある場合はお知らせください。

2
共有ライブラリの複数のバージョンをインストールできないのはなぜですか?
多くの場合、特定のプログラムがライブラリバージョンxyとxzに依存するプログラムがありますが、私が知る限り、xyとxzの両方をインストールできるパッケージマネージャーはありません。 qt4とqt5は同時にインストールできます)が、(おそらく)マイナーバージョンではありません。 どうしてこれなの?のように、それを妨げる制限要因は何ですか?この一見便利な機能を許可しないことには、十分な理由があるはずだと思います。たとえば、共有オブジェクトをロードするときにロードするバージョンを示すフィールドがないため、Linuxがロードするものを決定する方法を知る方法はありませんか?それとも理由は本当にないのですか?とにかく、すべてのマイナーバージョンは互換性があると思われますか?


2
置き換えたばかりのライブラリの古いバージョンを使用している実行中のプログラムを特定する
CVE-2014-0160(OpenSSL Heartbleedバグ)に対処するためのアップデートをインストールした後、libsslを使用している可能性のあるものを再起動するように注意する必要がありました-Apacheや私のVPNソフトウェアなどの多くのサービスには、古い脆弱なlibsslがまだロードされていますアップ、そして私のパッケージマネージャーはこれを修正しようとしませんでした。 これは私に考えさせられました:共有ライブラリを更新した後、どのバージョンの実行中のプログラムが現在ライブラリの古いバージョンにリンクされているかを確実に見つけるにはどうすればよいですか?実行中のプロセスにリンカーレベルまたはファイル記述子レベルで問い合わせて、ロードした特定の共有ライブラリのインスタンスが現在ディスク上にあるインスタンスと同じであるかどうかを確認する方法が必要だと思います。

2
実行時にnixによってインストールされたライブラリを使用する方法
私が使用しているnix私はルートじゃないシステムで「シングルユーザモード」で(私のnixのセットアップの説明については以下を参照)。 システムに存在しないライブラリに動的にリンクされているバイナリの1つをすばやく実行したいと思っていました。 だから、私はライブラリをインストールしましたnix: $ nix-env -qa 'gmp' gmp-4.3.2 gmp-5.1.3 $ nix-env -i gmp-5.1.3 しかし、ライブラリはまだリンカによって見つかりません: $ ldd -r ../valencies ../valencies: /lib64/libc.so.6: version `GLIBC_2.15' not found (required by ../valencies) ../valencies: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ../valencies) linux-vdso.so.1 => (0x00007fffbbf28000) /usr/local/lib/libsnoopy.so (0x00007f4dcfbdc000) libgmp.so.10 => not found libffi.so.5 => /usr/lib64/libffi.so.5 (0x00007f4dcf9cc000) libm.so.6 …

1
開始アドレスに対する静的リンクと動的リンクの影響
簡単なCプログラムがあります。走る: $ gcc Q1.c -Wall -save-temps -o Q1 次に、生成された実行可能ファイルを検査します。 $ objdump -f Q1 Q1: file format elf32-i386 architecture: i386, flags 0x00000112: EXEC_P, HAS_SYMS, D_PAGED start address 0x080483b0 次に、静的リンクを使用してコンパイルします。 $ gcc Q1.c -Wall -save-temps -static -o Q1 そしてファイルをもう一度調べます: $ objdump -f Q1 Q1: file format elf32-i386 architecture: i386, flags 0x00000112: EXEC_P, …

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.