[ << ] [ >> ]           [Top] [Contents] [Index] [ ? ]

13. libtoolの管理用メモ

この章は，libtool管理者が見つける重要な情報を含みます．新しいシステムへ の移植や，独自のlibtoolを書くことを考慮しない場合，役に立たないでしょう．

13.1 新しいシステムへのlibtoolの移植   How to port libtool to new systems.
13.2 テストされたプラットフォーム   When libtool was last tested.
13.3 プラットフォームの癖   Information about different library systems.
13.4 libtoolスクリプトの内容   Configuration information that libtool uses.
13.5 安っぽい手段   Making libtool maintainership easier.

13.1 新しいシステムへのlibtoolの移植

サポートされていないシステムへのlibtoolの移植に乗り出す前に，既存の仕事 と重複していないことを確認するために，the libtool mailing list libtool@gnu.orgに電子メールを送る 価値はあります．

移植の文章が見つからない場合，文句を言ってください！ パッチを用いた苦情 と，ドキュメントやlibtool自身の改良は十分に歓迎されます．

13.1.1 情報源   Where to find relevant documentation
13.1.2 ライブラリ内部の依存性のサポートの移植   Implementation details explained

13.1.1 情報源

新たな移植の必要性が明らかになると，通常，以下の情報が必要となります．

標準的なシステム名

他のシステムに影響しないようにlibtoolのコンフィグレーション処理を変更可 能にするため，このシステムに対するconfig.guessの出力が必要です．

ldとccに対するmanページ

共有ライブラリを作成するため，共有ライブラリのみにリンクするため，そして， PICを生成するために使用するフラグを，通常これらは記述しています．必要な 情報を見つけるため，以下の相互参照が必要かもしれません．

ld.so，rtld，または，その同等物のmanページ

これらは，システムで共有ライブラリがロードされる仕組みを理解するための， 有益な情報源です．

ldconfigやその同等物のmanページ

このページは，通常，共有ライブラリをインストールする方法を記述します．

ls -l /lib /usr/libの出力

これは，システムの共有ライブラリの命名規則を表示し，それは，シンボリック リンクの名前も含んでいます．

あらゆる追加の文章

共有ライブラリの構築とインストール方法の特別な文章があるシステムもありま す．

Bourneシェルプログラムの方法を知っている場合，完全に自分で移植することが 可能です．それ以外の場合，関連する作業を行う腕のある人を探す必要がありま す．libtoolメーリングリストの人々は，新たな移植への援助を志願する意思が あるので，彼らに情報を送ることができます．

独自に移植するためには，プラットフォーム特有のコンフィグレーションプロセ スの変更を行うため，libtool.m4マクロを明確に修正する必要がありま す．PORTMEキーワードに対するファイルを検索する必要があり，それで， 変更に必要なヒントを得られるでしょう．一般的に，呼び出されるものは，適切 なコンフィグレーション変数の編集です(see section libtoolスクリプトの内容)．

最善策は，既にサポートされている良く似たシステムを見つけ，変更の基本とす ることです．しかし，システムが他のサポートされているシステムと，大きく異 なる場合や，新しいコンフィグレーション変数を加え，それに応じて ltmain.inスクリプトを変更する必要がある場合もあります．欲しいもの を達成するための，最も効果的な方法の助言がある可能性があるので， ltmain.inを変更する前に，メーリングリストに書いて確認してください．

13.1.2 ライブラリ内部の依存性のサポートの移植

バージョン1.2c以降，libtoolは，Toshio Kuratomi badger@prtr-13.ucsc.eduのパッチのおかげで，ライブラリ内部の依存 性を可能とする機能が再導入されてるプラットフォームもあります．パッチに含 まれるメッセージの短いバージョンは以下のようになります．

基本的な体系はこのようになります．`libtool.m4'で，libtoolを書いてい る人は，`$deplibs'が`$archive_cmds'のどこかに含まれていること， また，変数`$deplibs_check_method'と，`deplibs_check_method'が ファイルマジックの場合は`$file_magic_cmd'が設定されていることを確認 します．

`deplibs_check_method'は，以下の５つの内の一つのはずです．

` file_magic [regex]'

ライブラリリンクパスで正しいlibnameを持つライブラリを探します．そして， ライブラリで`$file_magic_cmd'を実行し，egrepを使用した regexに一致することを調査します．file_magic_test_fileが `libtool.m4'によって設定されているとき，正規表現がその出力と一致す るかどうかを検証し，それ以外ではユーザが警告を受けるようにするため，それ は`$file_magic_cmd'への引数として使用されます．

