[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
この章は,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. |
サポートされていないシステムへのlibtoolの移植に乗り出す前に,既存の仕 事と重複していないことを確認するために,the libtool mailing list libtool@gnu.orgに電子メールを 送る価値はあります.
移植の文章が見つからない場合,文句を言ってください!パッチを用いた苦情 と,ドキュメントやlibtool自身の改良は十分に歓迎されます.
13.1.1 情報源 | Where to find relevant documentation | |
13.1.2 ライブラリ内部の依存性のサポートの移植 | Implementation details explained |
新たな移植の必要性が明らかになると,通常,以下の情報が必要となります.
他のシステムに影響しないようにlibtoolのコンフィグレーション処理を変更
可能にするため,このシステムに対するconfig.guess
の出力が必要で
す.
ld
とcc
に対するmanページ共有ライブラリを作成するため,共有ライブラリのみにリンクするため,そし て,PICを生成するために使用するフラグを,通常これらは記述しています. 必要な情報を見つけるため,以下の相互参照が必要かもしれません.
ld.so
,rtld
,または,その同等物のmanページこれらは,システムで共有ライブラリがロードされる仕組みを理解するための, 有益な情報源です.
ldconfig
やその同等物のmanページこのページは,通常,共有ライブラリをインストールする方法を記述していま す.
これは,システムの共有ライブラリの命名規則を表示し,それは,シンボリッ クリンクの名前も含んでいます.
共有ライブラリのビルドとインストール方法の特別な文章があるシステムもあ ります.
Bourneシェルプログラムの方法を知っている場合,完全に自分で移植すること が可能です.それ以外の場合,関連する作業を行う腕のある人を探す必要があ ります.libtoolメーリングリストの人々は,新たな移植への援助を志願する 意思があるので,彼らに情報を送ることができます.
独自に移植するためには,プラットフォーム特有のコンフィグレーションプロ
セスの変更を行うため,libtool.m4
マクロを明確に修正する必要があ
ります.PORTME
キーワードに対するファイルを検索する必要があり,
それで,変更に必要なヒントを得られるでしょう.一般的に,呼び出されるも
のは,適切なコンフィグレーション変数の編集です(see section libtool
スクリプトの内容).
最善策は,既にサポートされている良く似たシステムを見つけ,変更の基本と
することです.しかし,システムが他のサポートされているシステムと,大き
く異なる場合や,新しいコンフィグレーション変数を加え,それに応じて
ltmain.in
スクリプトを変更する必要がある場合もあります.欲しいも
のを達成するための,最も効果的な方法の助言がある可能性があるので,
ltmain.in
を変更する前に,メーリングリストに書いて確認してくださ
い.
バージョン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'は,以下の五つの内の一つのはずです.
ライブラリリンクパスで正しいlibnameを持つライブラリを探します.そして, ライブラリで`$file_magic_cmd'を実行し,正規表現regexに一致 することを調査します.file_magic_test_fileが`libtool.m4'に よって設定されているとき,正規表現がその出力と一致するかどうかを検証し, それ以外ではユーザが警告を受けるようにするため,それは `$file_magic_cmd'への引数として使用されます.
ライブラリリストの出力以外とプログラムがリンク可能かどうかのみを調査し,
それらがldd
の出力でリストアップされていることを調査します.それ
は現在,使用されていないので,将来は打ち切る可能性があります.
調査せず,すべて通過します.例えばDEC OSF/1 3 と 4のような,デフォルト で,コードが位置に依存せず,ライブラリ内部の依存性がダイナミックリンカ で適切にサポートされているプラットフォームで,これは動作するでしょう.
deplibsをdeplibs=""に再設定します.そうすれば,`archive_cmds'は, すべてのプラットフォームでdeplibsを含むはずですが,deplibは必要がなけ れば使用されません.
`libtool.m4'で優先されない場合,すべてのシステムでデフォルトです. それは`none'と同じですが,正しい値が何か,我々が本当に知らないこ とを文章化していて,我々はそれを改善するパッチを歓迎します.
`ltmain.in'で,我々は本当に一生懸命作業しました.それは, (libname_spec等の評価を使用するための変数を設定/リリース行う)小さな初 期化と移植,そして使用するメソッドを決定するケース文です.これは,実際 にはコードです... もう少し凝縮できれば良かったのですが,関数呼び出し を用いずにできるとは思えませんでした.私はほとんどの(ループの外に出す 等の)最適化を行いましたが,余分なものがあるかもしれません.明確な最適 化を考える前に,前進を止め,発見されたバグに対して作業すべきだと考えま した.
以下の表は,共有ライブラリのサポートを謡っているプラットフォームで, 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
を指定します.
このセクションは,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 dependent libraries. | |
13.3.5 アーカイバ | Programs that create static archives. |
以下は,価値のある文章の参照リストです.
SGIのIRIXのマニュアルページで,それは http://techpubs.sgi.com/cgi-bin/infosrch.cgi?cmd=browse&db=manで 見つかります.
Sunのフリーサービス領域 (http://www.sun.com/service/online/free.html)とドキュメントサー バ(http://docs.sun.com/).
CompaqのTru64 UNIXオンラインドキュメントは (http://tru64unix.compaq.com/faqs/publications/pub_page/doc_list.html) にあり,C++ドキュメントは (http://tru64unix.compaq.com/cplus/docs/index.htm)です.
Hewlett-Packardは(http://docs.hp.com/index.html)にオンラインドキュ メントがあります.
IBMは(http://www.rs6000.ibm.com/resource/aix_resource/Pubs/)にオ ンラインドキュメントがあります.
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'を使用してください.
すべての既知のシステム上で,リロード可能なオブジェクトはld -r -o output.o input1.o input2.oを実行することで生成可能 です.このリロード可能なオブジェクトは,他のオブジェクトと完全な同義語 として扱うことが可能です.
ほとんどの近代的なプラットフォームでは,依存するライブラリがリストアッ プされる順序はオブジェクトの生成で影響がありません.理論上,シンボルを 提供しているライブラリの後に,リストアップされている他のライブラリに足 りないシンボルを提供するライブラリを要求するプラットフォームがあります.
特に,一組のスタティックアーカイブのそれぞれが,他のシンボルのいくつか を解決する場合,それらのアーカイブの前後両方に他のものをリストアップす ることが必要かもしれません.重複したライブラリはリンク行からデフォルト で削除されるので,libtoolは,現在この状況に十分に対処していません.こ れが必要な状況では,すべての重複する依存性を避けるため、libtoolはコマ ンドラインオプション`--preserve-dup-deps'を提供しています.
すべての既知のシステム上で,スタティックライブラリのビルドは,ar cru libname.a obj1.o obj2.o …の実行で完成する はずで,そこでは,`.a'ファイルは出力ライブラリで,それぞれの `.o' ファイルはオブジェクトファイルです.
すべての既知のシステム上で,ranlib
という名のプログラムがある場
合,リンクする前にranlib libname.aコマンドを用いて,作成さ
れるライブラリを"祝福"するために使用する必要があります.Irixのように,
代わりにar ts
を使用するシステムもあります.
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のコンフィグレーション).
システムライブラリアーカイバの名前です.
ibtoolをコンフィグレーションするために使用するCコンパイラの名前です.
リロード可能にするリンクとおそらく共有ライブラリに対し,libtoolが内部 で使用するリンカの名前です.
BSD互換のnm
プログラムの名前で,それは以下の書式の一つで,大域的
なシンボルを生成します.
address C global-variable-name address D global-variable-name address T global-function-name |
存在する場合,ranlibプログラムの名前を設定します.
結果として生じる共有ライブラリに,未解決のシンボルがあることを宣言する ために,`archive_cmds'で使用されるフラグです.そのようなフラグが 不要な場合は空です.ライブラリで定義されていないシンボルを参照して,共 有ライブラリを生成する方法がない場合,`unsupported'を設定します.
アーカイブとリンクする前に,export_symbols_cmdsを使用してエクス ポートされるシンボルのリストを,libtoolが自動的に生成するかどうかです. `yes'または`no'に設定します.デフォルトは`no'です.
それぞれ,共有ライブラリ,`-export-symbols'を用いた共有ライブラリ, そしてスタティックライブラリを生成するために使用するコマンドです.
共有ライブラリがスタティックライブラリに依存する場合, `old_archive_from_new_cmds'はスタティックライブラリを生成するため に使用するコマンドを含みます.この変数が空の場合, `old_archive_cmds'は使用されません.
スタティックライブラリが,共有ライブラリで正しくリンクするために,エク スポートシンボルリストから作成される必要がある場合, `old_archive_from_expsyms_cmds'は,そのスタティックライブラリを作 成するために必要なコマンドを含みます.これらのコマンドが実行されるとき, 変数sonameは,共有ライブラリの名前を疑問符の中に含み, $objdir/$newlibは,これらのコマンドがビルドするスタティックライ ブラリのパスを含みます.これらのコマンドを実行した後,libtoolは, sonameの代わりに$objdir/$newlibに対してリンクするための処 理を行います.
このシステムで,libtoolが共有ライブラリをビルドできるかどうかです. `yes'または`no'に設定します.
このシステムで,libtoolがスタティックライブラリをビルドできるかどうか です.`yes'または`no'に設定します.
コンパイラが,同時に-c
と-o
オプションをサポートするかどう
かです.`yes'または`no'に設定します.
コンパイラが,直接".lo"ファイルへのコンパイルをサポートするかどうかで, 例えば,オブジェクトファイルが,接尾子".o"を持つ必要があるかどうかです. `yes'または`no'に設定します.
プラットフォームで,dlopen
をサポートするかどうかです.
`yes'または`no'に設定します.
実行形式自身がdlopen
可能かどうかです.`yes'または`no'
に設定します.
スタティックにリンクされているとき(`-all-static'),実行形式自身が
dlopen
可能かどうかです.`yes'または`no'に設定します.
バックスラッシュをエスケープ文字と解釈しないecho
プログラムです.
プリリードされているシンボルにリストアップされないシンボルのリストです.
dlopenされる共有ライブラリが,プログラムで定義されているシンボルへの参 照を可能にするコンパイラリンクフラグです.
libobjsからファイルexport_symbolsへエクスポートされたシン ボルを抽出するコマンドです.
共有ライブラリからエクスポートされたシンボルリストを抽出するコマンドで す.これらのコマンドは,ファイル$objdir/$soname-defが無い場合に 実行され,`old_archive_from_expsyms_cmds'が使用するため,エクスポー トされたシンボル名をそのファイルに書き出します.
libtoolが特権を与える人を,インストール者または開発者のどちらかに決定 します.インストール者がビルドツリーでプログラムを実行することは滅多に なく,開発者は滅多にインストールしないしないと仮定します.これは, shlibpath_overrides_runpathが`yes'でないプラットフォーム上 でのみ意味があるので,この場合,fast_installは`needless'設 定されます.fast_installが`yes'に設定される場合,libtoolは インストールされたライブラリを検索するプログラムを作成し,プログラムが ビルドツリーで実行される場合,まだインストールされていないライブラリを 使用するため,要求があれば,新しいコピーがリンクされます.`no'に 設定されている場合,libtoolは,まだインストールされていないライブラリ を使用するプログラムを作成し,インストール時にプログラムの新しいコピー をリンクします.デフォルト値は`yes'または`needless'で,それ は,プラットフォームとコンフィグレーションフラグに依存し,コンフィグレー ションフラグ`--disable-fast-install'を用いると,`yes'から `no'に切り替えられます.
指定されたディレクトリで共有ライブラリを見つける方法を,ダイナミックリ ンカに伝えるコマンドです.
コマンドが表示されない以外,finish_cmdsと同じです.
コンパイラに対するシェル変数$srcfileを修正する式です.
NMの出力を受け,Cの名前が続く生のシンボルのリストを生成するパイ プラインです.例えば,以下のようになります.
$ eval "$NM progname | $global_symbol_pipe" D symbol1 C-symbol1 T symbol2 C-symbol2 C symbol3 C-symbol3 … $ |
最初の列は,(いくつかのプラットフォーム上でコードからデータを伝えるた めに使用される)シンボル形式を含みますが,その意味はシステムに依存しま す.
global_symbol_pipeの出力を厳密なC宣言に変換するパイプラインです. HP/UXのような,リンカがコードとデータを区別するプラットフォームでは, データシンボルはそのように宣言され,コードシンボルは関数として宣言され ます.気にしないプラットフォームではすべてがデータと仮定されます.
`immediate'または`relink'のいずれかで,共有ライブラリパスが インストールされる前に実行形式にハードコードされるか,または,再リンク する必要があるかに依存します.
hardcode_libdir_flag_specが指定されたとき, (`dir/libname.a'のような)コマンド行でライブラリが直接 していされる場合,リンカがディレクトリをハードコードするかどうかに依存 し,`yes'または`no'に設定します.
ライブラリ内の実行パスのハードコードをプラットフォームがサポートするか どうかです.可能な場合,プログラムのリンクはより単純になりますが,ライ ブラリはインストール時に再リンクが必要です.`yes'または`no' に設定します.
実行時に,共有ライブラリに対しダイナミックリンカがlibdirを検索す るために,バイナリにlibdir変数をハードコードするためのフラグです. 空の場合,libtoolは他のハードコーディングメカニズムの使用を試みます.
コンパイラが単一のhardcode_libdir_flagのみ受け入れる場合,この変 数はそのフラグに対する複数の引数を分ける文字列を含みます.
hardcode_libdir_flag_specが指定されたとき,結果として生じる実行 形式に`-L'フラグで指定されるディレクトリを,リンカがハードコード するかどうかに依存し,`yes'または`no'に設定します.
hardcode_libdir_flag_specが指定されたとき,結果として生じる実行 形式に`$shlibpath_var'の内容を書き込むことで,リンカがディレクト リをハードコードするかどうかに依存し,`yes'または`no'に設定 します.`$shlibpath_var'で指定されたディレクトリが,リンク時では なく実行時に検索される場合,`unsupported'に設定します.
情報を目的として,libtoolがコンフィグレーションされたシステムの指定さ れた標準名に設定します.
export_symbolsの使用時に,常にエクスポートされる必要があるシンボ ルのリストです.
標準的な,古いアーカイブの接尾子(通常は"a")です.
ライブラリ名の接頭辞の書式です.Unixシステムでは,スタティックライブラ リは`libname.a'と命名されますが,(OS/2やMS-DOSのような)シス テムでは,ライブラリは`name.a'のみで命名されることもありま す.
共有ライブラリ名のリストです.最初はファイル名で,残りはファイルへのシ ンボリックリンクです.リスト内の名前は,`-lname'で与えられ たときリンカが見つけるファイル名です.
libtoolが,全ての依存するプログラムに対しプログラムをリンクする必要が あるかどうかです.`yes'または`no'に設定します.デフォルトは `unknown'で,それは`yes'と同じです.
ダイナミックリンクを避けるために使用する(Cコンパイラに渡す)リンカフラ グです.
自動的にモジュール名に'lib'接頭辞を付けるかどうかです.`yes'また
は`no'に設定します.デフォルトで,それは`unknown'になり,そ
れは`yes'と同じ意味ですが,本当に確かめたわけではないことを告げて
います.`yes'はdlopen
と'lib'接頭辞がないライブラリにリンク
可能なことを意味し,すなわち,それはhardcode_directを`yes'
にすることを要求します.
バージョン管理がライブラリに必要とされるかどうかで,すなわち,ダイナミッ クリンカが,すべてのライブラリに対しバージョンの接尾子を必要とするかど うかです.`yes'または`no'に設定します.デフォルトで,それは `unknown'で,それは`yes'と同じ意味を持ちますが,それを実際に は確かめていないことを告げています.
同時にコンパイルするとき,衝突を避けるためにファイルをロックする必要が あるかどうかです.`yes'または`no'に設定します.
char
として外部グローバルシンボルを宣言することと衝突する組み込
み関数を,利用不可能にするコンパイラフラグです.
結果として生じる共有ライブラリに,未解決のシンボルがないことを宣言する ための,`archive_cmds'で使用されるフラグです.
一時的なlibtoolファイルが含まれるディレクトリ名です.
標準的なオブジェクトファイルの接尾子(通常は"o")です.
ライブラリオブジェクトファイルをビルドするための,あらゆる追加のコンパ イルフラグです.
それぞれ,共有またはスタティックライブラリをインストールした後に実行す るコマンドです.
それぞれ,共有またはスタティックライブラリをアンインストールした後に実 行するコマンドです.
リロード可能なオブジェクトを作成するコマンドです.
結果として生じる実行形式内にハードコードするディレクトリをリンカに伝え る環境変数です.
環境変数でプログラムのハードコードされたライブラリ検索パスを優先可能か
どうかを示します.これが`no'に設定されている場合,libtoolはビルド
ツリーにプログラムのコピーを二つ作成する必要がある可能性があり,一つは
インストールされ,もう一つはビルドツリーのみで実行されます.これらのコ
ピーのどちらかが作成されるとき,fast_install
の値に依存します.
デフォルト値は`unknown'で,それは`no'と同じです.
ダイナミックリンカに共有ライブラリを探す場所を伝える環境変数です.
共有ライブラリがファイルの本当の名前と異なる場合,その中に符号化された コードされた名前です.
共有(striplib
)やスタティック(old_striplib
)のライブラリを
stripするコマンドです.これらの変数が空の場合,インストールモードの
stripフラグは,ライブラリに対し無視されます(see section インストールモード).
実行時にライブラリの検索パスを取得する式です.このリストに現れるディレ クトリが実行形式にハードコードされることは決してありません.
コンパイル時にライブラリの検索パスを取得する式です.この変数は,特定の
ライブラリが共有かスタティックかをテストする必要があるとき,libtoolが
使用します.shlibpath_varでリストアップされるディレクトリは,こ
のリストに自動的に現れ,ライブラリ検索パスを拡張するためにこの変数を使
用するリンカもあるので,毎回(すなわち,コンフィグレーション時以外)
libtoolは実行します.リンカは-L
のような検索パス引数も切り替えま
す.
スレッドセーフなライブラリを生成するために使用する(Cコンパイラに渡す) リンカフラグです.
ライブラリバージョンナンバーの形式です.`libtool', `freebsd-aout',`freebsd-elf',`irix',`linux', `osf',`sunos',`windows',または`none'の一つです.
コンビニエンスアーカイバから共有ライブラリを生成するコンパイラフラグで す.
libtoolが直接リンカにフラグを渡すことを可能とするCコンパイラフラグです.
${wl}some-flag
として使用されます.
`_cmds'や`_eval'で終わる変数は,`~'で分けられた,順番に
eval
されるコマンドのリストを含みます.ゼロ以外の終了ステータス
を返すコマンドがある場合,libtoolは一般的にエラーメッセージとともに終
了します.
`_spec'で終わる変数は,libtoolで使用される前にeval
されます.
より簡単にメンテナーシップを作成するために使用することが可能な手段は以 下のようになっています.
人々がバグを報告したとき,彼らを助けたいと思う場合は,`--config', `--debug',または`--features'フラグを使用したかどうかを尋ね てください.これらのフラグは,中古の調査を信頼しなければならない代わり に,情報を直接得る手助けとなるものです.
ltmain.in
を変更するたびごとに再コンフィグレーションする代わりに,
PATHに永久的なlibtool
スクリプトを保持し,それは直接
ltmain.in
の元となるものです.
以下のステップは,そのようなスクリプトを作成する方法を記述し,そこでは
/home/src/libtool
はlibtoolソースツリーを含むディレクトリ,
/home/src/libtool/libtool
はプラットフォームに対し以前にコンフィ
グレーションしたlibtooolスクリプト,そして~/bin
はPATHにあ
るディレクトリになっています.
trick$ cd ~/bin trick$ sed '/^# ltmain\.sh/q' /home/src/libtool/libtool > libtool trick$ echo '. /home/src/libtool/ltmain.in' >> libtool trick$ chmod +x libtool trick$ libtool --version ltmain.sh (GNU @PACKAGE@) @VERSION@@TIMESTAMP@ trick$ |
`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.