この章は,libtool管理者が見つける重要な情報を含みます.新しいシステム への移植や,独自のlibtoolを書くことを考慮しない場合,役に立たないでしょ う.
サポートされていないシステムへのlibtoolの移植に乗り出す前に,既存の仕 事と重複していないことを確認するために,the libtool mailing list libtool@gnu.orgに電子メールを 送る価値はあります.
移植の文章が見つからない場合,文句を言ってください!パッチを用いた苦情 と,ドキュメントやlibtool自身の改良は十分に歓迎されます.
新たな移植の必要性が明らかになると,通常,以下の情報が必要となります.
config.guess
の出力が必要で
す.
ld
とcc
に対するmanページ
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'は,以下の五つの内の一つのはずです.
ldd
の出力でリストアップされていることを調査します.それ
は現在,使用されていないので,将来は打ち切る可能性があります.
`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の改善 や,独自に書く方法の,より良いセンスが必要でしょう.
以下は,価値のある文章の参照リストです.
libtoolに影響するコンパイラの特徴は,PICオブジェクトを生成するための (存在する場合は)必要なフラグのみです.一般的に,Cコンパイラが特定のPIC フラグをサポートする場合,あらゆる派生的なコンパイラは同じフラグをサポー トします.この規則に対し,注目すべき若干の例外があるまでは,このセクショ ンではCコンパイラのみを説明します.
プラットフォームに関係なく,以下のCコンパイラは,標準のコマンドライオ プションがあります.
gcc
このサブセクションの残りは,バンドルされているオペレーティングシステム のコンパイラをリストアップします.
aix3*
aix4*
hpux10*
osf3*
solaris2*
sunos4*
すべての既知のシステム上で,リロード可能なオブジェクトは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のコンフィグレーション).
nm
プログラムの名前で,それは以下の書式の一つで,大域的
なシンボルを生成します.
address C global-variable-name address D global-variable-name address T global-function-name
-c
と-o
オプションをサポートするかどう
かです.`yes'または`no'に設定します.
dlopen
をサポートするかどうかです.
`yes'または`no'に設定します.
dlopen
可能かどうかです.`yes'または`no'
に設定します.
dlopen
可能かどうかです.`yes'または`no'に設定します.
echo
プログラムです.
$ eval "$NM progname | $global_symbol_pipe" D symbol1 C-symbol1 T symbol2 C-symbol2 C symbol3 C-symbol3 ... $
最初の列は,(いくつかのプラットフォーム上でコードからデータを伝えるた めに使用される)シンボル形式を含みますが,その意味はシステムに依存しま す.
dlopen
と'lib'接頭辞がないライブラリにリンク
可能なことを意味し,すなわち,それはhardcode_directを`yes'
にすることを要求します.
char
として外部グローバルシンボルを宣言することと衝突する組み込
み関数を,利用不可能にするコンパイラフラグです.
fast_install
の値に依存します.
デフォルト値は`unknown'で,それは`no'と同じです.
striplib
)やスタティック(old_striplib
)のライブラリを
stripするコマンドです.これらの変数が空の場合,インストールモードの
stripフラグは,ライブラリに対し無視されます(see section インストールモード).
-L
のような検索パス引数も切り替えま
す.
${wl}some-flag
として使用されます.
`_cmds'や`_eval'で終わる変数は,`~'で分けられた,順番に
eval
されるコマンドのリストを含みます.ゼロ以外の終了ステータス
を返すコマンドがある場合,libtoolは一般的にエラーメッセージとともに終
了します.
`_spec'で終わる変数は,libtoolで使用される前にeval
されます.
より簡単にメンテナーシップを作成するために使用することが可能な手段は以 下のようになっています.
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
を編集してください.
Go to the first, previous, next, last section, table of contents.