` test_compile'

ライブラリリストの出力以外とプログラムがリンク可能かどうかのみを調査し， それらがlddの出力でリストアップされていることを調査します．それは 現在，使用されておらず，将来は打ち切る可能性があります．

` pass_all'

調査せず，すべて通過します．例えばDEC OSF/1 3 と 4のような，デフォルトで， コードが位置に依存せず，ライブラリ内部の依存性がダイナミックリンカで適切 にサポートされているプラットフォームで，これは動作するでしょう．

` none'

deplibsをdeplibs=""に再設定します．そのように，`archive_cmds'は，す べてのプラットフォームでdeplibsを含むはずですが，deplibは必要がなければ 使用されません．

` unknown'

`libtool.m4'で優先されない場合，すべてのシステムでデフォルトです． それは`none'と同じですが，正しい値が何か，我々が本当に知らないこと を文章化していて，我々はそれを改善するパッチを歓迎します．

`ltmain.in'で，我々は本当に一生懸命作業しました．それは， (libname_spec等の評価を使用するための変数を設定/リリース行う)小さな初期 化と移植，そして使用するメソッドを決定するケース文です．これは，実際には コードです... もう少し凝縮できれば良かったのですが，関数呼び出しを用い ずにできるとは思えませんでした．私はほとんどの(ループの外に出す等の)最適 化を行いましたが，余分なものがあるかもしれません．明確な最適化を考える前 に，前進を止め，発見されたバグに対して作業すべきだと考えました．

13.2 テストされたプラットフォーム

この表は，共有ライブラリのサポートを謡っているプラットフォームで， libtoolがテストされたことが分かっている最後の時期を記述しています．

 
-------------------------------------------------------
標準的なホスト名            コンパイラ libtool   結果
(ツールのバージョン)                   リリース
-------------------------------------------------------
alpha-dec-osf5.1		cc	 1.3e	  ok (1.910)
alpha-dec-osf4.0f               gcc      1.3e     ok (1.910)
alpha-dec-osf4.0f               cc       1.3e     ok (1.910)
alpha-dec-osf3.2                gcc      0.8      ok
alpha-dec-osf3.2                cc       0.8      ok
alpha-dec-osf2.1                gcc      1.2f     NS
alpha*-unknown-linux-gnu        gcc      1.3b     ok
  (egcs-1.1.2, GNU ld 2.9.1.0.23)
hppa2.0w-hp-hpux11.00           cc       1.2f     ok
hppa2.0-hp-hpux10.20            cc       1.3.2    ok
hppa1.1-hp-hpux10.20            gcc      1.2f     ok
hppa1.1-hp-hpux10.20            cc       1.3c     ok (1.821)
hppa1.1-hp-hpux10.10            gcc      1.2f     ok
hppa1.1-hp-hpux10.10            cc       1.2f     ok
hppa1.1-hp-hpux9.07             gcc      1.2f     ok
hppa1.1-hp-hpux9.07             cc       1.2f     ok
hppa1.1-hp-hpux9.05             gcc      1.2f     ok
hppa1.1-hp-hpux9.05             cc       1.2f     ok
hppa1.1-hp-hpux9.01             gcc      1.2f     ok
hppa1.1-hp-hpux9.01             cc       1.2f     ok
i*86-*-beos                     gcc      1.2f     ok
i*86-*-bsdi4.0.1                gcc      1.3c     ok
  (gcc-2.7.2.1)
i*86-*-bsdi4.0                  gcc      1.2f     ok
i*86-*-bsdi3.1                  gcc      1.2e     NS
i*86-*-bsdi3.0                  gcc      1.2e     NS
i*86-*-bsdi2.1                  gcc      1.2e     NS
i*86-pc-cygwin                  gcc      1.3b     NS
  (egcs-1.1 stock b20.1 compiler)
i*86-*-dguxR4.20MU01            gcc      1.2      ok
i*86-*-freebsd4.3		gcc      1.3e     ok (1.912)
i*86-*-freebsdelf4.0            gcc      1.3c     ok
  (egcs-1.1.2)
i*86-*-freebsdelf3.2            gcc      1.3c     ok
  (gcc-2.7.2.1)
i*86-*-freebsdelf3.1            gcc      1.3c     ok
  (gcc-2.7.2.1)
i*86-*-freebsdelf3.0            gcc      1.3c     ok
i*86-*-freebsd3.0               gcc      1.2e     ok
i*86-*-freebsd2.2.8             gcc      1.3c     ok
  (gcc-2.7.2.1)
i*86-*-freebsd2.2.6             gcc      1.3b     ok
  (egcs-1.1 & gcc-2.7.2.1, native ld)
i*86-*-freebsd2.1.5             gcc      0.5      ok
i*86-*-netbsd1.5                gcc      1.3e     ok (1.901)
  (egcs-1.1.2)
i*86-*-netbsd1.4                gcc      1.3c     ok
  (egcs-1.1.1)
i*86-*-netbsd1.4.3A             gcc      1.3e     ok (1.901)
i*86-*-netbsd1.3.3              gcc      1.3c     ok
  (gcc-2.7.2.2+myc2)
i*86-*-netbsd1.3.2              gcc      1.2e     ok
i*86-*-netbsd1.3I               gcc      1.2e     ok
  (egcs 1.1?)
i*86-*-netbsd1.2                gcc      0.9g     ok
i*86-*-linux-gnu		gcc	 1.3e	  ok (1.901)
  (Red Hat 7.0, gcc "2.96")
i*86-*-linux-gnu		gcc	 1.4.2	  ok
  (SuSE 7.0, gcc 2.95.2)
i*86-*-linux-gnulibc1           gcc      1.2f     ok
i*86-*-openbsd2.5               gcc      1.3c     ok
  (gcc-2.8.1)
i*86-*-openbsd2.4               gcc      1.3c     ok
  (gcc-2.8.1)
i*86-*-solaris2.7               gcc      1.3b     ok
  (egcs-1.1.2, native ld)
i*86-*-solaris2.6               gcc      1.2f     ok
i*86-*-solaris2.5.1             gcc      1.2f     ok
i*86-ncr-sysv4.3.03             gcc      1.2f     ok
i*86-ncr-sysv4.3.03             cc       1.2e     ok
  (cc -Hnocopyr)
i*86-pc-sco3.2v5.0.5		cc	 1.3c	  ok
i*86-pc-sco3.2v5.0.5		gcc	 1.3c	  ok
  (gcc 95q4c)
i*86-pc-sco3.2v5.0.5		gcc	 1.3c	  ok
  (egcs-1.1.2)
i*86-sco-sysv5uw7.1.1		gcc	 1.3e	  ok (1.901)
  (gcc-2.95.2, SCO linker)
i*86-UnixWare7.1.0-sysv5	cc	 1.3c	  ok
i*86-UnixWare7.1.0-sysv5	gcc	 1.3c	  ok
  (egcs-1.1.1)
m68k-next-nextstep3             gcc      1.2f     NS
m68k-sun-sunos4.1.1             gcc      1.2f     NS
  (gcc-2.5.7)
m88k-dg-dguxR4.12TMU01          gcc      1.2      ok
m88k-motorola-sysv4             gcc      1.3      ok
  (egcs-1.1.2)
mips-sgi-irix6.5                gcc      1.2f     ok
  (gcc-2.8.1)
mips-sgi-irix6.4                gcc      1.2f     ok
mips-sgi-irix6.3                gcc      1.3b     ok
  (egcs-1.1.2, native ld)
mips-sgi-irix6.3                cc       1.3b     ok
  (cc 7.0)
mips-sgi-irix6.2                gcc      1.2f     ok
mips-sgi-irix6.2                cc       0.9      ok
mips-sgi-irix5.3                gcc      1.2f     ok
  (egcs-1.1.1)
mips-sgi-irix5.3                gcc      1.2f     NS
  (gcc-2.6.3)
mips-sgi-irix5.3                cc       0.8      ok
mips-sgi-irix5.2                gcc      1.3b     ok
  (egcs-1.1.2, native ld)
mips-sgi-irix5.2                cc       1.3b     ok
  (cc 3.18)
mips-sni-sysv4			cc       1.3.5    ok
  (Siemens C-compiler)
mips-sni-sysv4			gcc      1.3.5    ok
  (gcc-2.7.2.3, GNU assembler 2.8.1, native ld) 
mipsel-unknown-openbsd2.1       gcc      1.0      ok
powerpc-ibm-aix4.3.1.0          gcc      1.2f     ok
  (egcs-1.1.1)
powerpc-ibm-aix4.2.1.0          gcc      1.2f     ok
  (egcs-1.1.1)
powerpc-ibm-aix4.1.5.0          gcc      1.2f     ok
  (egcs-1.1.1)
powerpc-ibm-aix4.1.5.0          gcc      1.2f     NS
  (gcc-2.8.1)
powerpc-ibm-aix4.1.4.0          gcc      1.0      ok
powerpc-ibm-aix4.1.4.0          xlc      1.0i     ok
rs6000-ibm-aix4.1.5.0           gcc      1.2f     ok
  (gcc-2.7.2)
rs6000-ibm-aix4.1.4.0           gcc      1.2f     ok
  (gcc-2.7.2)
rs6000-ibm-aix3.2.5             gcc      1.0i     ok
rs6000-ibm-aix3.2.5             xlc      1.0i     ok
sparc-sun-solaris2.8		gcc	 1.4.2	  ok
  (gcc-2.95.2 & native ld)
sparc-sun-solaris2.8		gcc	 1.4.2	  ok
  (gcc-3.0.1 & GNU ld 2.11.2)
sparc-sun-solaris2.7            gcc      1.3e     ok (1.913)
  (gcc-2.95.3 & native ld)
sparc-sun-solaris2.6            gcc      1.3e     ok (1.913)
  (gcc-2.95.3 & native ld)
sparc-sun-solaris2.5.1          gcc      1.4.2    ok
  (gcc-2.95.1 & GNU ld 2.9.1)
sparc-sun-solaris2.5            gcc      1.3b     ok
  (egcs-1.1.2, GNU ld 2.9.1 & native ld)
sparc-sun-solaris2.5            cc       1.3b     ok
  (SC 3.0.1)
sparc-sun-solaris2.4            gcc      1.0a     ok
sparc-sun-solaris2.4            cc       1.0a     ok
sparc-sun-solaris2.3            gcc      1.2f     ok
sparc-sun-sunos4.1.4            gcc      1.2f     ok
sparc-sun-sunos4.1.4            cc       1.0f     ok
sparc-sun-sunos4.1.3_U1         gcc      1.2f     ok
sparc-sun-sunos4.1.3C           gcc      1.2f     ok
sparc-sun-sunos4.1.3            gcc      1.3b     ok
  (egcs-1.1.2, GNU ld 2.9.1 & native ld)
sparc-sun-sunos4.1.3            cc       1.3b     ok
sparc-unknown-bsdi4.0           gcc      1.2c     ok
sparc-unknown-linux-gnulibc1    gcc      1.2f     ok
sparc-unknown-linux-gnu         gcc      1.3b     ok
  (egcs-1.1.2, GNU ld 2.9.1.0.23)
sparc64-unknown-linux-gnu       gcc      1.2f     ok

注意:
- "ok" は，"すべてのテストを通過した"ことを意味します．
- "NS" は，"共有に失敗"("Not Shared")を意味しますが，
           スタティックライブラリはOKです．

注：ベンダー配布されているHP-UXのsed(1)プログラムは，ひどく壊れて いて，libtoolの要求を処理することができないため，ユーザは異常の問題を報 告する可能性があります．これらのシステムで動作する(GNU sed)のよう なsedをインストールする以外に，回避方法はありません．

注：ベンダー配布されているNCR MP-RAS ccプログラムは，標準エラーに 著作権を出力し，`conftest.err'の大きさのテストで混乱します．回避方 法は，configureを実行するとき，CC='cc -Hnocopyr'を用いて CC を指定します．

