| [ << ] | [ >> ] | [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.