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

13. libtoolの管理用メモ

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


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

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

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


13.1.1 情報源

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

標準的なシステム名

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

ldccに対するmanページ

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

ld.sortld,または,その同等物の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'を実行し,正規表現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がテストされたことが分かっている最後の時期を記述しています.

 
-------------------------------------------------------
$BI8=`E*$J%[%9%HL>(B            $B%3%s%Q%$%i(B libtool   $B7k2L(B
  ($B%D!<%k$N%P!<%8%g%s(B)                 $B%j%j!<%9(B
-------------------------------------------------------
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.3e	  ok (1.911)
  (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-apple-darwin6.4         gcc      1.5      ok
(apple dev tools released 12/2002)
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.3e	  ok (1.913)
  (gcc-2.95.3 & native ld)
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.3e     ok (1.911)
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

$BCm0U(B:
- "ok" $B$O!$(B"$B$9$Y$F$N%F%9%H$rDL2a$7$?(B"$B$3$H$r0UL#$7$^$9!%(B
- "NS" $B$O!$(B"$B6&M-$K<:GT(B"("Not Shared")$B$r0UL#$7$^$9$,!$(B
           $B%9%?%F%#%C%/%i%$%V%i%j$O(BOK$B$G$9!%(B

注:ベンダー配布されている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 リファレンス

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


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*

(IA-64のAIX以外)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はコマ ンドラインオプション`--preserve-dup-deps'を提供しています.


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

ibtoolをコンフィグレーションするために使用する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.