13.3 プラットフォームの癖

このセクションは，libtoolの管理者の健康に捧げます．それは，libtoolが使用 するプログラム，システムごとの違い，そしてテストの方法を記述します．

libtoolはシェルスクリプトなので，最初から最後まで読むだけで理解すること は難しいはずです．このセクションは，libtoolが特定の方法で行う理由の理解 を助けます．スクリプト自身が組み合わされているので，libtoolの改善や，独 自に書く方法の，より良いセンスが必要でしょう．

13.3.1 リファレンス   Finding more information.
13.3.2 コンパイラ   Creating object files from source files.
13.3.3 リロード可能なオブジェクト   Binding object files together.
13.3.4 複数の依存性   Removing duplicate dependant libraries.
13.3.5 アーカイバ   Programs that create static archives.

13.3.1 リファレンス

以下は，価値のある文章の参照リストです．

13.3.2 コンパイラ

libtoolに影響するコンパイラの特徴は，PICオブジェクトを生成するための(存 在する場合は)必要なフラグのみです．一般的に，Cコンパイラが特定のPICフラ グをサポートする場合，あらゆる派生的なコンパイラは同じフラグをサポートし ます．この規則に対し，注目すべき若干の例外があるまでは，このセクションで はCコンパイラのみを説明します．

プラットフォームに関係なく，以下のCコンパイラは，標準のコマンドライオプ ションがあります．

