crle - 実行時リンク環境の構成
crle [-64] [-a name] [-A name] [-c conf] [-e env] [-E env] [-f flags] [-i name] [-I name] [-g name] [-G name] [-l dir] [-o dir] [-s dir] [-t] [-u] [-v]
crle ユーティリティーを使用すると、実行時リンク構成ファイルを作成および表示できます。構成ファイルは、プロセスの開始時に実行時リンカー ld.so.1(1) によって読み取られ、解釈されます。実行時リンカーは、全プロセスのデフォルト構成ファイルを読み取ろうとします。32 ビットプロセスの場合、デフォルトの構成ファイルは /var/ld/ld.config です。64 ビットプロセスの場合、デフォルトの構成ファイルは /var/ld/64/ld.config です。
引数が指定されていないか、–c オプションのみが指定されている場合、crle は構成情報を表示します。この情報には、構成ファイルの内容、すべてのシステムデフォルト、および構成ファイルの再生成に必要なコマンド行が含まれます。ほかのオプションとともに使用すると、新しい構成ファイルが作成または更新されます。
LD_CONFIG ファミリ環境変数のいずれかを設定して、実行時リンカーを代替構成ファイルに接続することもできます。LD_CONFIG は、32 ビットと 64 ビットの両方のプログラムに適用されます。32 ビットと 64 ビットの構成ファイルは異なるため、1 つの構成ファイルを両方のオブジェクトクラスに使用することはできません。このため、あるクラスのプログラムが別のクラスのプログラムを実行する場合、LD_CONFIG がプログラムの実行に悪影響を及ぼすことがあります。特に、32 ビットバージョンの標準の Solaris ユーティリティーがその 64 ビットバージョンを実行するということがよくあります。この場合、LD_CONFIG を正しく使用することはできません。したがって、プロセスの適切なクラスが正しくターゲットとして指定された LD_CONFIG_32 および LD_CONFIG_64 環境変数を使用することをお勧めします。
標準の場所である /var/ld に不正な構成ファイルを作成すると、プログラムが実行されず、それにより回復が困難になる可能性があります。このような状況にならないようにするために、新しい構成ファイルは一時的な場所に作成することをお勧めします。次に、適切な LD_CONFIG 環境変数をこの新しい構成ファイルに設定します。この設定によって、実行時リンカーが、デフォルトではなく新しい構成ファイルを使用するようになります。検証が終わったら、必要に応じて新しい構成ファイルをデフォルトの場所に移動できます。いつでも環境変数 LD_NOCONFIG を任意の値に設定して、実行時リンカーに構成ファイルを無視するように指示できます。この設定は、実験を行う場合に役立ちます。
構成ファイルには次の情報を含めることができます。
実行時リンカーは、指定した検索パスを使って、オブジェクトの動的な依存関係を検索します。この検索パスは、LD_LIBRARY_PATH 定義のコンポーネントで始まり、その後ろにオブジェクトの runpath のコンポーネントが続きます。最後に、オブジェクトのクラスに固有のデフォルト検索パスが使用されます。検索パスの最後のコンポーネントは、構成ファイル内に記述できます。通常、この機能を使用するときは、システムデフォルトと組み合わせて機能を拡張してください。–l および –u オプションを参照してください。
実行時リンカーは、セキュリティー保護されたアプリケーションを処理する際、LD_LIBRARY_PATH 検索および $ORIGIN トークン拡張の使用を制限します。リンカーとライブラリガイドの実行時のセキュリティーに関するセクションを参照してください。また、事前に読み込まれたライブラリや監査ライブラリを検索できるディレクトリも制限されます。事前に読み込まれたライブラリや監査ライブラリに関連付けるパス名は、既知のトラストディレクトリに制限されます。トラストディレクトリは、構成ファイル内に記述できます。通常、この機能を使用するときは、システムデフォルトと組み合わせて機能を拡張してください。–s および –u オプションを参照してください。
実行時リンカーによって解釈されるすべての環境変数は、構成ファイル内で指定できます。
定義済みディレクトリ内部の共有オブジェクトの場所を、構成ファイル内でキャッシュとして管理できます。このディレクトリキャッシュによって、アプリケーションの依存関係を検索する際のオーバーヘッドを減らすことができます。
ディレクトリキャッシュとともに、共有オブジェクトの代替オブジェクトを指定して実行時に使用できます。これらの代替オブジェクトは、ユーザーが指定できます。また、crle を使用すると、既知のメモリー位置に固定された共有オブジェクトのコピーとして代替オブジェクトも作成できます。これらの固定代替オブジェクトは、元の共有オブジェクトよりも実行時の処理が少なくて済みます。
追加のデフォルト検索パスやトラストディレクトリを定義することは、管理者が他社のソフトウェアを 1 つの場所にインストールする場合に役立ちます。定義しない場合は、適切な runpath でコーディングされていない可能性があるアプリケーションの検索パスを変更することになります。
代替オブジェクトを宣言すると、シンボリックリンクを使用したり、LD_LIBRARY_PATH を設定したりせずに、依存関係を置き換えることができます。
実行時リンカーによって解釈される環境変数を宣言すると、すべてのアプリケーションの定義を集中管理できます。
ディレクトリキャッシュおよび crle によって生成される代替オブジェクトを使用すると、アプリケーション実行時の起動オーバーヘッドを減らすことができます。代替オブジェクトは、多数の依存関係が必要なアプリケーションや依存関係の再配置に大きな負荷がかかるアプリケーションで役に立つ場合があります。position-dependent コードを含む共有オブジェクトでは、再配置に大きな負荷がかかることがよくあります。システムには負のパス検索などの負荷の軽減に役立つキャッシュ機能が多数備わっているため、crle を使用したディレクトリキャッシュを作成すると、一部のごく限定的な場合を除いて影響が最小限で済みます。
crle によって生成される代替オブジェクトが構成ファイル内で指定されている場合、実行時リンカーは最小限の一貫性検証を実行します。代替オブジェクトは元のオブジェクトと照合されます。この照合の目的は、アプリケーション構成情報が基盤となるシステムコンポーネントと同期しなくなった場合にアプリケーション障害を回避することです。こうした状況が発生すると、動的リンクシステムコンポーネントの柔軟性が損なわれることがあります。このようなアプリケーション障害は、診断が非常に困難な場合があります。ディレクトリキャッシュ情報の検証は行われません。キャッシュを再構築しないかぎり、ディレクトリ構造へのどのような変更もプロセスで検出できません。
多くの場合、システム共有オブジェクトは適切に調整されているため、キャッシュされることによるメリットはほとんどありません。通常、ディレクトリキャッシュと代替オブジェクトの機能はユーザーアプリケーションや共有オブジェクトに適用されますが、一部のごく限定的な場合にしか機能は向上しません。
crle は、–I および –G オプションを使用したときに検出される共有オブジェクトの代替オブジェクトを、dldump(3C) を使用して作成します。代替オブジェクトは、直前の –o オプションで指定されたディレクトリ内に作成されます。デフォルトでは、構成ファイルが作成されたディレクトリになります。dldump() によって使用されるフラグは、–f オプションを使用して指定されるか、またはデフォルトで RTLD_REL_RELATIVE になります。
以下のオプションがサポートされています。
64 ビットオブジェクトを処理するよう指定します。デフォルトは 32 ビットです。–64 は、64 ビット固有の構成ファイルを作成する場合に使用します。
name の代替パス名を作成します。代替パス名は構成ファイルに追加されます。
実際の代替ファイルは、ユーザーが準備する必要があります。このオプションは複数回指定できます。name がディレクトリの場合、ディレクトリ内の各共有オブジェクトがキャッシュに追加されます。name が存在しない場合、name は、存在しないファイルとしてキャッシュ内でマークされます。
通常、このオプションは –o オプションとともに使用されます。
name のオプションの代替パス名を作成します。この代替パス名は構成ファイルに追加されます。
このオプションは、–a オプションと同じように動作します。ただし、実行時に代替が使用できない場合には元のオブジェクト name が使用されます。これは、補助フィルタを使用するのと同じような動作です。リンカーとライブラリガイドの補助フィルタの生成を参照してください。
通常、このオプションは –o オプションとともに使用されます。
構成ファイル名 conf を使用するよう指定します。このオプションを指定しないと、デフォルトの構成フィルが使用されます。
置き換え可能な環境変数 env を指定します。このオプションが意味を持つのは、実行時リンカーに適用可能な環境変数だけです。このオプションは複数回指定できます。このオプションは、–E オプションに似ています。ただし、構成ファイル定義、および同じ名前のプロセス環境定義を実行時に解決する方法が異なります。
構成ファイル内で指定された定義は、プロセス環境定義でオーバーライドするか、または NULL 値のプロセス環境定義で抑制することができます。
つまり、これらの構成ファイル定義は、実行時にプロセス環境で置換または削除できます。
永続的な環境変数 env を指定します。このオプションが意味を持つのは、実行時リンカーに適用可能な環境変数だけです。このオプションは複数回指定できます。このオプションは、–e オプションに似ています。ただし、構成ファイル定義、および同じ名前のプロセス環境定義を実行時に解決する方法が異なります。
実行時リンカーにとって意味がある環境変数定義は、2 つのどちらかのカテゴリに分けられます。単数定義は、LD_NOLAZYLOAD=1 や LD_DEBUG_OUTPUT=file などの定義です。1 つまたは複数の値を取ることのできるリスト定義は、LD_LIBRARY_PATH=path や LD_DEBUG=files,details などの定義です。
構成ファイルに記述された単数定義は、プロセス環境定義よりも優先されます。構成フィルに記述されたリスト定義は、プロセス環境定義に追加されます。構成ファイル内で記述された定義を、NULL 値のプロセス環境定義で無効にすることはできません。
つまり、これらの構成ファイル定義は、実行時にプロセス環境で置換および削除できません。
代替オブジェクトの生成に使用される dldump(3C) の呼び出しに対してシンボリック flags 引数を指定します。/usr/include/dlfcn.h で定義された任意の RTLD_REL フラグを使用できます。「|」文字を使用すると、複数のフラグを OR 接続できます。この場合、シェルによって拡張されないようにするため、文字列を引用符で囲んでください。flags 値が指定されていない場合、デフォルトのフラグは RTLD_REL_RELATIVE です。
name を構成キャッシュに個別に追加します。このオプションは複数回指定できます。name には共有オブジェクトまたはディレクトリを指定できます。name がディレクトリの場合、ディレクトリ内の各共有オブジェクトがキャッシュに追加されます。name が存在しない場合、name は、存在しないディレクトリとしてキャッシュ内でマークされます。
–i と同じように動作するだけでなく、dldump(3C) を使用して、処理対象のすべての共有オブジェクトの代替を作成します。–f フラグに RTLD_REL_EXEC が含まれている場合は、name を動的実行可能ファイルにすることができ、そのファイルの代替が作成されます。作成されるキャッシュはこのアプリケーションに固有であるため、この方法で指定できる動的実行可能ファイルは 1 つだけです。
グループ name を構成キャッシュに追加します。各オブジェクトが展開されて、依存関係が特定されます。このオプションは複数回指定できます。name には、動的実行可能ファイル、共有オブジェクト、またはディレクトリを指定できます。name が共有オブジェクトの場合、共有オブジェクトおよびその依存関係がキャッシュに追加されます。name がディレクトリの場合、ディレクトリ内の各共有オブジェクトとその依存関係がキャッシュに追加されます。
–g オプションと同じように動作するだけでなく、dldump(3C) を使用して、処理対象のすべての共有オブジェクトの代替を作成します。name が動的実行可能ファイルであり、かつ –f フラグに RTLD_REL_EXEC が含まれている場合は、その動的実行可能ファイルの代替も作成されます。作成されるキャッシュはこのアプリケーションに固有であるため、この方法で指定できる動的実行可能ファイルは 1 つだけです。
ELF オブジェクトの新しいデフォルト検索ディレクトリ dir を指定します。このオプションは複数回指定できます。
32 ビット ELF オブジェクトのデフォルト検索パスは順番に /lib、/usr/lib です。64 ビット ELF オブジェクトのデフォルト検索パスは、順番に /lib/64、/usr/lib/64 です。
このオプションを使用すると、デフォルトの検索パスが置き換えられます。このため、通常は、–l オプションを使用して、適用される新しいパスに対応する元のシステムデフォルトを指定する必要があります。ただし、–u オプションが有効で、かつ構成ファイルが存在しない場合は、システムデフォルトが新しい構成ファイルに追加されます。これらのデフォルトは、–l オプションで指定する新しいパスの前に追加されます。
–a または –A オプションとともに使用される場合、代替オブジェクトが存在するディレクトリ dir を指定します。代替オブジェクトが crle によって作成される場合、このオプションで代替の作成場所を指定します。このオプションを指定しない場合、代替オブジェクトは構成ファイルが作成されるディレクトリ内に存在します。このオプションは複数回指定でき、ディレクトリ dir は、以降のコマンド行オプションの代替を検索するために使用されます。代替オブジェクトで元の関連オブジェクトをオーバーライドすることは許可されません。
通常、このオプションは –a または –A オプションとともに使用されます。
セキュアな ELF オブジェクトの新しいトラストディレクトリ dir を指定します。このオプションは複数回指定できます。
セキュアなオブジェクトの定義については、ld.so.1(1) の「セキュリティー」を参照してください。セキュアなアプリケーションに適用される実行時制限については、リンカーとライブラリガイドの実行時のセキュリティーに関するセクションを参照してください。
セキュリティー保護された 32 ビット ELF オブジェクトのデフォルトのトラストディレクトリは順番に /lib/secure、/usr/lib/secure です。セキュアな 64 ビット ELF オブジェクトの場合、デフォルトのトラストディレクトリは順番に /lib/secure/64、/usr/lib/secure/64 です。
このオプションを使用すると、デフォルトのトラストディレクトリが置き換えられます。このため、通常は、–l オプションを使用して、適用される新しいディレクトリに対応する元のシステムデフォルトを指定する必要があります。ただし、–u オプションが有効で、かつ構成ファイルが存在しない場合は、システムデフォルトが新しい構成ファイルに追加されます。これらのデフォルトは、–l オプションで指定する新しいディレクトリの前に追加されます。
廃止。「注意事項」を参照してください。
構成ファイルの更新を要求します (通常は、新しい情報を追加して更新します) 。ほかのオプションを指定しないと、既存のすべての構成ファイルが検査され、その内容が再計算されます。 引数を追加すると、再計算された内容に情報を追加できます。「注意事項」を参照してください。
構成ファイルが存在しない場合は、ほかの引数で指定されたとおりに構成ファイルが作成されます。–l および –s オプションの場合は、まずシステムのデフォルトがすべて構成ファイルに適用されてから、これらのオプションで指定されたディレクトリが適用されます。
構成ファイルを、通常ならファイルの先頭に記述されるシステム識別情報が存在しない、古い形式にすることもできます。この場合、crle は生成されるファイルにシステム識別情報を記録しないため、古いバージョンの Solaris との互換性が維持されます。「注意事項」を参照してください。
詳細表示モードを指定します。構成ファイルの作成時には、処理中のファイルの追跡情報が標準出力に書き込まれます。構成ファイルの内容の出力時には、ディレクトリとファイルに関するより広範囲な情報が表示されます。
デフォルトでは、実行時リンカーは、処理対象の 32 ビットアプリケーションごとに構成ファイル /var/ld/ld.config を読み取ろうとします。64 ビットアプリケーションの場合は、それぞれ /var/ld/64/ld.config が読み取られます。実行時リンカーは、代替アプリケーションを処理する際に、$ORIGIN/ld.config.app-name 構成ファイルを使用します (存在する場合)。「注意事項」を参照してください。LD_CONFIG 環境変数を設定すると、アプリケーションから代替構成ファイルを参照できるようになります。アプリケーションの構築時に構成ファイル名をアプリケーションに記録して、代替構成ファイルを指定することもできます。ld(1) の –c オプションを参照してください。
次の例では、ELF オブジェクトの新しいデフォルト検索パスを使用して一時構成ファイルを作成します。環境変数 LD_CONFIG_32 を使用して、すべての 32 ビットプロセスでこの構成ファイルを使用するよう実行時リンカーに指示します。
$ crle -c /tmp/ld.config -u -l /local/lib
$ crle -c /tmp/ld.config
Configuration file [version 4]: /tmp/ld.config
Platform: 32-bit MSB SPARC
Default Library Path (ELF): /lib:/usr/lib:/local/lib
Trusted Directories (ELF): /lib/secure:/usr/lib/secure \
(system default)
Command line:
crle -c /tmp/ld.config -l /lib:/usr/lib:/local/lib
$ LD_CONFIG_32=/tmp/ld.config date
Wednesday, April 23, 2014 01:27:17 PM PDT
使用例 2 ELF オブジェクトの新しいデフォルト検索パスの更新および表示
次の例では、ELF オブジェクトの新しいデフォルト検索パスを更新して表示します。
# crle -u -l /local/lib
# crle
Configuration file [version 4]: /var/ld/ld.config
Platform: 32-bit MSB SPARC
Default Library Path (ELF): /lib:/usr/lib:/local/lib
Trusted Directories (ELF): /lib/secure:/usr/lib/secure \
(system default)
Command line:
crle -l /lib:/usr/lib:/local/lib
# crle -u -l /ISV/lib
# crle
Configuration file [version 4]: /var/ld/ld.config
Platform 32-bit MSB SPARC
Default Library Path (ELF): /lib:/usr/lib:/local/lib:/ISV/lib
Trusted Directories (ELF): /lib/secure:/usr/lib/secure \
(system default)
Command line:
crle -l /lib:/usr/lib:/local/lib:/usr/local/lib
この例では、最初はデフォルトの構成ファイルがありませんでした。このため、システムデフォルトに新しい検索パス /local/lib が追加されます。次の更新により、すでに構成ファイル内で確立されているこれらのパスに検索パス /ISV/lib が追加されます。
使用例 3 不正な構成ファイルを回復する次の例では、デフォルトの場所に不正な構成ファイルを作成します。環境変数 LD_NOCONFIG を含む構成ファイルをすべて無視するよう実行時リンカーに指示することで、このファイルを削除できます。一時構成ファイルを作成し、環境変数 LD_CONFIG を使用してこれらのファイルを試すことをお勧めします。
# crle -l /local/lib # date ld.so.1: date: fatal: libc.so.1: open failed: \ No such file or directory Killed # LD_NOCONFIG=yes rm /var/ld/ld.config # date Wednesday, April 23, 2014 01:27:17 PM PDT
この構成ファイルにはシステムのデフォルト検索パスが含まれていないため、date ユーティリティーは必要なシステム依存関係を見つけることができません。この場合に使用しなければならないオプションは –u でした。
使用例 4 ELF オブジェクトの新しいデフォルト検索パスと新しいトラストディレクトリの作成および表示次の例では、ELF オブジェクトの新しいデフォルト検索パスと新しいトラストディレクトリを作成して表示します。
# crle -l /local/lib -l /lib -l /usr/lib -s /local/lib # crle Configuration file [version 4]: /var/ld/ld.config Platform: 32-bit MSB SPARC Default Library Path (ELF): /local/lib:/lib:/usr/lib Trusted Directories (ELF): /local/lib Command line: crle -l /local/lib:/lib:/usr/lib -s /local/lib
この構成ファイルを使用すると、サードパーティー製アプリケーションを /local/bin に、またそれに関連付けられている依存関係を /local/lib にインストールできます。デフォルト検索パスを使用すると、アプリケーションは LD_LIBRARY_PATH を設定しなくてもその依存関係を見つけることができます。この例では、デフォルトのトラストディレクトリも置き換えられています。
使用例 5 ELF オブジェクトのディレクトリキャッシュの作成次の例では、ELF オブジェクトのディレクトリキャッシュを作成します。
$ crle -i /usr/dt/lib -i /usr/openwin/lib -i /lib \
-i /usr/lib -c config
$ ldd -s ./main
....
find object=libc.so.1; required by ./main
search path=/usr/dt/lib:/usr/openwin/lib \
(RUNPATH/RPATH ./main)
trying path=/usr/dt/lib/libc.so.1
trying path=/usr/openwin/lib/libc.so.1
search path=/lib (default)
trying path=/lib/libc.so.1
libc.so.1 => /lib/libc.so.1
$ LD_CONFIG=config ldd -s ./main
....
find object=libc.so.1; required by ./main
search path=/usr/dt/lib:/usr/openwin/lib \
(RUNPATH/RPATH ./main)
search path=/lib (default)
trying path=/lib/libc.so.1
libc.so.1 => /lib/libc.so.1
この構成では、システムライブラリ libc.so.1 がディレクトリ /usr/dt/lib にも /usr/openwin/lib にも存在しないことがキャッシュに反映されています。このため、アプリケーションの runpath でこれらのディレクトリが検索対象となっていても、このシステムファイルの検索では無視されます。
使用例 6 ELF 実行可能ファイルの代替オブジェクトキャッシュの作成次の例では、ELF 実行可能ファイルの代替オブジェクトキャッシュを作成します。
$ crle -c /local/$HOST/.xterm/ld.config.xterm \
-f RTLD_REL_ALL -G /usr/openwin/bin/xterm
$ ln -s /local/$HOST/.xterm/xterm /local/$HOST/xterm
$ ldd /usr/local/$HOST/xterm
libXaw.so.5 => /local/$HOST/.xterm/libWaw.so.5 \
(alternate)
libXmu.so.4 => /local/$HOST/.xterm/libXmu.so.4 \
(alternate)
....
libc.so.1 => /local/$HOST/.xterm/libc.so.1 \
(alternate)
....
この構成を使用すると、新しい xterm およびその依存関係が作成されます。これらの新しいオブジェクトが相互に完全に再配置されるため、元のオブジェクトより起動が高速化されます。このアプリケーションの実行には、独自の構成ファイルが使用されます。このモデルは、ldd(1) や truss(1) などのほかのアプリケーションが構成ファイルを誤って使用することがなくなるため、一般に、環境変数 LD_CONFIG の使用に比べて柔軟性が高くなります。
使用例 7 ELF 共有オブジェクトを置き換えるための代替オブジェクトキャッシュの作成次の例では、ELF 共有オブジェクトを置き換えるための代替オブジェクトキャッシュを作成します。
$ ldd /usr/bin/vi
libcurses.so.1 => /lib/libcurses.so.1
....
# crle -a /lib/libcurses.so.1 -o /usr/xpg4/lib
# crle
Configuration file [version 4]: /var/ld/ld.config
Platform: 32-bit LSB 80386
Default Library Path (ELF): /lib:/usr/lib (system default)
Trusted Directories (ELF): /lib/secure:/usr/lib/secure (system default)
Directory: /lib
libcurses.so.1 (alternate: /usr/xpg4/lib/libcurses.so.1)
....
# ldd /usr/bin/vi
libcurses.so.1 => /usr/xpg4/lib/libcurses.so.1 (alternate)
....
この構成では、通常であれば /usr/lib/libcurses.so.1 に解決される依存関係がすべて、代わりに /usr/xpg4/lib/libcurses.so.1 に解決されます。
使用例 8 置換可能な環境変数および永続的な環境変数を設定する次の例では、置換可能な環境変数と永続的な環境変数を設定します。
# crle -e LD_LIBRARY_PATH=/local/lib \
-E LD_PRELOAD=preload.so.1
# crle
.....
Environment Variables:
LD_LIBRARY_PATH=/local/lib (replaceable)
LD_PRELOAD=preload.so.1 (permanent)
.....
$ LD_DEBUG=files LD_PRELOAD=preload.so.2 ./main
.....
18764: file=preload.so.2; preloaded
18764: file=/local/lib/preload.so.2 [ ELF ]; \
generating link map
.....
18764: file=preload.so.1; preloaded
18764: file=/local/lib/preload.so.1 [ ELF ]; \
generating link map
.....
この構成ファイルでは、置換可能な検索パスが、事前に読み込まれた永続的なオブジェクトとともに指定されており、そのオブジェクトはプロセス環境定義に追加されます。
構成ファイルを作成または表示すると、0 が返されます。それ以外の場合は、どのようなエラー条件でも、診断メッセージとゼロ以外の値がともに返されます。
元のアプリケーションに DT_FLAGS_1 または DT_FEATURE_1 のいずれかの .dynamic タグが含まれている場合は、その代替アプリケーションにタグを付けてアプリケーション固有の構成ファイルを使用できます。これらのエントリが存在しない場合は、LD_CONFIG 環境変数を使用して構成ファイルを指定する必要があります。 後者の方法の場合、フォークされたすべてのアプリケーションからこの環境変数が見えるようになるため、注意してください。
–u オプションを使用するには、 crle のバージョン 2 以降が必要です。このバージョンレベルは、構成ファイルの内容を表示することで確認できます。
$ crle Configuration file [2]: /var/ld/ld.config ......
バージョン 2 の構成ファイルでは、crle は構成ファイルの再生成に必要なコマンド行引数を作成できます。このコマンド行を作成すると、–u オプションを使用して完全な更新を実行できます。バージョン 1 の構成ファイルを更新することはできますが、crle ですべての更新要件を計算するには、構成ファイルの内容が十分ではない可能性があります。
構成ファイルには、プラットフォーム固有のバイナリデータが含まれます。ある特定の構成ファイルは、ソフトウェアによって、同じマシンクラスとバイト順序でのみ解釈できます。構成ファイルには、ファイルの先頭にシステム識別情報が含まれています。この情報は、構成ファイルとの互換性を確認するために crle と実行時によって使用されます。また、この情報によって、file(1) コマンドは構成ファイルを正しく識別できます。下位互換性を確保するため、この情報が不足している古いファイルも受け入れられますが、新しいファイルでは可能な識別とエラー検査は行われません。システム情報が含まれていない以前のファイルに対する更新 (–u) 操作の処理中に、crle がその結果にシステム識別情報を追加することはありません。
Oracle Solaris 11 は、SPARC ハードウェア上の SunOS 4.x AOUT 実行可能ファイルに対するサポートを中止しました。この変更の前は、–t オプションによって ELF または AOUT のオブジェクトタイプを表すための切り替えが提供され、それが以降のすべての –l または –s オプションに影響を与えました。–t オプションは現在廃止されているため、AOUT 固有の指示はすべて無視され、その影響に対する警告が表示されます。同じ理由で、crle を使用して AOUT の情報を含む古い構成ファイルを検査すると、その情報が廃止されたことを知らせる警告メッセージが生成されます。
32 ビットアプリケーション用のデフォルトの構成ファイル。
64 ビットアプリケーション用のデフォルトの構成ファイル。
一時構成ファイルのデフォルトの場所。tempnam(3C) を参照してください。
dldump(3C) 32 ビットオブジェクトに対して使用されるスタブアプリケーション。
dldump(3C) 64 ビットオブジェクトに対して使用されるスタブアプリケーション。
dldump(3C) 32 ビットオブジェクトに対して使用される監査ライブラリ。
dldump(3C) 64 ビットオブジェクトに対して使用される監査ライブラリ。
crle によって参照される環境変数はありません。ただし、いくつかの環境変数は、crle によって作成される構成ファイルの処理に関する実行時リンカーの動作に影響を及ぼします。
代替構成ファイルを指定します。
構成ファイルの処理を無効にします。
構成ファイルからのディレクトリキャッシュ処理を無効にします。
構成ファイルからの環境変数処理を無効にします。
構成ファイルからの代替オブジェクト処理を無効にします。
次の属性については、attributes(5) を参照してください。
|
file(1), ld(1), ld.so.1(1), dldump(3C), tempnam(3C), attributes(5)
リンカーとライブラリガイド