| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
libtoolは，現在のオペレーティングシステムで最新を保つよう変更しながら， コンスタントに開発されていています．libtoolがプラットフォーム上で思っ たように動作しない場合，問題点と解決方法を決定する助けとなる，この章を 読んだ方が良いでしょう．
| 12.1 libtoolのテストスイート | Libtool's self-tests. | |
| 12.2 バグの報告 | How to report problems with libtool. |
libtoolは，その能力をテストし，libtoolプログラムの明らかなバグを報告す る，プログラムの独自のセットとともにあります．これらのテストは， libtoolの過去の問題と他のオペレーティングシステム内の既知の欠陥を基に して，絶えず進化もしています．
`INSTALL'ファイルに記述されているように，libtoolのビルド後，基本 的な機能要求に合っていることを確めるために，make checkを実行する ことが可能です．
| 12.1.1 テストスイートの記述 | The contents of the test suite. | |
| 12.1.2 テストが失敗するとき | What to do when a test fails. |
テストスイートの現在のプログラムと，それらがテストするもののリストは以 下のようになっています．
これらのプログラムは，libtool配布物の`cdemo'サブディレクトリが， 正しくコンフィグレーションされ，ビルドされることを知るための調査を行な います．
`cdemo'サブディレクトリは，libtoolのコンビニエンスライブラリのデ モンストレーションと，ビルド時にスタティックライブラリの作成を可能とす るメカニズムを含んでいて，コンポーネントが共有ライブラリであったとして も，プログラムや他のライブラリと後でリンクされることを可能とする方法で す．
`cdemo-make.test'と`cdemo-exec.test'のテストは，三つの異なる libtoolコンフィグレーションで，三回実行されます． `cdemo-conf.test'は，スタティックライブラリと共有ライブラリの両方 をビルドするために(両方サポートしているプラットフォームではデフォルト です)`cdemo/libtool'をコンフィグレーションし， `cdemo-static.test'はスタティックライブラリのみビルドし (`--disable-shared')，そして`cdemo-shared.test' は共有ライブ ラリのみビルドします(`--disable-static')．
これらのプログラムは，libtool配布物の`demo'サブディレクトリが，コ ンフィグレーション，ビルド，インストール，そしてアンインストールが正し くできることを知るために調査します．
`demo'サブディレクトリは，libtoolを使用する平凡なパッケージのデモ ンストレーションを含んでいます．テストの`demo-make.test'， `demo-exec.test'，`demo-inst.test'，そして `demo-unst.test'は，四つの異なるlibtoolのコンフィグレーションの下 で，四回実行されます．`demo-conf.test'は，スタティックと共有の両 方のライブラリをビルドするために`demo/libtool'をコンフィグレーショ ンし，`demo-static.test'は，スタティックライブラリのみビルドし (`--disable-shared')，そして`demo-shared.test'は，共有ライブ ラリのみをビルドします(`--disable-static')． `demo-nofast.test'は，高速インストールモードを使用禁止にするため に(`--enable-fast-install=no')，`demo/libtool'をコンフィグレー ションします．`demo-pic.test'は，PICコードをビルドしたいときは (`--with-pic')，非PICコードをビルドしたいときは (`--without-pic')にするように，`demo/libtool'をコンフィグレー ションします．
スタティックライブラリを共有ライブラリにリンク不可能なシステムもたくさ
んあります．そのような場合を避けるため，libtoolは
deplibs_check_methodを使用します．このテストは，libtoolの
deplibs_check_methodが正しく動作するかどうか調査します．
共有ライブラリを持つすべてのシステムで，実行形式に対しリンクされるライ ブラリの位置が実行形式の内部に符号化されるはずですsee section 実行形式のリンク．このテストは，システムリンカがライブラリの位置をハードコー ドし，libtool自身のリンカの動作方法の概念と一致することを保証する条件 を調査します．
変数shlibpath_overrides_runpathが正しく設定されているかどうか調 査します．テストが失敗し，VERBOSEが設定されている場合，それは変 数を設定する必要がないことを示します．
libtoolが，たった今ビルドされたライブラリにリンクする方が良い時，以前 にインストールされているバージョンにリンクしようとしないかどうか調査し ます．
これらのプログラムは，libtool配布物の`depdemo'サブディレクトリの， コンフィグレーション，ビルド，インストール，そしてアンインストールを， 正しく行えることを判定するための調査を行います．
`depdemo'サブディレクトリは，libtoolに依存する内部ライブラリのデ モンストレーションを含みます．このテストプログラムは，いくつかの交互依 存しているライブラリをリンクします．
テストの，`depdemo-make.test'，`depdemo-exec.test'， `depdemo-inst.test'，そして`depdemo-unst.test'は，四つの異な るlibtoolのコンフィグレーションの下で，四回実行されます． `depdemo-conf.test'は，スタティックと共有の両方のライブラリをビル ドするために，`depdemo/libtool'をコンフィグレーションし， `depdemo-static.test'はスタティックライブラリのみビルドし (`--disable-shared')，`depdemo-shared.test'は共有ライブラリ のみビルドします(`--disable-static')．`depdemo-nofast.test' は高速インストールモード(`--enable-fast-install=no')を利用不可能 にするために，`depdemo/libtool'をコンフィグレーションします．
これらのプログラムは，libtool配布物の`mdemo'サブディレクトリが， コンフィグレーション，ビルド，インストール，そしてアンインストールが正 しくできることを知るために調査します．
`mdemo'サブディレクトリは，libtoolと，システム非依存のモジュール ロードのための，dlopenラッパー`libltdl'を使用するパッケージのデモ ンストレーションを含みます．ライブラリ`libltdl'は，様々なプラット フォーム(Linux，Solaris，HP/UX等)に対する，dlpreopenモジュールに対する サポートを含む(see section dlopen)dlopenラッパーを提供します．
テストの`mdemo-make.test'，`mdemo-exec.test'， `mdemo-inst.test'，そして`mdemo-unst.test'は，三つの異なる libtoolのコンフィグレーションの下で，三回実行されます． `mdemo-conf.test'は，スタティックと共有の両方のライブラリをビルド するために`mdemo/libtool'をコンフィグレーションし， `mdemo-static.test'は，スタティックライブラリのみビルドし (`--disable-shared')，そして`mdemo-shared.test'は，共有ライ ブラリのみをビルドします(`--disable-static')．
このテストは，libtoolの--dry-runモードが正しく動作するかどうか
を調査します．
libtoolスクリプト内の割り当てられている同じ行で，停止したり，続けたり しないかどうか調査します．
このテストは，libtoolでないスタティックライブラリに対する直接的なリン クが正しく動作することを保証します．
このテストは，`.lo'で終わるファイルがプログラムファイルに直接リン クされないことを確かめます．
実際にlibtoolの助けが可能かどうか調査します．
このプログラムはlibtoolのメタ文字を引用符で囲むことを調査します．
`test'コマンドがlibtoolで忘れられていないか調査します．
他のプログラミング言語がlibtoolで使用されるとき(see section 他の言語でlibtoolを使用する)，ソースファイルは`.c'以外の接尾子で終わるかもしれませ ん．このテストは，サポートするすべてのファイル形式に対する接尾子を扱う こと可能で，接尾子が不当なときは失敗することを確認します．
上記のそれぞれのテストは，make checkを実行するとき出力を生成しな いように設計されています．それぞれのプログラムの終了ステータスで，テス トが成功しなかったかどうかを`Makefile'に伝えます．
テストが失敗した場合，それはlibtool内のプログラムエラー，またはプログ ラム自身のエラーのどちらかが存在することを意味します．
特定のテストを調査するために，通常のプログラムで行うように，直接実行す ることが可能です．テストがこの方法で呼び出されたとき，それは，問題を決 定するのに役に立ちそうな出力を生成します．
テストプログラムに出力を生成させるもうひとつの方法は，実行前に VERBOSE環境変数を`yes'に設定することです．例えば，env VERBOSE=yes make checkですべてのテストが実行され，それぞれについてデ バッグ情報の表示が得られます．
libtoolにバグを発見したと考えた場合，もう一度考えた直したほうが良いで しょう．libtool管理者は，責任転嫁(または"バグを通過させる"かもしれま せん)で有名です(12)．libtoolは，共有ライ ブラリの実装で既知の欠陥を修正するために開発されたので，libtoolのバグ のほとんどは，ある程度は，他のオペレーティングシステムのバグになります． しかし，libtool の管理者は，他人のバギーなオペレーティングシステムに対 するサポートを加えることを，確かに楽しんでいます．[Texinfoでウインクし ている笑顔を表示する，いい方法があれば良いのですが．]
libtoolの純粋なバグは，シェルスクリプトの移植性の問題，ドキュメントの エラー，そしてテストスイートの失敗(see section libtoolのテストスイート)を含みま す．
最初に，問題と考えられる動作が，既に特徴として言及されていないことを確 かめるために，ドキュメントとへルプ画面を調査してください．
そして，バグを報告することに関するEmacsガイド(see (emacs)Bugs section `Reporting Bugs' in The Emacs Manual)を読んでください．リストアップされてい る詳細は，Emacs特有のものもありますが，基本的な原則は一般的なものです．
最後に，テストスイートの出力(see section テストが失敗するとき)，バグを再生成す るのに必要なすべての詳細，そして，動作がバグだと考えられる理由の概要の ような適切なあらゆる事実とともに，the libtool bug reporting address bug-libtool@gnu.orgにバグの報告を 送ってください．サブジェクト行に，単語"libtool"と，同様に使用してい るバージョンナンバー(それは，ltconfig --versionの入力で分かりま す)が含まれていることを確認してください．
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated by Akihiro Sagawa on June, 15 2005 using texi2html 1.70.