gcc

これはGNU Cコンパイラで，多くのフリーオペレーティングシステム(少し例をあ げると，FreeBSD，GNU/Hurd，GNU/Linux，Lites，NetBSD，そしてOpenBSDです) に対する，システムコンパイラでもあります．

`-fpic'や`-fPIC'フラグは，位置に依存しないコードを生成するため に使用可能です．`-fPIC'は動作するコードを生成することを保証しますが， m68k，m88k，そしてSparcチップ上ではコードは遅くなります．しかし，これら のチップで`-fpic'を使用すると，共有ライブラリでの自由なサイズが強制 的に制限されます．

このサブセクションの残りは，バンドルされているオペレーティングシステムの コンパイラをリストアップします．

aix3*
aix4*

AIXはPowerPCとRS/6000チップのみに移植されているので，AIXコンパイラはPIC フラグはありません．(13)

hpux10*

PICを生成するために`+Z'を使用してください

osf3*

Digital/UNIX 3.xは，少なくともPowerPCプラットフォームでなければ，PICフラ グはありません．

solaris2*

PICを生成するために`-KPIC'を使用してください．

sunos4*

PICを生成するために`-PIC'を使用してください．

13.3.3 リロード可能なオブジェクト

すべての既知のシステム上で，リロード可能なオブジェクトはld -r -o output.o input1.o input2.oを実行することで生成可能で す．このリロード可能なオブジェクトは，他のオブジェクトと完全な同義語とし て扱うことが可能です．

