動的リンク

ウィキペディア

動的リンク

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/10/25 17:04 UTC 版)

動的リンク（どうてきりんく、英語: dynamic link）とは二つの意味がある。

ウィキペディア小見出し辞書

動的リンク

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/03/12 21:29 UTC 版)

「リンケージエディタ」の記事における「動的リンク」の解説

動的リンクは、リンク時にライブラリの参照を名前のみで解決してプログラムを作る方法。出来上がったプログラムにはライブラリの部分のプログラムは含まれないのが特徴である。そのプログラム実行時に、ライブラリ空間上の実際のプログラムと結合し、実行する（この作業は通常ローダと呼ばれるプログラムが行う）。出来上がったプログラムの大きさが小さくなる、プログラムを再度リンクしなくてもライブラリだけ入れ替えることができるなどの利点があり、現在広く使われている。 C言語の標準ランタイムライブラリのような汎用ライブラリは動的リンクするものの、ユーザー定義のライブラリは静的リンクする、あるいは汎用ライブラリは静的リンクするものの、ユーザー定義のライブラリは動的リンクする、両方動的リンクする、両方静的リンクする、といった組み合わせがあり、用途によって使い分けることもある。

動的リンク

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/07/01 06:34 UTC 版)

「ライブラリ」の記事における「動的リンク」の解説

動的リンク (英: dynamic linking) は、あるライブラリ内のデータ（コードを含む）を新たな実行ファイルのビルド時にコピーすることはなく、ディスク上に別のファイルとして存在している。ビルド時にリンカが行うのは、その実行ファイルが必要とするのがどのライブラリのどの部分であるか（関数名やインデックス）を記録するだけである。リンク作業の大部分はそのアプリケーションがメモリ上にロードされたときか、実行時である。リンクを行うプログラムコードはローダ（英: loader）と呼ばれ、実際にはオペレーティングシステム (OS) の一部と見なされる。適当な時点でローダは必要なライブラリをディスク上で見つけてプロセスのメモリ空間に（追加のデータ空間と共に）マッピングする。OSによってはプロセスが実行開始する前でないとライブラリをリンクできないものもあるが、多くのOSではプロセス実行時に実際にライブラリを参照したときにリンクできる。後者は「遅延読み込み」などと呼ばれる。どちらの場合もライブラリは動的リンクライブラリ（ダイナミックリンクライブラリ）と呼ばれる。Windows環境では動的リンクライブラリの略称でもある「DLL」という呼び方が一般的であり、動的ライブラリのファイル拡張子は通例 .dll である。動的リンクライブラリの中でも、システム上の複数の実行プログラムによって共有・再利用されうるものを、共有ライブラリ（シェアードライブラリ）と呼ぶ。 ローダの処理は、メモリ上の各ライブラリの位置が実際にロードされるまで確定しないため、ちょっとしたトリックを必要とする。ディスク上のファイル内に絶対アドレスを書きこんでおくことはDLL内であっても不可能である。理論的にはメモリにロードされたときにライブラリを参照している部分を全て書き換えて正しいメモリ上の位置を参照するようにすることはできるが、それによって消費される時間とメモリは無視できない。その代わりに多くの動的リンクシステムではアドレス欄が空欄となったシンボルテーブルをコンパイル時に用意する。ライブラリへの参照は全てこのシンボルテーブルを経由して行われる（コンパイラはシンボルテーブルからアドレスを取り出して使うコードを生成する）。メモリにロードされたとき、ローダがこのテーブルを書き換える。 ライブラリも全メソッド（関数、サブルーチン）のテーブルを持っている。ライブラリに入ってくるときは、このテーブルを経由して各ルーチンにジャンプする。これによってライブラリのルーチンコールにオーバーヘッドが発生するが、通例それは無視できるほど小さい。 動的リンカ・ローダは機能面で様々なものがある。いくつかの場合、実行ファイルに格納された明示的なライブラリパスに依存し、ライブラリ名やディスク上の配置を変更するとシステムが作動できなくなる。より一般的な手法としてはライブラリ名だけを実行ファイルに格納し、OSが何らかのアルゴリズムでディスク上のライブラリを検索する。Unix系システムでは、ライブラリを探す場所（ディレクトリ）を構成ファイルにリストアップしておく。ライブラリ開発者はそこに書かれたディレクトリにライブラリを配置することを推奨される。しかし、この方法では新しいライブラリをインストールする際に問題が発生しやすく、共通のディレクトリにあまりにも多くのライブラリが置かれることとなって管理を難しくする。Windowsではレジストリを使ってCOMコンポーネントやActiveX DLLの場所を決めているが、標準DLLでは、 アプリケーションの実行ファイルの存在するディレクトリ SetDllDirectory()で指定されるディレクトリ（Windows XP SP1以降でサポート） システムディレクトリ (NT系ではSystem32) 16ビットシステムディレクトリ (System) Windowsディレクトリ カレントディレクトリ PATH環境変数 で示されるディレクトリを探す（古いバージョンではカレントディレクトリが2番目だった）。OPENSTEPはもっと柔軟なシステムを使用していて、ライブラリの探索リストを保持している。しかし不正なDLLが探索の上位に置かれていると実行ファイルは不正動作する可能性がある。Windowsではこれが「DLL地獄」（英: DLL hell）と呼ばれ、よく知られている問題である。 Windows XPからはSide-by-Sideアセンブリ（DLL署名、WinSxS）というメカニズムが追加された。これは動的リンク時にライブラリのファイル名ではなく、ライブラリにつけられた署名によってリンクすべきライブラリを決定するものである。これにより、同じファイル名を持つが異なる実装を持つライブラリを同時に使い分ける事ができる。よくあるパターンとして、ソースコードから改変・ビルドされたランタイムライブラリをシステムにインストールする場合にこのメカニズムが有効に働く。システムにインストールされたライブラリはライブラリ探索リスト上比較的上位に存在するが、署名が一致するプログラムにのみロードされるのでDLL地獄は今後解消されるであろうと考えられる。しかし、この機構には一つの弱点がある。それはシステムライブラリをオーバーライドして独自機能を実装する時、この機構は役に立たない方向へ働く。その様な実装をする時には、故意にマニフェスト機能を無効にしてライブラリを作らなくてはならない。もっとも、そのようなアプローチは、システムファイル保護機能が搭載されたWindows 2000のリリース時点で時代遅れであり、Windows Vistaに至っては管理者と言えどもシステムライブラリを書き換える事は出来なくなっている。 動的ライブラリの起源は定かではないが、少なくとも1960年代後半のMTS (Michigan Terminal System) まで遡ることができる ("A History of MTS", Information Technology Digest, Vol. 5, No. 5)。