[ << ] | [ >> ] | [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'は,以下の5つの内の一つのはずです.
ライブラリリンクパスで正しいlibnameを持つライブラリを探します.そして,
ライブラリで`$file_magic_cmd'を実行し,egrep
を使用した
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がテストされたことが分かっている最後の時期を記述しています.
------------------------------------------------------- 標準的なホスト名 コンパイラ 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
を指定します.
このセクションは,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. |
以下は,価値のある文章の参照リストです.
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*
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の除去アルゴリズムを無効にすることが可能です.
$ libtool ... -lfoo -lbar -Wl,-lfoo |
すべての既知のシステム上で,スタティックライブラリのビルドは,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のコンフィグレーション).
システムライブラリアーカイバの名前です.
libtoolをコンフィグレーションするために使用する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はビルドツリー
にプログラムのコピーを2つ作成する必要がある可能性があり,一つはインストー
ルされ,もう一つはビルドツリーのみで実行されます.これらのコピーのどちら
かが作成されるとき,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.