13.3.4 複数の依存性

ほとんどの近代的なプラットフォームでは，依存するライブラリがリストアップ される順序はオブジェクトの生成で影響がありません．理論上，シンボルを提供 しているライブラリの後に，リストアップされている他のライブラリに足りない シンボルを提供するライブラリを要求するプラットフォームがあります．

特に，一組のスタティックアーカイブのそれぞれが，他のシンボルのいくつかを 解決する場合，それらのアーカイブの前後両方に他のものをリストアップするこ とが必要かもしれません．複製されたライブラリはリンク行から削除されるので， libtoolは，現在この状況に十分に対処していません．

正しくリンクされたオブジェクトを生成するために，ライブラリを複数回リスト アップすることを要求するホストで開発していることが分かった場合，以下のよ うにして，libtoolの除去アルゴリズムを無効にすることが可能です．

 
$ libtool ... -lfoo -lbar -Wl,-lfoo

13.3.5 アーカイバ

すべての既知のシステム上で，スタティックライブラリのビルドは，ar cru libname.a obj1.o obj2.o …の実行で完成するは ずで，そこでは，`.a'ファイルは出力ライブラリで，それぞれの`.o' ファイルはオブジェクトファイルです．

すべての既知のシステム上で，ranlibという名のプログラムがある場合， リンクする前にranlib libname.aコマンドを用いて，作成されるラ イブラリを"祝福"するために使用する必要があります．Irixのように，代わり にar tsを使用するシステムもあります．

13.4 libtoolスクリプトの内容

バージョン1.4からは，libtoolスクリプトはconfigureによって 生成されます(see section libtoolのコンフィグレーション．以前のバージョンでは，`ltconfig' と呼ばれるへルパースクリプトを呼び出すことで，configureはそれを達 成していました．libtoolのバージョン0.7から1.0までは，このスクリプトは， 単純にシェル変数を設定し，libtoolのバックエンドのltmain.shの源と なっていました．libtoolバージョン1.1から1.3までのltconfigは， ltmain.shの内容を，生成されたlibtoolにインライン化し，それ は多くのシステムでパフォーマンスを改善しました．`ltconfig'が実行す るために使用するテストは，現在`libtool.m4'にあり，そこで我々は Autoconfを使用して書くことが可能となっています．これは，インライン化され たltmain.shの実行時の動作に有利で，そして，管理が必要な生 のシェルコードの量をかなり取り除くことで，構築時間を短くする改善を行いま した．

後で評価するもの対するシェルコマンドを保持する変数の命名に使用される規則 は，有効な単一行のシェルスクリプトが必要とされるところで接尾子 _cmd，複数行のシェルスクリプトが後で評価することが可能な ところで接尾子_cmdsを使用することです．規則では，_cmds変数 は，必要なところで，~文字で評価ユニットを区切ります．

それぞれのコンフィグレーション変数と，ltmain.shで使用する方法のリ ストは，以下のようになります(see section libtoolのコンフィグレーション)．

Variable: AR

システムライブラリアーカイバの名前です．

Variable: CC

libtoolをコンフィグレーションするために使用するCコンパイラの名前です．

Variable: LD

リロード可能にするリンクとおそらく共有ライブラリに対し，libtoolが内部で 使用するリンカの名前です．

Variable: NM

BSD互換のnmプログラムの名前で，それは以下の書式の一つで，大域的な シンボルを生成します．

 
address C global-variable-name
address D global-variable-name
address T global-function-name
Variable: RANLIB

存在する場合，ranlibプログラムの名前を設定します．

Variable: allow_undefined_flag

結果として生じる共有ライブラリに，未解決のシンボルがあることを宣言するた めに，`archive_cmds'で使用されるフラグです．そのようなフラグが不要 な場合は空です．ライブラリで定義されていないシンボルを参照して，共有ライ ブラリを生成する方法がない場合，`unsupported'を設定します．

Variable: always_export_symbols

アーカイブとリンクする前に，export_symbols_cmdsを使用してエクスポー トされるシンボルのリストを，libtoolが自動的に生成するかどうかです． `yes'または`no'に設定します．デフォルトは`no'です．

Variable: archive_cmds
Variable: archive_expsym_cmds
Variable: old_archive_cmds

それぞれ，共有ライブラリ，`-export-symbols'を用いた共有ライブラリ， そしてスタティックライブラリを生成するために使用するコマンドです．

Variable: old_archive_from_new_cmds

共有ライブラリがスタティックライブラリに依存する場合， `old_archive_from_new_cmds'はスタティックライブラリを生成するために 使用するコマンドを含みます．この変数が空の場合，`old_archive_cmds' は使用されません．

Variable: old_archive_from_expsyms_cmds

スタティックライブラリが，共有ライブラリで正しくリンクするために，エクス ポートシンボルリストから作成される必要がある場合， `old_archive_from_expsyms_cmds'は，そのスタティックライブラリを作成 するために必要なコマンドを含みます．これらのコマンドが実行されるとき，変 数sonameは，共有ライブラリの名前を疑問符の中に含み， $objdir/$newlibは，これらのコマンドがビルドする静的ライブラリのパ スを含みます．これらのコマンドを実行した後，libtoolは，sonameの代 わりに$objdir/$newlibに対してリンクするための処理を行います．

Variable: build_libtool_libs

このシステムで，libtoolが共有ライブラリをビルドできるかどうかです． `yes'または`no'に設定します．

Variable: build_old_libs

このシステムで，libtoolがスタティックライブラリをビルドできるかどうかで す．`yes'または`no'に設定します．

Variable: compiler_c_o

コンパイラが，同時に-cと-oオプションをサポートするかどうか です．`yes'または`no'に設定します．

Variable: compiler_o_lo

コンパイラが，直接".lo"ファイルへのコンパイルをサポートするかどうかで， 例えば，オブジェクトファイルが，接尾子".o"を持つ必要があるかどうかです． `yes'または`no'に設定します．

Variable: dlopen_support

プラットフォームで，dlopenをサポートするかどうかです．`yes' または`no'に設定します．

Variable: dlopen_self

実行形式自身がdlopen可能かどうかです．`yes'または`no' に設定します．

Variable: dlopen_self_static

静的にリンクされているとき(`-all-static')，実行形式自身が dlopen可能かどうかです．`yes'または`no'に設定します．

Variable: echo

バックスラッシュをエスケープ文字と解釈しないechoプログラムです．

Variable: exclude_expsyms

プリリードされているシンボルにリストアップされないシンボルのリストです．

Variable: export_dynamic_flag_spec

dlopenされる共有ライブラリが，プログラムで定義されているシンボルへの参照 を可能にするコンパイラリンクフラグです．

Variable: export_symbols_cmds

libobjsからファイルexport_symbolsへエクスポートされたシンボ ルを抽出するコマンドです．

Variable: extract_expsyms_cmds

共有ライブラリからエクスポートされたシンボルリストを抽出するコマンドです． これらのコマンドは，ファイル$objdir/$soname-defが無い場合に実行さ れ，`old_archive_from_expsyms_cmds'が使用するため，エクスポートされ たシンボル名をそのファイルに書き出します．

Variable: fast_install

libtoolが特権を与える人を，インストール者または開発者のどちらかに決定し ます．インストール者がビルドツリーでプログラムを実行することは滅多になく， 開発者は滅多にインストールしないしないと仮定します．これは， shlibpath_overrides_runpathが`yes'でないプラットフォーム上で のみ意味があるので，この場合，fast_installは`needless'設定さ れます．fast_installが`yes'に設定される場合，libtoolはインス トールされたライブラリを検索するプログラムを作成し，プログラムがビルドツ リーで実行される場合，まだインストールされていないライブラリを使用するた め，要求があれば，新しいコピーがリンクされます．`no'に設定されてい る場合，libtoolは，まだインストールされていないライブラリを使用するプロ グラムを作成し，インストール時にプログラムの新しいコピーをリンクします． デフォルト値は`yes'または`needless'で，それは，プラットフォー ムとコンフィグレーションフラグに依存し，コンフィグレーションフラグ `--disable-fast-install'を用いると，`yes'から`no'に切り替 えられます．

Variable: finish_cmds

指定されたディレクトリで共有ライブラリを見つける方法を，ダイナミックリン カに伝えるコマンドです．

Variable: finish_eval

コマンドが表示されない以外，finish_cmdsと同じです．

Variable: fix_srcfile_path

コンパイラに対するシェル変数$srcfileを修正する式です．

Variable: global_symbol_pipe

NMの出力を受け，Cの名前が続く生のシンボルのリストを生成するパイプ ラインです．例えば，以下のようになります．

 
$ eval "$NM progname | $global_symbol_pipe"
D symbol1 C-symbol1
T symbol2 C-symbol2
C symbol3 C-symbol3
…
$

最初の列は，(いくつかのプラットフォーム上でコードからデータを伝えるため に使用される)シンボル形式を含みますが，その意味はシステムに依存します．

Variable: global_symbol_to_cdecl

global_symbol_pipeの出力を厳密なC宣言に変換するパイプラインです． HP/UXのような，リンカがコードとデータを区別するプラットフォームでは，デー タシンボルはそのように宣言され，コードシンボルは関数として宣言されます． 気にしないプラットフォームではすべてがデータと仮定されます．

Variable: hardcode_action

`immediate'または`relink'のいずれかで，共有ライブラリパスがイ ンストールされる前に実行形式にハードコードされるか，または，再リンクする 必要があるかに依存します．

Variable: hardcode_direct

hardcode_libdir_flag_specが指定されたとき， (`dir/libname.a'のような)コマンド行でライブラリが直接し ていされる場合，リンカがディレクトリをハードコードするかどうかに依存し， `yes'または`no'に設定します．

Variable: hardcode_into_libs

ライブラリ内の実行パスのハードコードをプラットフォームがサポートするかど うかです．可能な場合，プログラムのリンクはより単純になりますが，ライブラ リはインストール時に再リンクが必要です．`yes'または`no'に設定 します．

Variable: hardcode_libdir_flag_spec

実行時に，共有ライブラリに対しダイナミックリンカがlibdirを検索する ために，バイナリにlibdir変数をハードコードするためのフラグです．空 の場合，libtoolは他のハードコーディングメカニズムの使用を試みます．

Variable: hardcode_libdir_separator

コンパイラが単一のhardcode_libdir_flagのみ受け入れる場合，この変数 はそのフラグに対する複数の引数を分ける文字列を含みます．

Variable: hardcode_minus_L

hardcode_libdir_flag_specが指定されたとき，結果として生じる実行形 式に`-L'フラグで指定されるディレクトリを，リンカがハードコードする かどうかに依存し，`yes'または`no'に設定します．

Variable: hardcode_shlibpath_var

hardcode_libdir_flag_specが指定されたとき，結果として生じる実行形 式に`$shlibpath_var'の内容を書き込むことで，リンカがディレクトリを ハードコードするかどうかに依存し，`yes'または`no'に設定します． `$shlibpath_var'で指定されたディレクトリが，リンク時ではなく実行時 に検索される場合，`unsupported'に設定します．

Variable: host
Variable: host_alias

情報を目的として，libtoolがコンフィグレーションされたシステムの指定され た標準名に設定します．

Variable: include_expsyms

export_symbolsの使用時に，常にエクスポートされる必要があるシンボル のリストです．

Variable: libext

標準的な，古いアーカイブの接尾子(通常は"a")です．

Variable: libname_spec

ライブラリ名の接頭辞の書式です．Unixシステムでは，スタティックライブラリ は`libname.a'と呼ばれますが，(OS/2やMS-DOSのような)システムで は，ライブラリは`name.a'のみで呼ばれることもあります．

Variable: library_names_spec

共有ライブラリ名のリストです．最初はファイル名で，残りはファイルへのシン ボリックリンクです．リスト内の名前は，`-lname'で与えられたと きリンカが見つけるファイル名です．

Variable: link_all_deplibs

libtoolが，全ての依存するプログラムに対しプログラムをリンクする必要があ るかどうかです．`yes'または`no'に設定します．デフォルトは `unknown'で，それは`yes'と同じです．

Variable: link_static_flag

ダイナミックリンクを避けるために使用する(Cコンパイラに渡す)リンカフラグ です．

Variable: need_lib_prefix

自動的にモジュール名に'lib'接尾子を付けるかどうかです．`yes'または `no'に設定します．デフォルトで，それは`unknown'になり，それは `yes'と同じ意味ですが，本当に確かめたわけではないことを告げています． `yes'はdlopenと'lib'接頭辞がないライブラリにリンク可能なこと を意味し，すなわち，それはhardcode_directを`yes'にすることを 要求します．

Variable: need_version

バージョン管理がライブラリに必要とされるかどうかで，すなわち，ダイナミッ クリンカが，すべてのライブラリに対しバージョンの接尾子を必要とするかどう かです．`yes'または`no'に設定します．デフォルトで，それは `unknown'で，それは`yes'と同じ意味を持ちますが，それを実際には 確かめていないことを告げています．

Variable: need_locks

同時にコンパイルするとき，衝突を避けるためにファイルをロックする必要があ るかどうかです．`yes'または`no'に設定します．

Variable: no_builtin_flag

charとして外部グローバルシンボルを宣言することと衝突する組み込み 関数を，利用不可能にするコンパイラフラグです．

Variable: no_undefined_flag

結果として生じる共有ライブラリに，未解決のシンボルがないことを宣言するた めの，`archive_cmds'で使用されるフラグです．

Variable: objdir

一時的なlibtoolファイルが含まれるディレクトリ名です．

Variable: objext

標準的なオブジェクトファイルの接尾子(通常は"o")です．

Variable: pic_flag

ライブラリオブジェクトファイルをビルドするための，あらゆる追加のコンパイ ルフラグです．

Variable: postinstall_cmds
Variable: old_postinstall_cmds

それぞれ，共有またはスタティックライブラリをインストールした後に実行する コマンドです．

Variable: postuninstall_cmds
Variable: old_postuninstall_cmds

それぞれ，共有またはスタティックライブラリをアンインストールした後に実行 するコマンドです．

Variable: reload_cmds
Variable: reload_flag

リロード可能なオブジェクトを作成するコマンドです．

Variable: runpath_var

結果として生じる実行形式内にハードコードするディレクトリをリンカに伝える 環境変数です．

Variable: shlibpath_overrides_runpath

環境変数でプログラムのハードコードされたライブラリ検索パスを優先可能かど うかを示します．これが`no'に設定されている場合，libtoolはビルドツリー にプログラムのコピーを２つ作成する必要がある可能性があり，一つはインストー ルされ，もう一つはビルドツリーのみで実行されます．これらのコピーのどちら かが作成されるとき，fast_installの値に依存します．デフォルト値は `unknown'で，それは`no'と同じです．

Variable: shlibpath_var

ダイナミックリンカに共有ライブラリを探す場所を伝える環境変数です．

Variable: soname_spec

共有ライブラリがファイルの本当の名前と異なる場合，その中に符号化されたコー ドされた名前です．

Variable: striplib
Variable: old_striplib

共有(striplib)やスタティック(old_striplib)のライブラリを stripするコマンドです．これらの変数が空の場合，インストールモードのstrip フラグは，ライブラリに対し無視されます(see section インストールモード)．

Variable: sys_lib_dlsearch_path_spec

実行時にライブラリの検索パスを取得する式です．このリストに現れるディレク トリが実行形式にハードコードされることは決してありません．

Variable: sys_lib_search_path_spec

コンパイル時にライブラリの検索パスを取得する式です．この変数は，特定のラ イブラリが共有かスタティックかをテストする必要があるとき，libtoolが使用 します．shlibpath_varでリストアップされるディレクトリは，このリス トに自動的に現れ，ライブラリ検索パスを拡張するためにこの変数を使用するリ ンカもあるので，毎回(すなわち，コンフィグレーション時以外)libtoolは実行 します．リンカは-Lのような検索パス引数も切り替えます．

Variable: thread_safe_flag_spec

スレッドセーフなライブラリを生成するために使用する(Cコンパイラに渡す)リ ンカフラグです．

Variable: version_type

ライブラリバージョンナンバーの形式です．`libtool'， `freebsd-aout'，`freebsd-elf'，`irix'，`linux'， `osf'，`sunos'，`windows'，または`none'の一つです．

Variable: whole_archive_flag_spec

便利なアーカイバから共有ライブラリを生成するコンパイラフラグです．

Variable: wl

libtoolが直接リンカにフラグを渡すことを可能とするCコンパイラフラグです． ${wl}some-flagとして使用されます．

`_cmds'や`_eval'で終わる変数は，`~'で分けられた，順番に evalされるコマンドのリストを含みます．ゼロ以外の終了ステータスを 返すコマンドがある場合，libtoolは一般的にエラーメッセージとともに終了し ます．

`_spec'で終わる変数は，libtoolで使用される前にevalされます．

13.5 安っぽい手段

より簡単にメンテナーシップを作成するために使用することが可能な手段は以下 のようになっています．

`libtool --version'コマンドの最終的な出力は，ltmain.inスクリ プトが直接使用されていることを示します．configureを再実行する必要 なく新しい変更をテストするため，すぐに，~/bin/libtoolや /home/src/libtool/ltmain.inを編集してください．

[ << ] [ >> ]           [Top] [Contents] [Index] [ ? ]

This document was generated by Akihiro Sagawa on June, 15 2005 using texi2html 1.70.