\input texinfo   @c -*-texinfo-*-
@c %**start of header
@setfilename libtool-ja.info
@settitle Libtool
@c For double-sided printing, uncomment:
@c @setchapternewpage odd
@c %**end of header

@c @documentlanguage ja

@include libtool-v.texi
@set BUGADDR the libtool bug reporting address @email{bug-libtool@@gnu.org}
@set MAILLIST the libtool mailing list @email{libtool@@gnu.org}
@set objdir .libs

@dircategory GNU programming tools
@direntry
* Libtool(ja): (libtool-ja).           Generic shared library support script.
@end direntry

@dircategory Individual utilities
@direntry
* libtoolize(ja): (libtool-ja)Invoking libtoolize.     Adding libtool support.
@end direntry

@ifinfo
This file documents GNU Libtool @value{VERSION}

このファイルは，GNU Libtool @value{VERSION}を説明します．

Copyright (C) 1996-2000 Free Software Foundation, Inc.

Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1
or any later version published by the Free Software Foundation;
with the no Invariant Sections, with no Front-Cover Texts,
and with no Back-Cover Texts.  A copy of the license is included in
the section entitled "GNU Free Documentation License".

@ignore
Permission is granted to process this file through TeX and print the
results, provided the printed document carries copying permission notice
identical to this one except for the removal of this paragraph

@end ignore
@end ifinfo

@titlepage
@title GNU Libtool
@subtitle For version @value{VERSION}, @value{UPDATED}
@author Gordon Matzigkeit
@author Alexandre Oliva
@author Thomas Tanner
@author Gary V. Vaughan
@c 翻訳：西尾 太

@page
@vskip 0pt plus 1filll
Copyright @copyright{} 1996-2000 Free Software Foundation, Inc.

Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1
or any later version published by the Free Software Foundation;
with the no Invariant Sections, with no Front-Cover Texts,
and with no Back-Cover Texts.  A copy of the license is included in
the section entitled "GNU Free Documentation License".

@end titlepage

@c Put everything in one index (arbitrarily chosen to be the concept index).
@syncodeindex vr cp
@syncodeindex fn cp
@syncodeindex tp cp
@synindex pg cp

@ifnottex
@node Top, Introduction, (dir), (dir)
@comment  node-name,  next,  previous,  up
@top Shared library support for GNU

このファイルはGNU Libtoolの説明で，それは，パッケージ開発者が一般的な共
有ライブラリを提供することを可能にするスクリプトです．このエディションは
バージョン@value{VERSION}を説明します．

libtoolを用いたときの問題の報告方法の情報は，@xref{Reporting bugs}.

@menu
* Introduction::                What the heck is libtool?
* Libtool paradigm::            How libtool's view of libraries is different.
* Using libtool::               Example of using libtool to build libraries.
* Invoking libtool::            Running the @code{libtool} script.
* Integrating libtool::         Using libtool in your own packages.
* Versioning::                  Using library interface versions.
* Library tips::                Tips for library interface design.
* Inter-library dependencies::  Libraries that depend on other libraries.
* Dlopened modules::            @code{dlopen}ing libtool-created libraries.
* Using libltdl::               Libtool's portable @code{dlopen} wrapper library.
* Other languages::             Using libtool without a C compiler.
* Troubleshooting::             When libtool doesn't work as advertised.
* Maintaining::                 Information used by the libtool maintainer.
* GNU Free Documentation License:: License for this manual.
* Index::                       Full index.

@detailmenu
 ---詳細なノードリスト---

はじめに

* Motivation::                  Why does GNU need a libtool?
* Issues::                      The problems that need to be addressed.
* Other implementations::       How other people have solved these issues.
* Postmortem::                  Learning from past difficulties.

libtoolを使用する

* Creating object files::       Compiling object files for libraries.
* Linking libraries::           Creating libraries from object files.
* Linking executables::         Linking object files against libtool libraries.
* Debugging executables::       Running GDB on libtool-generated programs.
* Installing libraries::        Making libraries available to users.
* Installing executables::      Making programs available to users.
* Static libraries::            When shared libraries are not wanted.

@code{libtool}の呼び出し

* Compile mode::                Creating library object files.
* Link mode::                   Generating executables and libraries.
* Execute mode::                Debugging libtool-generated programs.
* Install mode::                Making libraries and executables public.
* Finish mode::                 Completing a library installation.
* Uninstall mode::              Removing installed executables and libraries.
* Clean mode::                  Removing uninstalled executables and libraries.

パッケージとlibtoolの統合

* Makefile rules::              Writing @file{Makefile} rules for libtool.
* Using Automake::              Automatically supporting libtool.
* Configuring::                 Configuring libtool for a host system.
* Distributing::                What files to distribute with your package.
* Static-only libraries::       Sometimes shared libraries are just a pain.

libtoolのコンフィグレーション

* AC_PROG_LIBTOOL::             Configuring @code{libtool} in @file{configure.in}.

パッケージにlibtoolを含める

* Invoking libtoolize::         @code{libtoolize} command line options.
* Autoconf .o macros::          Autoconf macros that set object file names.

ライブラリインターフェースのバージョン

* Interfaces::                  What are library interfaces?
* Libtool versioning::          Libtool's versioning system.
* Updating version info::       Changing version information before releases.
* Release numbers::             Breaking binary compatibility for aesthetics.

インターフェースデザインへの助言

* C header files::              How to write portable include files.

dlopenモジュール

* Building modules::            Creating dlopenable objects and libraries.
* Dlpreopening::                Dlopening that works on static platforms.
* Finding the dlname::          Choosing the right file to @code{dlopen}.
* Dlopen issues::               Unresolved problems that need your attention.

libltdlを使用する

* Libltdl interface::           How to use libltdl in your programs.
* Modules for libltdl::         Creating modules that can be @code{dlopen}ed.
* Thread Saftey in libltdl::	Registering callbacks for multi-thread safety.
* User defined module data::    Associating data with loaded modules.
* Module loaders for libltdl::  Creating user defined module loaders.
* Distributing libltdl::        How to distribute libltdl with your package.

他の言語でlibtoolを使用する

* C++ libraries::

トラブルシューティング

* Libtool test suite::          Libtool's self-tests.
* Reporting bugs::              How to report problems with libtool.

libtoolのテストスイート

* Test descriptions::           The contents of the test suite.
* When tests fail::             What to do when a test fails.

libtoolのための管理メモ

* New ports::                   How to port libtool to new systems.
* Tested platforms::            When libtool was last tested.
* Platform quirks::             Information about different library systems.
* libtool script contents::     Configuration information that libtool uses.
* Cheap tricks::                Making libtool maintainership easier.

新しいシステムへlibtoolを移植する

* Information sources::         Where to find relevant documentation
* Porting inter-library dependencies::  Implementation details explained

プラットフォームの癖

* References::                  Finding more information.
* Compilers::                   Creating object files from source files.
* Reloadable objects::          Binding object files together.
* Multiple dependencies::	Removing duplicate dependant libraries.
* Archivers::                   Programs that create static archives.

@end detailmenu
@end menu

@end ifnottex

@node Introduction
@chapter はじめに

これまで，ソースコードパッケージの開発者が共有ライブラリの能力を利用した
い場合，パッケージを実行するそれぞれのプラットフォームに対し，カスタムサ
ポートコードを書く必要がありました．パッケージインストーラがビルドされる
ライブラリの種類を選択できるように，コンフィグレーションインターフェース
を設計する必要もありました．

GNU Libtoolは，一つのスクリプトでプラットフォーム特有の依存性とユーザイ
ンターフェースの両方をカプセル化することで，開発者の仕事を単純にします．
GNU Libtoolは，それぞれのホストの形式の完全な機能を，一般的なインタフェー
スを通して利用できるが，やっかいな癖はプログラマから隠されるように設計さ
れています．

GNU Libtoolの一貫したインターフェースは再保証されます@dots{} ユーザは好
みのソースコードパッケージを共有ライブラリにビルドするため，不明瞭なドキュ
メントを読む必要がありません．パッケージの@code{configure}スクリプト(ま
たはその同等品)を実行するだけで，libtoolがいやな仕事をすべて行ってくれま
す．

このドキュメント全体にいくつかの例があります．すべて同じ環境を仮定してい
ます．我々は，ライブラリ@file{libhello}を一般的な方法でビルドしたいと思っ
ています．

@file{libhello}は，共有ライブラリ，スタティックライブラリ，または，その
両方になります@dots{} libtoolで移植できるホストシステムで利用可能なすべ
てのものです．

この章では，libtoolの最初の設計思想を説明します．歴史に興味がなかったり，
堅実な方法で拡張されているlibtoolのコードを書きたい場合，自由に飛ばして
次の章へ行ってください．

@menu
* Motivation::                  Why does GNU need a libtool?
* Issues::                      The problems that need to be addressed.
* Other implementations::       How other people have solved these issues.
* Postmortem::                  Learning from past difficulties.
@end menu

@node Motivation
@section libtoolを書いた動機

@cindex motivation for writing libtool
@cindex design philosophy
1995年初頭から，数人のGNU開発者はそれぞれ，パッケージに対する共有ライブ
ラリのサポートの重要性を認識していました．そのように変更する主な動機は，
GNUプログラムでのコードのモジュール化と再利用を(概念的，物理的の両方で) 
促進するためです．

そのような要求は，パッケージのインストーラが要求するあらゆるライブラリの
形式が可能になるように，GNUパッケージにライブラリを組み込む方法を一般的
なものにする必要があることを意味します．問題は，異なるプラットフォームで
共有ライブラリを作成する標準手続きが無いことです．

以下のセクションで，GNUでの共有ライブラリのサポートが直面している重大な
問題と，共有ライブラリのサポートをlibtoolで標準化した方法を概説します．

@cindex specifications for libtool
@cindex libtool specifications
以下の仕様書が，このシステムの開発と評価で使用されました．

@enumerate
@item
システムはできる限り簡潔である必要があります．

@item
システムは，GNU管理者がより簡単に使用できるように，GNU Autoconfと
Automakeユーティリティと完全に統合する必要があります．しかし，GNUパッケー
ジ以外でも使用できるように，これらのツールを要求してはなりません．

@item
他の(GNUでない)アーキテクチャとツールへの移植が望まれます．
@end enumerate


@node Issues
@section 問題の実装

@cindex tricky design issues
@cindex design issues
以下の問題は，再利用可能なあらゆる共有ライブラリシステム，特にlibtoolで
扱う必要があります．

@enumerate
@item
パッケージのインストーラで，ビルドされるライブラリの種類を制御可能にすべ
きです．

@item
インストールされていないライブラリと動的にリンクされるプログラムの実行を
巧妙に行うことを可能にします．@code{LD_LIBRARY_PATH}が(サポートしている
場合は)正しく設定されている必要があり，そうでなければプログラムの実行に
失敗するでしょう．

@item
システムは，共有ライブラリをサポートしていないホストでさえ，堅実に処理す
る必要があります．

@item
共有ライブラリをビルドするときに必要なコマンドは，ホスト毎に大きく異なる
可能性があります．これらは，コンフィグレーション時に一定の方法で決定する
必要があります．

@item
インストールされる共有ライブラリの接尾子が常に明確なわけではありません．
通常，ファイル名はホスト毎に同じだということを仮定されるので，
@file{Makefile}規則が難しくなります．

@item
共有ライブラリをその場でアップグレード可能なように，システムは，単純なラ
イブラリバージョンナンバーの抽象化が必要です．バイナリ互換を最大にするた
め，ライブラリへのインターフェースの設計方法を，プログラマに伝えるべきで
す．

@item
インストールする@file{Makefile}ターゲットは，パッケージインストーラに
特定の環境変数(@code{LD_LIBRARY_PATH}または同等のもの)を設定したり，
@code{ldconfig}を実行するよう，警告する必要があります．
@end enumerate

@node Other implementations
@section その他の実装

libtoolが開発されるまで，多くのフリーソフトウエアパッケージは，独自の共
有ライブラリをビルドしインストールしていました．既存の機能の再発明を避け
るために，これらのパッケージを最初に調査しました．

さて，これらのパッケージに，libtoolが必要としている共有ライブラリシステ
ムの詳細な文章が無いのは明らかです．そのため，それ以外のパッケージは影響
するので多少断念されました．


@node Postmortem
@section その他の実装の近代的な解析

@cindex other implementations, flaws in
@cindex reusability of library systems
調査されたそれぞれの実装は，多くの異なるホストシステムに対して，予定して
いた仕事をすべて公平に行いました．しかし，再利用できるコンポーネントとし
て一般的に機能するものは，これらの解決法にはないようでした．

@cindex complexity of library systems
ほとんどのものは，実装で行なわれていることを正確に理解すること無く使用す
る(まして，変更する)には複雑すぎ，それらは通常，文章化されていませんでし
た．

異なるベンダーはライブラリについて異なる見解を持つこと，そして，当然
@emph{動作する}という単一のパラダイムを自信を持って定めているものが調査
したパッケージには無かったことが主な難点です．

理想としては，拡張シリーズとして，そして既存のシステムが絶えず動作するよ
うは変更物として実装されている標準物に，libtoolがなることです．しかし，
オペレーティングシステム開発者に悪い方法を修正させることは簡単な仕事では
なく，バグが多く，壊れていて，混乱したオペレーティングシステム上でさえ，
今すぐに共有ライブラリをビルドしたいと，人々は思っていました．

このため，libtoolは独立したシェルスクリプトとして設計されました．それは，
異なるプラットフォーム上のコンパイラスイートを，堅実で強力なインターフェー
スを用いて包み隠すことで，@file{Makefile}の書き手を悩ませるライブラリ構
築での問題と矛盾から隔離しています．

運が良ければ，libtoolは役に立ち，GNUコミュニティで使用され，そして，それ
を書くとき学んだ教訓は，将来のライブラリシステムの設計に採用されるでしょ
う．


@node Libtool paradigm
@chapter libtoolのパラダイム

最初は，ライブラリのオブジェクト形式の不特定多数をサポートするように
libtoolは設計されました．その後，libtoolはより多くのプラットフォームに移
植され，ライブラリとプログラムの間の関係を記述するため，新しいパラダイム
が徐々に開発されました．

@cindex definition of libraries
@cindex libraries, definition of
要約すると，``ライブラリは複数のエントリポイントと，より正式に定義された
インターフェースがあるプログラムである．''ということです．

libtoolのバージョン0.7は，この新しいパラダイムを反映するため，完全に再設
計され書き換えられました．今のところ成功しているようです．libtoolは，以
前よりより単純になり，より役に立ちます．

libtoolパラダイムを導入する最善の方法は，それぞれの例を用いて，既存のラ
イブラリシステムのパラダイムと比較することです．それは新しい考え方なので
吸収するまで少し時間がかかるかもしれませんが，理解したとき世界がより単純
化されるでしょう．


@node Using libtool
@chapter libtoolを使用する

@cindex examples of using libtool
@cindex libtool examples
libtoolが人生をより単純にする方法が分かるまで，独自のパッケージでlibtool 
を使用することを話す意味はありません．この章の例は，標準的なライブラリの
ビルド処理と，libtoolの処理を，2つの異なるプラットフォームで比較すること
で，主な特徴を紹介します．

@table @samp
@item a23
スタティックライブラリのみのUltrix 4.2プラットフォーム．

@item burger
共有ライブラリを持つ，NetBSD/i386 1.2プラットフォーム．
@end table

独自のプラットフォームの例をこれに続けることが可能で，それは，libtoolで
インストールされた，前もってコンフィグレーションされたlibtoolスクリプト
を使用します(@pxref{Configuring})．

以下の例のソースファイルは，libtool配布物の@file{demo}サブディレクトリか
ら持ってきています．ファイル@file{foo.c}と@file{hello.c}からライブラリ
@file{libhello}をビルドしていると仮定してください．

@file{foo.c}ソースファイルが@code{cos}数学ライブラリ関数を使用していて，
それは通常，Cライブラリではなく単独の数学ライブラリで見つかることに注意
してください(@pxref{Trig Functions, , Trigonometric Functions, libc, The
GNU C Library Reference Manual})．そのため，@file{foo.o}や@file{foo.lo} 
を実行形式やライブラリにリンクするときは，常にリンク行の最後に@kbd{-lm} 
を加える必要があります(@pxref{Inter-library dependencies})．

同じ規則は，標準Cライブラリに無い関数を使用するとき，常に当てはまります
@dots{} これらのオブジェクトに対しリンクするときは，適切な
@kbd{-l@var{name}}フラグをリンク行の終りに加える必要があります．

ライブラリをビルドした後，@file{libhello}に対して@file{main.o}をリンクす
ることでプログラムを作成したいと思います．

@menu
* Creating object files::       Compiling object files for libraries.
* Linking libraries::           Creating libraries from object files.
* Linking executables::         Linking object files against libtool libraries.
* Debugging executables::       Running GDB on libtool-generated programs.
* Installing libraries::        Making libraries available to users.
* Installing executables::      Making programs available to users.
* Static libraries::            When shared libraries are not wanted.
@end menu

@node Creating object files
@section オブジェクトファイルの作成

@cindex compiling object files
@cindex object files, compiling
ソースファイルからオブジェクトファイルを作成するため，コンパイラは`-c'フ
ラグ(とその他の必要なあらゆるフラグ)とともに呼び出されます．

@example
burger$ @kbd{gcc -g -O -c main.c}
burger$
@end example

上記のコンパイラコマンドは，ソースファイル@file{main.c}からオブジェクト
ファイル@file{main.o}を生成します．

ほとんどのライブラリシステムでは，スタティックライブラリの一部となるオブ
ジェクトファイルを作成することは，実行可能な形式にリンクされるオブジェク
トファイルを作成することと同じくらい単純です．

@example
burger$ @kbd{gcc -g -O -c foo.c}
burger$ @kbd{gcc -g -O -c hello.c}
burger$
@end example

@cindex position-independent code
@cindex PIC (position-independent code)
しかし，共有ライブラリは@dfn{position-independent code} (PIC)のみからビ
ルドされます．そのため，標準のposition-dependent codeではなくPICを生成す
るようコンパイラに伝えるため，特定のフラグを渡す必要があります．

@cindex library object file
@cindex @samp{.lo} files
@cindex object files, library
これがライブラリ実装の詳細なので，libtoolは個別の(@samp{.o}の代わりに
@samp{.lo}で終わる)ライブラリオブジェクトファイルを用いて，複雑なPICコン
パイラフラグを隠蔽します．共有ライブラリが無い(または，特定のPICフラグが
無い)システムでは，これらのライブラリオブジェクトファイルは``標準の''オ
ブジェクトファイルと同じです．

@file{foo.c}と@file{hello.c}に対するライブラリオブジェクトファイルを作成
するため，単純に標準のコンパイルコマンドを引数として，libtoolを呼び出し
てください(@pxref{Compile mode})．

@example
a23$ @kbd{libtool gcc -g -O -c foo.c}
gcc -g -O -c foo.c
echo timestamp > foo.lo
a23$ @kbd{libtool gcc -g -O -c hello.c}
gcc -g -O -c hello.c
echo timestamp > hello.lo
a23$
@end example

それぞれの呼び出しで，libtoolが２つのファイルを作成することに注意してく
ださい．@samp{.lo}ファイルはライブラリオブジェクトで，それは共有ライブラ
リにビルドされ，@samp{.o}ファイルは標準的なオブジェクトファイルです．
@samp{a23}では，スタティックライブラリのみサポートされているので，ライブ
ラリオブジェクトはタイムスタンプのみです．

共有ライブラリのあるシステムでは，ライブラリオブジェクトと標準オブジェク
トが異なるように，libtoolはPIC生成フラグをコンパイルコマンドに自動的に挿
入します．

@example
burger$ @kbd{libtool gcc -g -O -c foo.c}
gcc -g -O -c -fPIC -DPIC foo.c
mv -f foo.o foo.lo
gcc -g -O -c foo.c >/dev/null 2>&1
burger$ @kbd{libtool gcc -g -O -c hello.c}
gcc -g -O -c -fPIC -DPIC hello.c
mv -f hello.o hello.lo
gcc -g -O -c hello.c >/dev/null 2>&1
burger$
@end example

２番目に実行されるGCCがその出力を破棄していることに注意してください．こ
れは，コンパイラの警告がうるさく重複しないために行われます．


@node Linking libraries
@section ライブラリのリンク

@pindex ar
libtoolを用いない場合，スタティックライブラリを作成するため，プログラマ
は@code{ar}コマンドを呼び出していました．

@example
burger$ @kbd{ar cru libhello.a hello.o foo.o}
burger$
@end example

@pindex ranlib
しかしもちろん，それだけではあまりに単純すぎて，多くのシステムでは(それ
以上のカルマや何かを与えるため)結果として生成されたライブラリ上で，
@code{ranlib}コマンドを実行する必要があります．

@example
burger$ @kbd{ranlib libhello.a}
burger$
@end example

libtoolの``ライブラリはプログラム''というアプローチで与えられるこの作業
に対して，Cコンパイラを使用することは，より自然に感じられます．そのため，
共有ライブラリが無いプラットフォームでは，libtoolは単純にシステムの
@code{ar}(そして可能なら@code{ranlib})コマンドのラッパーとして動作します．

@cindex libtool libraries
@cindex @samp{.la} files
また，libtoolのライブラリ名は，標準の名前(@samp{.a}接尾子の代わりに
@samp{.la} 接尾子を持ちます)と異なります．libtoolの引数は，コンパイラで
@file{libhello.la}という名の実行形式を生成するために使用したのと同じもの
です(@pxref{Link mode})．

@example
a23$ @kbd{libtool gcc -g -O -o libhello.la foo.o hello.o}
libtool: cannot build libtool library `libhello.la' from non-libtool \
                objects
a23$
@end example

あぁ！libtoolは通常のエラーを得てしまった@dots{} ライブラリオブジェクト
の代わりに，標準のオブジェクトからライブラリをビルドしています．これはス
タティックライブラリでは問題ありませんが，共有ライブラリシステムでは非常
に重要です．

そのため，今回はライブラリオブジェクトファイルを用いて，もう一度試してみ
ましょう．@file{foo.c}が@code{cos}数学ライブラリを使用しているので，コマ
ンドラインに@kbd{-lm}を加える必要があることも忘れないでください
(@pxref{Using libtool})．

共有ライブラリをビルドするその他の複雑なことは，(最終的に)インストールさ
れるディレクトリパス(この場合は，@file{/usr/local/lib})
@footnote{@code{rpath}を指定しない場合，libtoolは便利なアーカイブをビル
ドしますが，それは共有ライブラリではありません(@pxref{Static libraries})．} 
を指定する必要があることです．

@example
a23$ @kbd{libtool gcc -g -O -o libhello.la foo.lo hello.lo \
                -rpath /usr/local/lib -lm}
mkdir @value{objdir}
ar cru @value{objdir}/libhello.a foo.o hello.o
ranlib @value{objdir}/libhello.a
creating libhello.la
a23$
@end example

さて，共有ライブラリのプラットフォーム上で同じトリックを試してみましょう．

@example
burger$ @kbd{libtool gcc -g -O -o libhello.la foo.lo hello.lo \
                -rpath /usr/local/lib -lm}
mkdir @value{objdir}
ld -Bshareable -o @value{objdir}/libhello.so.0.0 foo.lo hello.lo -lm
ar cru @value{objdir}/libhello.a foo.o hello.o
ranlib @value{objdir}/libhello.a
creating libhello.la
burger$
@end example

さてそれはかなり賢いです@dots{} libtoolは共有ライブラリを作成するため，
スタティックライブラリと同様に，曖昧な@code{ld}コマンドを実行しただけで
す．

@cindex @file{@value{objdir}} subdirectory
libtoolが，現在のディレクトリではなく，@file{@value{objdir}}サブディレク
トリに余分なファイルを作成することに注意してください．この機能は，ビルド
ディレクトリをきれいにするのをより簡単にするためと，たまたまlibtoolの使
用を忘れていて他のプログラムを実行するとき，確実に手ひどく失敗するので役
に立ちます．


@node Linking executables
@section 実行形式のリンク

@cindex linking against installed libraries
ライブラリを実行形式とリンクする前に，@dfn{インストール}する(永久に位置
する場所にそれを配置する)場所を選択した場合，リンクするためにlibtoolを使
用する必要はありません．ライブラリの位置を指定するため，単純に適切な
@samp{-L}と@samp{-l}フラグを使用してください．

@cindex buggy system linkers
システムのリンカによっては，結果として生じる実行形式に，共有ライブラリの
完全なディレクトリ名の符号化を強要するものもあります．libtoolは，永久に
配置されるディレクトリ名のみをインストールされた実行形式に書き込むことを
確実にするため，特別な魔法でこの設計ミスに関して動作する必要があります．

@cindex security problems with buggy linkers
@cindex bugs, subtle ones caused by buggy linkers
このバグの重要性は見落としてはなりません．それによるプログラムの暴走は明
白ではありません．それはセキュリティホールを作成し，さらに悪いことには，
パッケージのインストール後にライブラリソースコードを編集した場合，インス
トールされたプログラムの動作を変更してしまうでしょう！

そのため，インストールする前にライブラリとプログラムをリンクさせたい場合，
リンクするためにlibtoolを使用する必要があります．

@cindex linking against uninstalled libraries
インストールされていないライブラリとリンクする古い方法は，以下のようにな
ります．


@example
burger$ @kbd{gcc -g -O -o hell.old main.o libhello.a -lm}
burger$
@end example

libtoolの方法は，ほとんど同じです@footnote{しかし，インストールされてい
ないlibtoolライブラリにリンクするために，@samp{-L}や@samp{-l}フラグの使
用は避けたほうがいいでしょう．@samp{.la}ファイルに対する，
@file{../intl/libintl.la}のような相対パスのみを指定してください．これは，
インストールされていない共有ライブラリに対しリンクするとき，あらゆる曖昧
さを取り除くため決定された設計です．}(@pxref{Link mode})．

@example
a23$ @kbd{libtool gcc -g -O -o hell main.o libhello.la -lm}
gcc -g -O -o hell main.o ./@value{objdir}/libhello.a -lm
a23$
@end example

真実としてはあまりに単純に見えます．libtoolが行うことは，
@file{libhello.la}を@file{./@value{objdir}/libhello.a}に変換することがす
べてですが，@samp{a23}は共有ライブラリがないことを忘れないでください．

@samp{burger}では，状況が異なります．

@example
burger$ @kbd{libtool gcc -g -O -o hell main.o libhello.la -lm}
gcc -g -O -o @value{objdir}/hell main.o -L./@value{objdir} -R/usr/local/lib -lhello -lm
creating hell
burger$
@end example

@cindex linking with installed libtool libraries

さて，@file{libhello.la}が既にインストールされていると仮定し，新しいプロ
グラムをそれとリンクしたいとします．自分でそれがある場所を探し，以下を実
行します．

@example
burger$ @kbd{gcc -g -O -o test test.o -L/usr/local/lib -lhello}
@end example

しかし，@file{/usr/local/lib}が標準のライブラリ検索パスに無い場合，
@code{test}を実行することはできません．しかし，既にインストールされてい
るlibtoolライブラリとリンクするためlibtoolを使用する場合，それは The
Right Thing (TM)となります．

@example
burger$ @kbd{libtool gcc -g -O -o test test.o /usr/local/lib/libhello.la}
gcc -g -O -o @value{objdir}/test test.o -Wl,--rpath
-Wl,/usr/local/lib /usr/local/lib/libhello.a -lm
creating test
burger$
@end example

libtoolが，ライブラリlibhello.laが依存している@samp{-lm}同様，必要なラン
タイムパスフラグを追加していることに注意してください．いいですね，ふっふ？

libtoolがラッパースクリプトを作成したので，インストールとデバッグにも
libtoolを使用したほうがいいでしょう．しかし，プログラムはインストールさ
れていないlibtoolライブラリには全く依存しないので，ラッパースクリプトを
用いない場合でもおそらく有用でしょう．この場合は，ラッパースクリプトの作
成を避けるため，おそらくより賢くlibtoolを作成できたでしょうが，これは読
者の演習として残しておきます．


@cindex wrapper scripts for programs
@cindex program wrapper scripts
実行形式@code{hell}は，実際には@file{@value{objdir}}サブディレクトリに作
成されることに注意してください．そして，ラッパースクリプトは現在のディレ
クトリに作成されます．

NetBSD 1.2では，libtoolは@samp{-R/usr/local/lib}コンパイラフラグを使用し
て，@file{libhello}のディレクトリのインストールを符号化します．そして，
ラッパースクリプトは，正しくインストールされるまで実行形式が正しい
(@file{./@value{objdir}}にある)共有ライブラリを見つけることを保証します．

2つの異なるプログラムを比較してみましょう．

@example
burger$ @kbd{time ./hell.old}
Welcome to GNU Hell!
** This is not GNU Hello.  There is no built-in mail reader. **
        0.21 real         0.02 user         0.08 sys
burger$ @kbd{time ./hell}
Welcome to GNU Hell!
** This is not GNU Hello.  There is no built-in mail reader. **
        0.63 real         0.09 user         0.59 sys
burger$
@end example

ラッパースクリプトは実行にかなり時間がかかりますが，共有ライブラリがイン
ストールされていなくても，少なくとも結果は正しくなります．

そのため，共有ライブラリがもたらした，全体的なスペース削減ははどうなって
いるのでしょう？

@example
burger$ @kbd{ls -l hell.old libhello.a}
-rwxr-xr-x  1 gord  gord  15481 Nov 14 12:11 hell.old
-rw-r--r--  1 gord  gord   4274 Nov 13 18:02 libhello.a
burger$ @kbd{ls -l @value{objdir}/hell @value{objdir}/libhello.*}
-rwxr-xr-x  1 gord  gord  11647 Nov 14 12:10 @value{objdir}/hell
-rw-r--r--  1 gord  gord   4274 Nov 13 18:44 @value{objdir}/libhello.a
-rwxr-xr-x  1 gord  gord  12205 Nov 13 18:44 @value{objdir}/libhello.so.0.0
burger$
@end example

うーん，だめだなあ@footnote{訳注：原文は，Well, that sucks.}．おそらく，
私はこのプロジェクトを破壊し，作成中のゆりかごを取り上げたほうがいいでしょ
う．

実際，それは重要なことを証明しています．共有ライブラリには，それが(関連
する)複雑さのため，オーバーへッドをがあります．この状況では，ダイナミッ
クの価値は8キロバイトで，報酬は約4キロバイトです．そのため，少なくとも2，
3個以上のプログラムとリンクするまで，共有される@file{libhello}を維持する
ことは利点になりません．


@node Debugging executables
@section 実行形式のデバッグ

@file{hell}が複雑なプログラムの場合，システムにインストールする前にそれ
のテストとデバッグを間違いなく行いたいでしょう．上記のセクションで，
libtoolラッパースクリプトが，プログラムを直接実行することを可能にする方
法を見ましたが，残念ながら，このメカニズムはデバッガの邪魔になります．

@example
burger$ @kbd{gdb hell}
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i386-unknown-netbsd), (C) 1996 Free Software Foundation, Inc.

"hell": not in executable format: File format not recognized

(gdb) @kbd{quit}
burger$
@end example

残念です．GDBは実行形式がある場所が分からないので動作しません．そのため，
もう一度実行形式でGDBを呼び出してみてください．

@example
burger$ @kbd{gdb @value{objdir}/hell}
trick:/home/src/libtool/demo$ gdb .libs/hell
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i386-unknown-netbsd), (C) 1996 Free Software Foundation, Inc.
(gdb) @kbd{break main}
Breakpoint 1 at 0x8048547: file main.c, line 29.
(gdb) @kbd{run}
Starting program: /home/src/libtool/demo/.libs/hell
/home/src/libtool/demo/.libs/hell: can't load library 'libhello.so.2'

Program exited with code 020.
(gdb) @kbd{quit}
burger$
@end example

あぁ．さて，GDBは，@file{hell}がリンクしている共有ライブラリを見つけるこ
とができないため文句を言いました．そのため，正しいライブラリパスを設定し
てデバッガを実行するために，libtoolを使う必要があります．幸い，
@file{@value{objdir}}ディレクトリを完全に忘れて，そのままの実行形式のラッ
パーで実行可能です(@pxref{Execute mode})．

@example
burger$ @kbd{libtool gdb hell}
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i386-unknown-netbsd), (C) 1996 Free Software Foundation, Inc.
(gdb) @kbd{break main}
Breakpoint 1 at 0x8048547: file main.c, line 29.
(gdb) @kbd{run}
Starting program: /home/src/libtool/demo/.libs/hell

Breakpoint 1, main (argc=1, argv=0xbffffc40) at main.c:29
29	  printf ("Welcome to GNU Hell!\n");
(gdb) @kbd{quit}
The program is running.  Quit anyway (and kill it)? (y or n) @kbd{y}
burger$
@end example


@node Installing libraries
@section ライブラリのインストール

@pindex strip
libtoolが無いシステムでライブラリをインストールすることは，全く簡単です
@dots{} それらをその場所にコピーするだけです．@footnote{偶発的にライブラ
リをstripしないでください，そうすると使用不可能になります．}

@pindex su
@example
burger$ @kbd{su}
Password: @kbd{********}
burger# @kbd{cp libhello.a /usr/local/lib/libhello.a}
burger#
@end example

おっと，@code{ranlib}コマンドを忘れないでください．

@example
burger# @kbd{ranlib /usr/local/lib/libhello.a}
burger#
@end example

@pindex install
libtoolのインストールは，同様に全く単純です．通常使用する，
@code{install}や@code{cp}コマンドをそのまま使用してください
(@pxref{Install mode})．

@example
a23# @kbd{libtool cp libhello.la /usr/local/lib/libhello.la}
cp libhello.la /usr/local/lib/libhello.la
cp @value{objdir}/libhello.a /usr/local/lib/libhello.a
ranlib /usr/local/lib/libhello.a
a23#
@end example

アンインストールでlibtoolを助け(@pxref{Uninstall mode})，リンクし
(@pxref{Linking executables})，dlopenでプログラムを助ける
(@pxref{Dlopened modules})ため，libtoolのライブラリ@file{libhello.la}も
インストールされることに注意してください．

Here is the shared library example:

共有ライブラリの例は，以下のようになります．

@example
burger# @kbd{libtool install -c libhello.la /usr/local/lib/libhello.la}
install -c @value{objdir}/libhello.so.0.0 /usr/local/lib/libhello.so.0.0
install -c libhello.la /usr/local/lib/libhello.la
install -c @value{objdir}/libhello.a /usr/local/lib/libhello.a
ranlib /usr/local/lib/libhello.a
burger#
@end example

@cindex stripping libraries
@cindex libraries, stripping
ライブラリインストール時にBSD互換のinstallプログラムを使用する場合，
@samp{-s}(シンボルのstrip)フラグを指定すると安全です．libtoolは@samp{-s} 
フラグを無視する，またはライブラリからデバッグとコンパイラシンボルのみを
stripするプログラムを実行します．

ライブラリを一度配置すると，使用する前に必要な追加のコンフィグレーション
を行います．最初に，ビルド時に使用した@samp{-rpath}フラグと同じ場所に，
ライブラリが実際にインストールされていることを確かめる必要があります．

@cindex postinstallation
@cindex installation, finishing
@cindex libraries, finishing installation
そして，@samp{libtool -n --finish @var{libdir}}を実行すると，行うことの
ヒントが与えられるはずです(@pxref{Finish mode})．

@example
burger# @kbd{libtool -n --finish /usr/local/lib}
PATH="$PATH:/sbin" ldconfig -m /usr/local/lib
-----------------------------------------------------------------
Libraries have been installed in:
   /usr/local/lib

To link against installed libraries in a given directory, LIBDIR,
you must use the `-LLIBDIR' flag during linking.

 You will also need to do one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-RLIBDIR' linker flag

See any operating system documentation about shared libraries for
more information, such as the ld and ld.so manual pages.
-----------------------------------------------------------------
burger#
@end example

これらのステップを完了した後，インストールされたライブラリの使用開始が可
能になります．作成されたライブラリに依存する実行形式もインストールできま
す．


@node Installing executables
@section 実行形式のインストール

インストールされていないlibtoolライブラリに対して，実行形式をリンクする
ためにlibtoolを使用した場合(@pxref{Linking executables})，ライブラリをイ
ンストールした後に実行形式をインストールするため，libtoolを使用する必要
があります．

それでは，Ultrixの例を対象に，以下のように実行します．

@example
a23# libtool install -c hell /usr/local/bin/hell
install -c hell /usr/local/bin/hell
a23#
@end example

共有ライブラリシステムでは，libtoolはラッパースクリプトを無視し，正しい
バイナリをインストールします．

@example
burger# libtool install -c hell /usr/local/bin/hell
install -c @value{objdir}/hell /usr/local/bin/hell
burger#
@end example


@node Static libraries
@section スタティックライブラリとのリンク

@cindex static linking
@cindex convenience libraries
libtoolの旨味を知って，@code{ar}と@code{ranlib}の愚かさへなぜ戻るのでしょ
う？さて，決して共有されるはずがないスタティックアーカイブをつくることが
望ましいときもあります．最もよくある状況として，複数の異なるプログラムを
ビルドするために使用する，オブジェクトファイルの集まりを持っているときが
あります．個々のプログラムに対し，すべてのオブジェクトファイルをリストアッ
プする代わりに，それらのオブジェクトから``便利なライブラリ''を作成し，ラ
イブラリとプログラムをリンクすることが可能です．この技術は，他のディレク
トリのライブラリへのリンクをサポートするので，他のディレクトリのソースか
らビルドされるオブジェクトファイルをリンクするサポートが欠けている，GNU
automakeを補うためによく使用されます．この制限は，リリース1.4までのGNU
automakeに当てはまります．より新しいリリースは，他のディレクトリのソース
をサポートするでしょう．

この便利なライブラリとプログラムをリンクしたいだけの場合，完全にlibtool
を無視し，古い@code{ar}と@code{ranlib}コマンド(や，対応するGNU automake
@samp{_LIBRARIES}規則)が使用可能です．(おそらく使用したくはないでしょう
が)libtoolを使用して，便利なライブラリをインストールすることさえ可能です．

@example
burger$ @kbd{libtool ./install-sh -c libhello.a /local/lib/libhello.a}
./install-sh -c libhello.a /local/lib/libhello.a
ranlib /local/lib/libhello.a
burger$
@end example

スタティックライブラリのインストールにlibtoolを使用すると，ライブラリが
(@samp{-s}フラグを使用したインストーラの場合のように)偶然stripされること
から守り，自動的に実行される正しい@code{ranlib}コマンドと同様になります．

しかし，libtoolライブラリは単にオブジェクトファイルの集合以上です．それ
らは古いアーカイブにはない，ライブラリの依存情報をも運ぶことが可能です．
libtoolの静的な便利なライブラリを作成したい場合，スタティックライブラリ
のみに興味があることを示すため，@samp{-rpath}フラグを省略し
@samp{-static}を使用することができます．そのようなスタティックライブラリ
とリンクするとき，libtoolは実際にすべてのオブジェクトファイルと依存する
ライブラリをプログラムにリンクします．

@samp{-rpath}と@samp{-static}の両方を省略した場合，libtoolは，他の
libtoolライブラリで，共有ライブラリの作成にすら使用可能なlibtoolの便利な
ライブラリを作成します．静的な場合のように，ライブラリは一組のオブジェク
トファイルと依存するライブラリの別名として動作しますが，この場合，オブジェ
クトファイルは共有ライブラリに含まれるほうが適しています．しかし，直接ま
たは間接的に，単一のプログラムやライブラリに単一の便利なライブラリをリン
クしないように注意して下さい．さもなければ，シンボル再定義に関するエラー
を得るでしょう．

GNU automakeを使用するとき，@samp{-rpath}オプションがリンク時に渡されな
いように，便利なライブラリに対する@code{lib_LTLIBRARIES}の代わりに
@code{noinst_LTLIBRARIES}を使用した方が良いでしょう．

経験的に，最大一つのlibtoolライブラリにlibtoolの便利なライブラリをリンク
し，プログラムにはリンクしないようにしてください，そして，libtoolの便利
なスタティックライブラリを一つのプログラムにのみリンクし，それは，ライブ
ラリ依存情報を便利なスタティックライブラリのユーザに運ぶことが必要な場合
のみにしてください．

@cindex standalone binaries
静的なリンクが適している，その他の一般的な状況は，独立したバイナリを作成
するときです．リンクにlibtoolを使用し，@samp{-all-static}フラグを加えて
ください．


@node Invoking libtool
@chapter @code{libtool}の呼び出し
@pindex libtool
@cindex libtool command options
@cindex options, libtool command
@cindex command options, libtool

@code{libtool}プログラムは以下の構文を持ちます．

@example
libtool [@var{option}]@dots{} [@var{mode-arg}]@dots{}
@end example

@noindent
そして，以下のオプションを受け入れます．

@table @samp
@item --config
libtoolのコンフィグレーション変数を表示し終了します．

@item --debug
シェルスクリプトの実行の追跡を標準出力にダンプします．これは多くの出力を
生成するので，@code{less}(や@code{more})にパイプしたり，ファイルにリダイ
レクトしたいかもしれません．

@item -n
@itemx --dry-run
あらゆるファイルを作成，編集，削除せず，libtoolで実行されるコマンドのみ
を表示します．

@item --features
基本的なコンフィグレーションオプションを表示します．これは，パッケージが
ビルドするライブラリを，スタティックまたは共有のいずれにするか決定する方
法を提供します．

@item --finish
@samp{--mode=finish}と同じです．

@item --help
へルプメッセージを表示し終了します．@samp{--mode=@var{mode}}が指定された
場合，@var{mode}の詳細へルプを表示します．

@item --mode=@var{mode}
処理モードとして@var{mode}を使用します．デフォルトで，処理モードは
@var{mode-args}から推測されます．

@var{mode}が指定された場合，それは以下の一つにする必要があります．

@table @samp
@item compile
ソースファイルをlibtoolオブジェクトにコンパイルします．

@item execute
インストールされていない，libtoolが生成したプログラムやライブラリを他の
プログラムが使用できるように，自動的にライブラリパスを設定します．

@item finish
libtoolライブラリのシステムへのインストールを完全に行います．

@item install
ライブラリや実行形式をインストールします．

@item link
ライブラリや実行形式を作成します．

@item uninstall
インストールされたライブラリや実行形式を削除します．

@item clean
アンインストールされたライブラリや実行形式を削除します．
@end table

@item --version
ibtoolのバージョン情報を出力し終了します．
@end table

@var{mode-args}は引数の変数の数で，それは処理モードの選択に依存します．
一般的に，それぞれの@var{mode-arg}は，libtool自身ではなく，libtoolが呼び
出すプログラムで解釈されます．

@menu
* Compile mode::                Creating library object files.
* Link mode::                   Generating executables and libraries.
* Execute mode::                Debugging libtool-generated programs.
* Install mode::                Making libraries and executables public.
* Finish mode::                 Completing a library installation.
* Uninstall mode::              Removing installed executables and libraries.
* Clean mode::                  Removing uninstalled executables and libraries.
@end menu

@node Compile mode
@section コンパイルモード
@cindex mode, compile
@cindex compile mode

@dfn{コンパイル}モードに対し，@var{mode-args}は，`標準的な'オブジェクト
ファイルを作成するとき使用するコンパイルコマンドです．これらの引数は，C 
コンパイラの名前で始まり，オブジェクトファイルのみを作成するための
@samp{-c}コンパイラフラグを含みます．

libtoolは，ソースファイル名からディレクトリ要素を削除して出力ファイル名
を決定し，ソースコードの接尾子(例えば，Cソースコードに対する@samp{.c})を
ライブラリオブジェクト接尾子@samp{.lo}に置換します．

共有ライブラリをビルドする場合は，必要なPIC生成フラグがコンパイルコマン
ドに置換されます．@samp{-Wc,@var{flag}}と@samp{-Xcompiler @var{flag}}を
使用したり，@samp{-Wl,@var{flag}}と@samp{-Xlinker @var{flag}}を使用した
りして，それぞれ，コンパイラとリンカに指定したフラグを渡すことが可能です．

@samp{-static}オプションが与えられている場合は，libtoolが
@samp{--disable-static}でコンフィグレーションされていた場合でも，
@samp{.o}ファイルがビルされてます．

現在は@samp{-o}オプションが，完全にサポートされていることに注意してくだ
さい．それがサポートされていないプラットフォームでは，(オブジェクトのロッ
クと移動によって)エミュレートされるので，Makefileを少し編集するだけで
libtoolは本当に簡単に使用できます．入力例は以下のようになります．
@example
libtool gcc -c foo/x.c -o foo/x.lo
@end example
これは期待したことを行います．

しかし，コンパイラが@samp{-c}と@samp{-o}をサポートしていない場合，既存の
@file{./x.o}を上書きせずに@file{foo/x.c}をコンパイルすることが不可能なこ
とに注意してください．そのため，ソースファイル@file{./x.c}がある場合，
@file{./x.o}(や@file{./x.lo})が，サブディレクトリのあらゆる@file{x.lo}の
後で再作成されることを確実にするため，@file{Makefile}に依存性の導入を必
ず行ってください．
@example
x.o x.lo: foo/x.lo bar/x.lo
@end example
これは，プログラムやライブラリを作成するため，一時的に壊れた@file{x.o}の
使用を試みないことを確実にします．それは，@samp{-c}と@samp{-o}を同時にサ
ポートするプラットフォームで，不必要な再コンパイルを引き起こすかもしれま
せんが，それは，そうでないものに対して安全にする唯一の方法です．


@node Link mode
@section リンクモード
@cindex link mode
@cindex mode, link

@dfn{リンク}モードは，(ライブラリオブジェクトを含む)オブジェクトファイル
と，その他のライブラリや作成された実行可能なプログラムをリンクします．

@var{mode-args}は，いくつかのオブジェクトファイルから(@samp{-o}フラグを
用いた)出力ファイルを作成するためにCコンパイラが使用するコマンドから成り
立ちます．

以下の@var{mode-args}の組は特別に扱われます．

@table @samp
@cindex undefined symbols, allowing
@cindex unresolved symbols, allowing
@item -all-static
@var{output-file}がプログラムの場合，共有ライブラリと全くリンクしません．
@var{output-file}がライブラリの場合，スタティックライブラリのみ作成しま
す．

@item -avoid-version
ライブラリとモジュールに対しバージョン管理(@pxref{Versioning})を避けよう
とし，すなわち，バージョン情報は保存されず，シンボリックリンクも作成され
ません．プラットフォームがバージョニングを要求する場合，このオプションは
効果がありません．

@item -dlopen @var{file}
ネイティブなdlopenがホストプラットフォームでサポートされていない場合
(@pxref{Dlopened modules})や，プログラムが@samp{-static}や
@samp{-all-static}でリンクされている場合，@samp{-dlpreopen @var{file}}と
同じです．それ以外では効果はありません．@var{file}が@code{self}の場合，
@code{-export-dynamic}を可能にする，または，@samp{-dlpreopen self}に後退
することにより，libtoolはプログラムがそれ自身を@code{dlopen}可能であるこ
とを確かめます．

@item -dlpreopen @var{file}
@var{file}を出力プログラムにリンクし，そのシンボルを
@var{lt_preloaded_symbols}に含めます(@pxref{Dlpreopening})．@var{file}が
@code{self}の場合，プログラムのシンボル自身が@var{lt_preloaded_symbols} 
に加えられます．@var{file}が@code{force}の場合，libtoolは，
@var{lt_preloaded_symbols}が空であろうがなかろうが，常に@emph{定義済}で
あることを確実にします．

@item -export-dynamic
@var{output-file}からのシンボルが@code{dlsym}で解決されることを可能にし
ます(@pxref{Dlopened modules})．

@item -export-symbols @var{symfile}
リンカに@var{symfile}でリストアップされているシンボルのみエクスポートす
るよう伝えます．シンボルファイルは@samp{.sym}で終わるべきで，一行毎に一
シンボル名を含める必要があります．このオプションに効果がないプラットフォー
ムがあります．デフォルトですべてのシンボルがエクスポートされます．

@item -export-symbols-regex @var{regex}
正規表現@var{regex}に一致するシンボルのみエクスポートされる以外，
@samp{-export-symbols}と同じです．デフォルトですべてのシンボルがエクスポー
トされます．

@item -L@var{libdir}
既にインストールされている，要求されているライブラリに対し，@var{libdir}
を検索します．

@item -l@var{name}
@var{output-file}はインストールされているライブラリ@file{lib@var{name}} 
を要求します．このオプションは@var{output-file}が実行形式でないときも要
求されます．

@item -module
dlopen可能なライブラリを作成します(@pxref{Dlopened modules})．このオプショ
ンはプログラムでは動作しません．モジュール名の'lib'の前置は不要です．し
かし，名前の破壊を避けるため，'libname'と'name' パッケージで同時に使用し
てはなりません．

@item -no-fast-install
実行形式@var{output-file}の高速インストールモードを利用不可にします．プ
ログラムをインストールする必要がないとき役に立ちます．

@item -no-install
インストール不可能で，そのためラップスクリプトが不要な実行形式
@var{output-file}をリンクします．プログラムがビルドツリーでのみ使用され
る場合，例えば，テストしたり他のファイルを生成するプログラムに対して役に
立ちます．

@item -no-undefined
@var{output-file}が他のライブラリに依存しないことを宣言します．他のライ
ブラリに依存する共有ライブラリを作成不可能なプラットフォームもあります
(@pxref{Inter-library dependencies})．

@item -o @var{output-file}
指定されたオブジェクトとライブラリから@var{output-file}を作成します．

@item -release @var{release}
ユーザが他より新しいバージョンを簡単に伝えられるよう，パッケージのリリー
ス@var{release}で生成されたライブラリを指定します．このフラグを使用する
場合，パッケージの２つのリリースがバイナリ互換でないことを警告されます．
バイナリ互換が欲しい場合，代わりに@samp{-version-info}フラグを使用してく
ださい(@pxref{Versioning})．

@item -rpath @var{libdir}
@var{output-file}がlibtoolライブラリの場合，それをビルドするために，バー
ジョン情報@var{current}，@var{revision}，そして@var{age}を使用します
(@pxref{Versioning})．このフラグをパッケージのリリース情報の指定に使用せ
ず，そのためには@samp{-release}を参照してください．

@item -R @var{libdir}
@var{output-file}がプログラムの場合，プログラムの実行時のパスを
@var{libdir}に加えます．@var{output-file}がライブラリの場合，ライブラリ
がプログラムとリンクされるときは，常に@var{libdir}が実行時のパスに加えら
れるように，その@var{dependency_libs}に-R@var{libdir}を加えます．

@item -static
@var{output-file}がプログラムの場合，インストールされていない共有ライブ
ラリとリンクしません．@var{output-file}がライブラリの場合，スタティック
ライブラリのみ作成します．

@item -version-info @var{current}[:@var{revision}[:@var{age}]]
@var{output-file}がlibtoolライブラリの場合，それをビルドするために，バー
ジョン情報@var{current}，@var{revision}，そして@var{age}を使用します
(@pxref{Versioning})．このフラグをパッケージのリリース情報の指定に使用せ
ず，そのためには@samp{-release}を参照してください．

@item -Wl,@var{flag}
@itemx -Xlinker @var{flag}
リンカ指定のフラグを直接リンカに渡します．
@end table

@var{output-file}が@samp{.la}で終わる場合，libtoolライブラリが作成され，
それはライブラリオブジェクト(@samp{.lo}ファイル)のみから作成される必要が
あります．@samp{-rpath}オプションは要求されません．現在の実装では，
libtoolライブラリが他のインストールされていないlibtoolライブラリに依存す
ることはできません(@pxref{Inter-library dependencies})．

@var{output-file}が@samp{.a}で終わる場合，標準的なライブラリは@code{ar} 
と，おそらく@code{ranlib}を使用して作成されます．

@cindex partial linking
@cindex linking, partial
@var{output-file}が@samp{.o}や@samp{.lo}で終わる場合，リロード可能なオブ
ジェクトファイルは，(通常@samp{ld -r}を用いて)入力ファイルから作成されま
す．この手法は@dfn{部分的なリンク}と呼ばれることが多いです．

それ以外の場合，実行可能なプログラムが作成されます．


@node Execute mode
@section 実行モード
@cindex execute mode
@cindex mode, execute

@samp{実行}モードに対し，ライブラリパスは自動的に設定され，プログラムは
実行されます．

@var{mode-args}の最初は，プログラム名として扱われ，残りはプログラムの引
数となります．

以下の@var{mode-args}の組は特別に扱われます．

@table @samp
@item -dlopen @var{file}
ライブラリパスに@var{file}を含むディレクトリを加えます．
@end table

このモードは，あらゆる@samp{-dlopen}フラグによって，ライブラリパス環境変
数を設定します．

すべての@var{args}がlibtoolの実行形式のラッパーの場合，それらは対応する
インストールされていないバイナリの名前に変換され，それらが要求するすべて
のライブラリディレクトリがライブラリパスに加えられます．


@node Install mode
@section インストールモード
@cindex install mode
@cindex mode, install

@dfn{インストール}モードでは，libtoolは@var{mode-args}を，@code{cp}で始
まるインストールコマンドやBSD互換の@code{install}プログラムとして解釈し
ます．

@var{mode-args}の残りは，そのコマンドの引数として解釈されます．

コマンドが実行され，特権の不要な必要なインストール後のコマンドも完全に実
行されます．


@node Finish mode
@section フィニッシュモード
@cindex finish mode
@cindex mode, finish

@dfn{フィニッシュ}モードは，ユーザプログラムにlibtoolライブラリを配置し
リンクできるよう，システム管理者のインストールを助けます．

それぞれの@var{mode-arg}はライブラリのディレクトリの名前として解釈されま
す．このコマンドの実行は，@samp{--dry-run}オプションが役に立つように，スー
パーユーザの特権を要求するかもしれません．


@node Uninstall mode
@section アンインストールモード
@cindex uninstall mode
@cindex mode, uninstall

@dfn{アンインストール}モードはインストールされているライブラリ，実行形式，
そしてオブジェクトを削除します．

@var{mode-arg}の最初はファイルの削除に使用するプログラム名(通常は
@file{/bin/rm})です．

残りの@var{mode-args}は，(`-'で始まる)削除プログラムに対するフラグ，また
は削除するファイル名です．


@node Clean mode
@section クリーンモード
@cindex clean mode
@cindex mode, clean

@dfn{クリーン}モードはアンインストールされたライブラリ，実行形式，オブジェ
クト，そして，それらに関連があるlibtoolの一時ファイルを削除します．

最初の@var{mode-arg}は，ファイルを削除するために使用するプログラムの名前
(通常は@file{/bin/rm})です．

残りの@var{mode-args}は削除プログラムに対する(`-'で始まる)フラグ，または
削除するファイル名です．


@node Integrating libtool
@chapter パッケージとlibtoolの統合

この章は，ユーザが混乱せずに共有ライブラリをインストールできるように，パッ
ケージとlibtoolの統合方法を記述します．

@menu
* Makefile rules::              Writing @file{Makefile} rules for libtool.
* Using Automake::              Automatically supporting libtool.
* Configuring::                 Configuring libtool for a host system.
* Distributing::                What files to distribute with your package.
* Static-only libraries::       Sometimes shared libraries are just a pain.
@end menu

@node Makefile rules
@section libtoolに対する@file{Makefile}規則を書く
@cindex Makefile
@cindex Makefile.am
@cindex Makefile.in

libtoolは，完全にAutomake(@pxref{Top,, Introduction, automake, The
Automake Manual})と統合されていて，それはAutomake version 1.2から開始さ
れています．

通常の@file{Makefile}(や@file{Makefile.in})で，libtoolを使用したい場合は，
独自のものとなります．Automake 1.2を使用せず，パッケージにlibtoolの組み
込み方を知らない場合，以下の一つが必要になります．

@enumerate 1
@item
Automake(バージョン1.2以降)を近くのGNUのミラーからダウンロードし，インス
トールし，その使用を開始してください．

@item
@file{Makefile}規則の手での書き方を学んでください．複雑なときもあります
が，古いライブラリをコンパイルするための規則を書けるぐらいの知識がある場
合，libtoolライブラリに対する新しい規則の理解は可能でしょう(ヒント：
libtool 配布物の@file{demo}サブディレクトリの@file{Makefile.in}を調べて
ください@dots{} 特に，それがAutomakeによって@file{Makefile.am}から自動的
に生成されたことに注意してください)．
@end enumerate


@node Using Automake
@section libtoolと共にAutomakeを使用する

@vindex LTLIBRARIES
libtoolライブラリのサポートは，@samp{LTLIBRARIES}プライマリの下で実装さ
れています．

libtool配布物の@file{demo}サブディレクトリの，Automake
@file{Makefile.am}からの例は，以下のようになっています．

最初に，プログラムをlibtoolライブラリとリンクするため，
@samp{program_LDADD}変数のみを使用してください．

@example
bin_PROGRAMS = hell hell.debug

# Build hell from main.c and libhello.la
hell_SOURCES = main.c
hell_LDADD = libhello.la

# Create an easier-to-debug version of hell.
hell_debug_SOURCES = main.c
hell_debug_LDADD = libhello.la
hell_debug_LDFLAGS = -static
@end example

フラグ@samp{-dlopen}と@samp{-dlpreopen}(@pxref{Link mode})は，
@var{program_LDADD}変数で，より適切になります．残念ながら，リリース1.4ま
でのGNU automakeは，@var{program_LDADD}変数でこれらのフラグを受け入れな
いため，以下で代用します．

@itemize @bullet
@item
それらを@var{program_LDFLAGS}に加え，@var{program_DEPENDENCIES}にライブ
ラリをリストアップし，それらが属するこれらのフラグを受け入れるGNU
automakeのリリースを待ってください．

@item
フラグの回りを引用符で囲みます，しかし，@var{program_DEPENDENCIES}も設定
する必要があります．

@example
program_LDADD = "-dlopen" libfoo.la
program_DEPENDENCIES = libfoo.la
@end example

@item
@file{configure.in}の@samp{AC_SUBST}で，変数@var{DLOPEN}と
@var{DLPREOPEN}を設定し，@samp{program_LDADD}での明確なフラグ
@samp{-dlopen}と@samp{-dlpreopen}に対する置換物として，@samp{@@DLOPEN@@} 
と@samp{@@DLPREOPEN@@}を使用します．Automakeは，依存性から
@samp{AC_SUBST}された変数を捨てるので，@samp{program_LDADD}のこれらのフ
ラグを受け入れたとき，それは正確に期待したように動作します．
@end itemize

(インストールされていない共有libtoolライブラリとのリンクを避けるため
@samp{-static}を使用するような)@samp{program}をリンクしている間，libtool
に渡したいあらゆるフラグを詰め込むため，@samp{program_LDFLAGS}変数を使用
することも可能です．

libtoolライブラリをビルドすることは，ほとんど冒険です@dots{}
@samp{-version-info}(@pxref{Versioning})オプションをlibtoolに渡すため，
@samp{libhello_la_LDFLAGS}を使用することに注意してください．

@example
# Build a libtool library, libhello.la for installation in libdir.
lib_LTLIBRARIES = libhello.la
libhello_la_SOURCES = hello.c foo.c
libhello_la_LDFLAGS = -version-info 3:12:1
@end example

@samp{-rpath}オプションは，(@code{noinst_LTLIBRARIES}としてリストアップ
されるライブラリ以外)Automakeにより自動的に渡されるので，指定する必要は
ありません．

詳細は，@xref{A Shared Library, Building a Shared Library, The Automake
Manual, automake, The Automake Manual}.


@node Configuring
@section libtoolのコンフィグレーション
@cindex configuring libtool

libtoolは，共有ライブラリを作成し適切なものにリンクするため，コンパイラセット
とオペレーティングシステムの詳細な知識を必要とします．libtool配布物をイ
ンストールするとき，システム特有のlibtoolスクリプトはバイナリディレクト
リにインストールされます．

しかし，独自のパッケージとともにlibtoolを配布するとき
(@pxref{Distributing})，パッケージをコンパイルするために使用されるコンパ
イラセットとオペレーティングシステムを，常に知っているわけではありません．

このため，libtoolを使用する前に@dfn{コンフィグレーション}する必要があり
ます．この考えは，GNU @code{configure}スクリプトを使用するものに似ていま
す．@code{configure}は，システムの特徴に対しいくつものテストを行い，
@file{Makefiles}(と，おそらく@file{config.h}ヘッダファイル)を生成し，そ
の後，@code{make}を実行しパケージをビルドすることが可能です．

libtoolは，インストーラのホストマシンに対するlibtoolスクリプトを生成する
ために，独自のテストを@code{configure}スクリプトに加えます．

@menu
* AC_PROG_LIBTOOL::             Configuring @code{libtool} in @file{configure.in}.
@end menu

@node AC_PROG_LIBTOOL
@subsection @code{AC_PROG_LIBTOOL}マクロ

GNU Autoconf(やAutomake)を使用している場合，@code{AC_PROG_LIBTOOL}の呼び
出しを@file{configure.in}に加える必要があります．このマクロは，
生成されたlibtoolスクリプトがホストの特徴を理解できるようにするため，
多くの新しいテストを@code{configure}スクリプトに加えます．

@defmac AC_PROG_LIBTOOL
@defmacx AM_PROG_LIBTOOL
@samp{--enable-shared}と@samp{--disable-shared}の@code{configure}フラグ
に対するサポートを加えます．@footnote{@code{AC_PROG_LIBTOOL}は，
@file{Makefile.in}での@file{Makefile}変数の@code{top_builddir}の定義を要
求します．Automakeはこれを自動的に行いますが，Autoconfユーザは，ビルドディ
レクトリのトップへの相対パス(例えば，@file{../..})を設定する必要がありま
す．} @code{AM_PROG_LIBTOOL}は，このマクロに対する古い名前で，しばらくは
サポートされますが，やめた方がいいでしょう．

デフォルトで，このマクロは，利用可能な場合は共有ライブラリを開始し，共有
ライブラリと衝突しない場合はスタティックライブラリも可能とします．これら
のデフォルトは，@code{AC_DISABLE_SHARED}や@code{AC_DISABLE_STATIC}マクロ
のどちらかで修正可能です．

@example
# Turn off shared libraries during beta-testing, since they
# make the build process take too long.
AC_DISABLE_SHARED
AC_PROG_LIBTOOL
@end example

ユーザは，パッケージ名を元にビルドされる，共有またはスタティックライブラ
リを選択するため，@samp{--enable-shared}と@samp{--enable-static}コンフィ
グレーションフラグで指定を修正できます．例えば，共有する@samp{bfd}と
@samp{gdb}ライブラリをビルドし，@samp{libg++}を共有にしないため，以下の
@code{configure}スクリプトの実行で，３つのことのすべて可能となります．

@example
trick$ ./configure --enable-shared=bfd,gdb
@end example

一般的に，@samp{--enable-shared=@var{pkgs}}の指定は，カンマで分けられた
@var{pkgs}リストに名前があるすべてのパッケージを@samp{--enable-shared}で，
それ以外のすべてのパッケージを@samp{--disable-shared}でコンフィグレーショ
ンすること同じです．@samp{--enable-static=@var{pkgs}}フラグは，同様に動
作しますが，その場合は@samp{--enable-static}と@samp{--disable-static}を
使用します．同様に，@samp{--enable-fast-install=@var{pkgs}}フラグは適用
され，それは，@samp{--enable-fast-install}と
@samp{--disable-fast-install}を使用します．

パッケージ名@samp{default}は，@code{PACKAGE}環境変数に名前が設定されてい
ない，あらゆるパッケージに一致します．

このマクロは，シェル変数@var{LIBTOOL_DEPS}も設定し，それで，libtoolスク
リプトが時代遅れになった場合の自動的な更新に使用できるようになります．そ
うするために@file{configure.in}に以下を加えてください．

@example
AC_PROG_LIBTOOL
AC_SUBST(LIBTOOL_DEPS)
@end example

そして，@file{Makefile.in}や@file{Makefile.am}に，以下を加えてください．

@example
LIBTOOL_DEPS = @@LIBTOOL_DEPS@@
libtool: $(LIBTOOL_DEPS)
        $(SHELL) ./config.status --recheck
@end example

GNU automakeを使用してる場合，automakeが面倒をみるので，指示の省略が可能
です．@file{libtool}での依存性を明確に作成する必要があります．

@end defmac

@defmac AC_LIBTOOL_DLOPEN
dlopenサポートの調査を可能にします．パッケージで@samp{-dlopen}と
@samp{-dlpreopen}フラグを使用する場合，このマクロ使用すべきで，そうしな
い場合，libtoolはシステムがdlopenをサポートしていないと仮定します．マク
ロは@code{AC_PROG_LIBTOOL}の@strong{前で}呼び出す必要があります．
@end defmac

@defmac AC_LIBTOOL_WIN32_DLL
このマクロは，win32プラットフォームでクリーンなdllをビルドするために移植
する場合，使用する必要があります．通常，これは，あらゆるライブラリデータ
項目を@code{__declspec(dllexport)}でエクスポートし，
@code{__declspec(dllimport)}でインポートすることを意味します．このマクロ
が使用されていない場合，libtoolはパッケージライブラリがクリーンなdllでは
なく，win32ホストでのスタティックライブラリのみをビルドすると仮定します．

このマクロは@code{AC_PROG_LIBTOOL}の@strong{前で}呼び出す必要があり，パッ
ケージの@code{Makefile}でのリンクモードでの準備として，@code{libtool}に
@samp{-no-undefined}を渡させる必要があります．通常，@samp{-no-undefined} 
を渡す場合，すべてのライブラリシンボルが，リンク時には@strong{本当に}定
義されていることを確かめる必要があります！
@end defmac

@defmac AC_DISABLE_FAST_INSTALL
@code{AC_PROG_LIBTOOL}のデフォルトの動作を，高速インストールに対する最適
化を不可能にするよう変更します．ユーザはこのデフォルトを，プラットフォー
ムのサポートに依存して，@samp{--enable-fast-install}を指定することで優先
させることができます．
@end defmac

@defmac AC_DISABLE_SHARED
@defmacx AM_DISABLE_SHARED
@code{AC_PROG_LIBTOOL}のデフォルトの動作を，共有ライブラリを利用不可能に
変更します．ユーザはこのデフォルトを，@samp{--enable-shared}を指定するこ
とで優先させることができます．
@end defmac

@defmac AC_DISABLE_STATIC
@defmacx AM_DISABLE_STATIC
@code{AC_PROG_LIBTOOL}のデフォルトの動作を，スタティックライブラリを利用
不可能に変更します．ユーザはこのデフォルトを，@samp{--enable-static}を指
定することで優先させることができます．
@end defmac

@code{AC_PROG_LIBTOOL}内のテストは，以下の環境変数も認識します．

@defvar CC
生成された@code{libtool}が使用するCコンパイラです．これが設定されていな
い場合，@code{AC_PROG_LIBTOOL}は@code{gcc}や@code{cc}を探します．
@end defvar

@defvar CFLAGS
標準的なオブジェクトファイルを生成するために使用するコンパイラフラグです．
これが設定されていない場合，@code{AC_PROG_LIBTOOL}はそのようなフラグを全
く使用しません．それは，@code{AC_PROG_LIBTOOL}がテストを実行する方法にの
み効果があり，生成された@code{libtool}には効果はありません．
@end defvar

@defvar CPPFLAGS
Cプリプロセッサフラグです．これが設定されていない場合，
@code{AC_PROG_LIBTOOL}はそのようなフラグを全く使用しません．それは，
@code{AC_PROG_LIBTOOL}がテストを実行する方法にのみ効果があり，生成された
@code{libtool}には効果はありません．
@end defvar

@defvar LD
(生成された@code{libtool}が要求する場合は)システムリンカです．これが設定
されていない場合，@code{AC_PROG_LIBTOOL}は，@var{CC}で使用されるリンカが
何かを判別しようとします．
@end defvar

@defvar LDFLAGS
プログラムをリンクするとき，@code{libtool}が使用するフラグです．これが設
定されていない場合，@code{AC_PROG_LIBTOOL}はそのようなフラグを全く使用し
ません．それは，@code{AC_PROG_LIBTOOL}がテストを実行する方法にのみ効果が
あり，生成された@code{libtool}には効果はありません．
@end defvar

@defvar LIBS
プログラムのリンクとき，@code{AC_PROG_LIBTOOL}が使用するライブラリです．
これが設定されていない場合，@code{AC_PROG_LIBTOOL}はそのようなフラグを使
用しません．それは@code{AC_PROG_LIBTOOL}が実行するテストにのみに効果があ
り，生成された@code{libtool}には効果はありません．
@end defvar

@defvar NM
使用するプログラムで，@code{nm}の調査ではありません．
@end defvar

@defvar RANLIB
使用するプログラムで，@code{ranlib}の調査ではありません．
@end defvar

@defvar LN_S
プログラムのリンクを作成するコマンドで，可能な場合はソフトリンク，それ以
外ではハードリンクです．この変数が設定されていない場合，
@code{AC_PROG_LIBTOOL}は適切なプログラムを調査します．
@end defvar

@defvar DLLTOOL
使用するプログラムで，@code{dlltool}の調査ではありません．
Cygwin/MS-Windowsでのみ意味があります．
@end defvar

@defvar OBJDUMP
使用するプログラムで，@code{objdump}の調査ではありません．
Cygwin/MS-Windowsでのみ意味があります．
@end defvar

@defvar AS
使用するプログラムで，@code{as}の調査ではありません．しばらくは，
Cygwin/MS-Windows でのみ使用されます．
@end defvar

@pindex aclocal
@code{libtoolize}プログラムを呼び出すとき(@pxref{Invoking libtoolize})，
それは@code{AC_PROG_LIBTOOL}の定義が見つかる場所を伝えます．Automakeを使
用している場合，@code{aclocal}プログラムは自動的に，@code{configure}スク
リプトに@code{AC_PROG_LIBTOOL}サポートを@code{configure}スクリプトに加え
ます．

それにもかかわらず，@file{acinclude.m4}に@file{libtool.m4}のコピーを含め
ることは賢明で，そのため，@file{aclocal.m4}と@file{configure}がとある理
由で再びビルドされた場合も，適切なlibtoolマクロが使用されます．代わりに，
ユーザが@file{libtool.m4}の互換バージョンをインストールしていて，
@code{aclocal}にアクセス可能なことを期待します．これは，バージョンが一致
しない場合，不運なエラーを導くかもしれません．


@node Distributing
@section パッケージにlibtoolを含める

libtoolを使用するため，パッケージに以下のファイルを含める必要があります．

@table @file
@item config.guess
@pindex config.guess
標準的なシステム名の判別を試みます．

@item config.sub
@pindex config.sub
標準的なシステム名を評価する，サブルーチンスクリプトです．

@item ltmain.sh
@pindex ltmain.sh
基本的なlibtool機能を実装する一般的なスクリプトです．
@end table

libtoolスクリプト自身はパッケージに含まれないことに注意してください．
@xref{Configuring}.

手動でこれらのファイルをパッケージにコピーするより，@code{libtoolize}プ
ログラムを使用した方がよいでしょう．

@menu
* Invoking libtoolize::         @code{libtoolize} command line options.
* Autoconf .o macros::          Autoconf macros that set object file names.
@end menu

@node Invoking libtoolize
@subsection @code{libtoolize}の呼び出し
@pindex libtoolize
@cindex libtoolize command options
@cindex command options, libtoolize
@cindex options, libtoolize command

@code{libtoolize}プログラムは，libtoolサポートをパッケージに追加する標準
的な方法を提供します．将来は，より良い調査の使用法や，より簡単にlibtool 
を作成する特徴を実装するかもしれません．

@code{libtoolize}プログラムは以下の構文です．

@example
libtoolize [@var{option}]@dots{}
@end example

@noindent
そして，以下のオプションを受け入れます．

@table @samp
@item --automake
静かに動作し，libtoolがサポートされているAutomakeを仮定します．

@samp{libtoolize --automake}は，@code{AC_PROG_LIBTOOL}が
@file{configure.in}にあるとき，Automakeがlibtoolファイルをパッケージに追
加するために使用します．

@item --copy
@itemx -c
libtoolデータディレクトリから，シンボリックリンクを作成するのではなく，
ファイルをコピーします．

@item --debug
シェルスクリプトの実行の追跡を，標準出力にダンプします．これは大量の出力
を生成するため，@code{less}(や@code{more})にパイプしたり，ファイルにリダ
イレクトしたいかもしれません．

@item --dry-run
@itemx -n
ファイルシステムを変更するコマンドは実行せず，それらを出力するだけです．

@item --force
@itemx -f
既存のlibtoolのファイルを置換します．デフォルトで，@code{libtoolize}は既
存のファイルを上書きしません．

@item --help
へルプメッセージを出力し終了します．

@item --ltdl
パッケージのサブディレクトリに，libltdlをインストールします．

@item --ltdl-tar
ファイルlibltdl.tar.gzをパッケージに追加します．

@item --version
@code{libtoolize}のバージョン情報を出力し終了します．
@end table

@findex AC_CONFIG_AUX_DIR
@code{libtoolize}が，パッケージの@file{configure.in}で，明確な
@code{AC_CONFIG_AUX_DIR}の呼び出しを検出した場合(@pxref{Input, , The
Autoconf Manual, autoconf, The Autoconf Manual})，指定されたディレクトリ
にファイルを配置します．

@code{libtoolize}は，パッケージにlibtoolサポートを加えるヒントも同様に表
示します．


@node Autoconf .o macros
@subsection Autoconfの@samp{.o}マクロ

utoconfパッケージは，テストを実行するいくつかのマクロをもたらし，それは，
オブジェクトファイル名に対応して変数を設定します．libtoolオブジェクトに
対応する名前を使用する必要があるときもあります．

ここにlibtoolオブジェクトがリストアップする変数名があります．

@defvar LTALLOCA
@findex AC_FUNC_ALLOCA
@code{AC_FUNC_ALLOCA}で置換されます(@pxref{Particular Functions,
Particular Function Checks, The Autoconf Manual, autoconf, The Autoconf
Manual})．空，または@samp{alloca.lo}を含みます．
@end defvar

@defvar LTLIBOBJS
@findex AC_REPLACE_FUNCS
@code{AC_REPLACE_FUNCS}(@pxref{Generic Functions, Generic Function
Checks, The Autoconf Manual, autoconf, The Autoconf Manual})とその他の関
数で置換されます．
@end defvar

残念ながら，安定版のリリースのAutoconf(これを書いている時期は，2.13)は，
libtoolでこれらの変数を提供する方法が全くありません．そのため，それに依
存して，パッケージの@file{configure.in}で@code{AC_OUTPUT}を呼び出す前に，
以下のコードの実装を使用してください．

@example
LTLIBOBJS=`echo "$LIBOBJS" | sed 's/\.[^.]* /.lo /g;s/\.[^.]*$/.lo/'`
AC_SUBST(LTLIBOBJS)
LTALLOCA=`echo "$ALLOCA" | sed 's/\.[^.]* /.lo /g;s/\.[^.]*$/.lo/'`
AC_SUBST(LTALLOCA)
AC_OUTPUT(@dots{})
@end example


@node Static-only libraries
@section スタティックのみのライブラリ
@cindex debugging libraries
@cindex developing libraries
@cindex double-compilation, avoiding
@cindex avoiding shared libraries
@cindex eliding shared libraries
@cindex using shared libraries, not
@cindex shared libraries, not using
@cindex time, saving
@cindex saving time

パッケージを開発しているとき，パッケージを@samp{--disable-shared}フラグ
でコンフィグレーションしたり，@code{AC_DISABLE_SHARED} Autoconfマクロ
(@pxref{AC_PROG_LIBTOOL, , The @code{AC_PROG_LIBTOOL} macro})を使用して，
@code{AC_PROG_LIBTOOL}のデフォルトに優先することに価値があることもよくあ
ります．これは，libtoolが共有ライブラリをビルドすることを避け，それには，
いくつかの利点があります．

@itemize @bullet
@item
2回目のコンパイルを速くし，開発サイクルを高速にします．

@item
共有ライブラリによって加えられる複雑さの詳細が不要なので，デバッグがより
簡単になります．

@item
スタティックのみのプラットフォームでのlibtoolの動作方法が分かります．
@end itemize

パッケージの@file{README}に，他の開発者に@samp{--disable-shared}で時間を
稼げることを知らせるため，ちょっとした注意を書きたいかもしれません．以下
の例の注意は，GIMP@footnote{思い切りがよくない人のためのGNU Image
Manipulation Programです．@url{http://www.gimp.org/}を参照してください．} 
配布物の@file{README}から持ってきました．

@example
The GIMP uses GNU Libtool in order to build shared libraries on a
variety of systems. While this is very nice for making usable
binaries, it can be a pain when trying to debug a program. For that
reason, compilation of shared libraries can be turned off by
specifying the @samp{--disable-shared} option to @file{configure}.
@end example


@node Versioning
@chapter ライブラリインターフェースのバージョン
@cindex dynamic dependencies
@cindex dependency versioning
@cindex shared library versions

共有ライブラリで導入された発行物で，最も難しいものは，実行時の依存性の作
成と解決です．プログラムとライブラリの依存性は，@code{sed}のような単一の
名前の用語で，よく記述されます．そのため``libtoolはsedに依存する''と告げ，
それで十分目的を果たせます．

しかし，規則的にインターフェースが変更されるとき，我々はより具体的に告げ
る必要があります．``Gnus 5.1はEmacs 19.28以上を要求する．''ここでは，名
前からなるインターフェースの記述と``バージョンナンバー''です．

種類の説明はいくつかの目的において十分でないことすらあります．Emacs 20で
変更された場合，Gnus 5.1を破壊するのに十分ではないでしょうか？

同じ問題は，共有ライブラリでも存在します．我々は，プログラムが必要として
いるインターフェースを提供するライブラリのみとリンクされることを，ダイナ
ミックリンカが保証できるように，プログラムが依存する共有ライブラリを記述
するために，公式なバージョン管理システムが必要です．

@menu
* Interfaces::                  What are library interfaces?
* Libtool versioning::          Libtool's versioning system.
* Updating version info::       Changing version information before releases.
* Release numbers::             Breaking binary compatibility for aesthetics.
@end menu

@node Interfaces
@section ライブラリインターフェースとは？
@cindex library interfaces

ライブラリのインターフェースは，以下の何か(またはそれ以上)でしょう．

@itemize @bullet
@item
グローバル変数: 名前と型

@item
グローバル関数: 引数の型と数，戻り値の型，関数名

@item
標準入力，標準出力，標準エラー，ファイル形式

@item
ソケット，パイプ，プロセス間通信のプロトコル書式
@end itemize

スタティック関数は，ライブラリのユーザが直接利用不可能なので，インター
フェースに数えられないことに注意してください．


@node Libtool versioning
@section libtoolのバージョン管理システム
@cindex libtool library versions
@cindex formal versioning
@cindex versioning, formal

libtoolは独自の公式のバージョン管理システムがあります．それは，あまり柔
軟ではありませんが，強力なバージョン管理システムで，確かに最も単純です．

ライブラリとは，整数で任意に表示できるインターフェースのいくつかの組を
エクスポートするものだと考えて下さい．プログラムがライブラリとリンクされ
るとき，これらのインターフェースのサブセットを利用するかもしれません．

プログラムが使用するインターフェースのlibtoolの記述は単純です．それは，
結果のバイナリにある最大と最小のインターフェースの番号を符号化します
(@var{first-interface}, @var{last-interface})．

ダイナミックリンカは，ライブラリが@var{first-interface}と
@var{last-interface}の間の@emph{すべての}インターフェースの番号をサポー
トする場合，プログラムがライブラリとリンク可能なことを保証します．

libtoolの移植性の要求が，実際に必要と言うよりは厳密なので，問題を生じる
可能性があることに注意してください．

さて，@file{libhello}がインターフェースの5，16，17，18，と19をサポートし，
libtoolは@file{libhello}を@file{test}にリンクするとき使用されると仮定し
ます．

libtoolは@file{test}に数字5と19を符号化し，ダイナミックリンカは，5と19の
間の@emph{すべての}インターフェースをサポートしているライブラリのみと，
@file{test}をリンクします．そのため，ダイナミックリンカは@file{libhello} 
と@file{test}をリンクすることを拒否するのです！

この問題を排除するために，libtoolはライブラリは，連続したインターフェー
ス番号を宣言することのみ可能としています．そのため，@file{libhello}は，
16 から19までのインターフェースをサポートすることを宣言するのが精一杯で
す．そして，ダイナミックリンカは，@file{libhello}を@file{test}とリンクし
ます．

そのため，libtoolライブラリバージョンは，３つの整数で宣言されます．

@table @var
@item current
このライブラリで実装されている，最も新しいインターフェース番号．

@item revision
@var{current}のインターフェースの実装番号．

@item age
このライブラリで実装されている，最新と最古のインターフェースの違い．言い
換えると，ライブラリは，@code{@var{current} - @var{age}}から
@code{@var{current}}までの番号の範囲で，すべてのインターフェース番号を実
装しています．
@end table

2つのライブラリが，個別の@var{current}と@var{age}を持つ場合，ダイナミッ
クリンカは，より大きい@var{revision}番号を選択します．


@node Updating version info
@section ライブラリバージョン情報の更新

libtoolのバージョン管理システムを使用したい場合，リンクモード
(@pxref{Link mode})の時に，@samp{-version-info}フラグを使用して，libtool
にバージョン情報を指定する必要があります．

このフラグは，@samp{@var{current}[:@var{revision}[:@var{age}]]}の形式の
引数を受け入れます．そして，@samp{-version-info 3:12:1}を渡すと，
@var{current}を3，@var{revision}を12，そして@var{age}を1に設定します．

@var{revision}や@var{age}が省略された場合，デフォルトは0になります．また，
@var{age}は@var{current}インターフェース番号以下にする必要があることに注
意してください．

ライブラリバージョン情報を更新する助けとなる規則の集合は，以下のようにな
ります．

@enumerate 1
@item
バージョン情報は，それぞれのlibtoolライブラリに対し@samp{0:0:0}で始めて
ください．

@item
ソフトウェアの一般へのリリースの直前にのみ，バージョン情報を更新してくだ
さい．より頻繁な更新は不要で，現在のインターフェース番号が速くなることを
保証するだけです．

@item
前回の更新から，ライブラリソースコードが完全に変更された場合，
@var{revision}を増加してください(@samp{@var{c}:@var{r}:@var{a}}は
@samp{@var{c}:@math{r+1}:@var{a}}となります)．

@item
前回の更新から，インターフェースが加えられた，削除された，または変更され
た場合，@var{current}を増加し，@var{revision}を0に設定してください．

@item
前回の一般へのリリースから，あるインターフェースが削除された場合，
@var{age}を0に設定してください．

@item
前回の一般へのリリースから，あるインターフェースが削除された場合，
@var{age}を0に設定してください．
@end enumerate

パッケージのリリース番号に対応するように，インターフェース番号を設定する
試みは@strong{@emph{決して}}しないでください．これは，ライブラリバージョ
ンの目的の誤解を促進する悪習にすぎません．その代わり，@samp{-release}
フラグ(@pxref{Release numbers})を使用しますが，パッケージが他のリリース
とバイナリ互換でないことを警告されます．


@node Release numbers
@section リリース情報の管理

プログラムをライブラリにリンクしたいユーザに明確になるように，パッケージ
リリース名を共有ライブラリに符号化したいこともよくあります．この便利さは，
特にGNU/Linuxで使用されます．

@example
trick$ @kbd{ls /usr/lib/libbfd*}
/usr/lib/libbfd.a	    /usr/lib/libbfd.so.2.7.0.2
/usr/lib/libbfd.so
trick$
@end example

@samp{trick}として，@file{/usr/lib/libbfd.so}は@file{libbfd.so.2.7.0.2} 
へのシンボリックリンクで，それは@samp{binutils-2.7.0.2}の一部として配布
されています．

ライブラリインターフェースは，リリース番号のように，滅多に同時に変更され
す，ライブラリ接尾子はすべてのプラットフォームを跨り，すべて同じではない
ので，残念ながらこの便利さはlibtoolのライブラリバージョンの情報の考えと
直接衝突します．

そのため，両方の見方に適応するため，@samp{-version-info}を使用したくない
ライブラリに対し，リリース情報を設定するにあたり，@samp{-release}フラグ
を使用することができます．@file{libbfd}の例では，libtoolが使用する次のリ
リースは，@samp{-release 2.9.0}でビルドされるべきで，それは，GNU/Linuxで，
以下のファイルを生成します．

@example
trick$ @kbd{ls /usr/lib/libbfd*}
/usr/lib/libbfd-2.9.0.so     /usr/lib/libbfd.a
/usr/lib/libbfd.so
trick$
@end example

この場合，@file{/usr/lib/libbfd.so}は@file{libbfd-2.9.0.so}へのシンボリッ
クリンクです．これは@samp{binutils-2.9.0}を扱っているユーザにとって，バー
ジョン情報のlibtoolの考えに妥協することなく，明白になります．

このオプションはライブラリ名を編集することに注意し，過去のライブラリリリー
スとのバイナリ互換を壊したくない場合は使用しないでください．一般的に，パッ
ケージの内部ライブラリや，大変頻繁に変更されるインターフェースを持つ物に
対してのみ@samp{-release}を使用してください．


@node Library tips
@chapter インターフェース設計に対する助言
@cindex library interfaces, design
@cindex design of library interfaces

良いライブラリインターフェースと書くことは，多くの経験とライブラリが解決
する問題への完全な理解が必要です．

良いインターフェースを設計した場合，頻繁に変更する必要がなく，ドキュメン
トを更新し続ける必要がなく，ユーザはライブラリの使用方法を何度も学習する
必要がありません．

ここにライブラリインターフェースの設計に関するヒントの短いリストがあり，
それは仕事上で役立つでしょう．

@table @asis
@item 計画前
エントリポイントを頻繁に削除する必要がないように，すべてのインターフェー
スを本当に最小限にするように試みてください．

@item インターフェースの変更を避ける
@cindex renaming interface functions
エントリポイントの再設計と変更を地獄のように繰り返すのが好きな人もいます
(注意：関数の@emph{名前変更}はエントリポイントの変更と考えられます)．イ
ンターフェースを再設計する必要がある場合，ユーザが既存のコードを書き換え
る必要がないように，互換機能を残すことを試みてください．

@item 不透明なデータ型の使用
@cindex opaque data types
ライブラリユーザがアクセスするデータ型の定義は，少ないければ少ないほど良
いでしょう．可能な場合，一般的な(内部データにキャスト可能な)ポインタを受
け入れる関数を設計し，ライブラリユーザが直接データを操作するのを許可する
のではなく，アクセスする関数を提供してください．そうすることで，インター
フェースを変更せずに，データ構造を変更することが自由になります．

これは，本質的にオブジェクト指向のシステムで抽象的なデータ型と継承を使用
するのと同じです．

@item ヘッダファイルの使用
@cindex header files
ライブラリのグローバル関数と変数のそれぞれのドキュメントをヘッダファイル
に注意して書いていて，ライブラリソースファイルに含めている場合，コンパイ
ラは偶然にインターフェースの変更の有無を知らせるでしょう(@pxref{C header
files})．

@item 可能な場所での@code{static}キーワード(またはその等価物)の使用
@cindex global functions
ライブラリが持つグローバル関数は，減らせば減らすほど，より柔軟に変更でき
ます．スタティック関数と変数は，形式を変更したいとき変更できます@dots{} 
ユーザはそれらにアクセスできず，そのためインターフェースは変更されません．
@end table

@menu
* C header files::              How to write portable include files.
@end menu

@node C header files
@section Cヘッダファイルを書く
@cindex portable C headers
@cindex C header files, portable
@cindex include files, portable

移植性の高いCヘッダファイルを書くことは難しく，それは異なる形式のコンパ
イラで読まれる可能性があるためです．

@table @asis
@item C++コンパイラ
C++コンパイラは，Cより強固に形式化されているため，完全なプロトタイプで宣
言された関数を要求します．C関数と変数は，名前がおかしくならないように，
@code{extern "C"}ディレクティブで宣言する必要があります．libtool でC++の
使用に関連したその他の問題は，@xref{C++ libraries}.

@item ANSI Cコンパイラ
ANSI Cコンパイラは，C++コンパイラほど厳密ではありませんが，関数のプロト
タイプは，ヘッダファイルを@code{#include}したときの不必要な警告を避ける
ため，行う方が良いでしょう．

@item 非ANSI Cコンパイラ
Non-ANSIコンパイラは，関数がプロトタイプされている場合，エラーを報告しま
す．
@end table

これらの複雑さは，上記それぞれのコンパイラを利用可能にするため，ライブラ
リインファーフェースヘッダで，いくつかのCプリプロセッサの魔法を使用する
必要があることを意味します．

libtool配布物の@file{demo}サブディレクトリの@file{foo.h}は，安全にシステ
ムディレクトリにインストール可能な，ヘッダファイルの書き方の例を提供しま
す．

そのファイルの関連する部分は，以下のようになっています．

@example
/* BEGIN_C_DECLS should be used at the beginning of your declarations,
   so that C++ compilers don't mangle their names.  Use END_C_DECLS at
   the end of C declarations. */
#undef BEGIN_C_DECLS
#undef END_C_DECLS
#ifdef __cplusplus
# define BEGIN_C_DECLS extern "C" @{
# define END_C_DECLS @}
#else
# define BEGIN_C_DECLS /* empty */
# define END_C_DECLS /* empty */
#endif

/* PARAMS is a macro used to wrap function prototypes, so that
   compilers that don't understand ANSI C prototypes still work,
   and ANSI C compilers can issue warnings about type mismatches. */
#undef PARAMS
#if defined (__STDC__) || defined (_AIX) \
        || (defined (__mips) && defined (_SYSTYPE_SVR4)) \
        || defined(WIN32) || defined(__cplusplus)
# define PARAMS(protos) protos
#else
# define PARAMS(protos) ()
#endif
@end example

これらのマクロは，以下のように@file{foo.h}で使用されます．

@example
#ifndef FOO_H
#define FOO_H 1

/* The above macro definitions. */
#include "@dots{}"

BEGIN_C_DECLS

int foo PARAMS((void));
int hello PARAMS((void));

END_C_DECLS

#endif /* !FOO_H */
@end example

@file{#ifndef FOO_H}が，@file{foo.h}の本体を，与えられたコンパイルで一回
以上読み込むことを避けることに注意してください．

また，@code{BEGIN_C_DECLS}/@code{END_C_DECLS}の組の外側あるものだけが，
@code{#include}行にあります．厳密にいうと，それは，保護が必要なCのシンボ
ル名ですが，ヘッダの内容の中心周辺にこれらのマクロの単一の組がある場合，
ヘッダファイルはより管理しやすくなります．

@code{PARAMS}，@code{BEGIN_C_DECLS}，そして@code{END_C_DECLS}のこれらの
定義を独自のヘッダで使用すべきです．そして，C++，ANSI，そして非ANSIのコ
ンパイラ@footnote{我々は，@code{__P}，@code{__BEGIN_DECLS}そして
@code{__END_DECLS}の使用を推奨していました．アンダースコアで始まるシンボ
ル(とプリプロセッサマクロさえも)がコンパイラの使用で予約されているので，
悪いアドバイスでした．}で有効なヘッダファイルを作成するために，それらを
使用することが可能となります．

移植可能なコードをネイティブに書かないでください，上記のヒントに続けるこ
とで，最も明白な問題を無くすことに役立ちますが，明らかに別の微妙な問題が
あります．以下の問題に対処する必要があるかもしれません．

@itemize @bullet
@item
ANSI以前のコンパイラは，一般的なポインタ型@code{void *}を常にサポートす
るわけではなく，そこでは@code{char *}を使用する必要があります．

@item
@code{const}，@code{signed}そして@code{signed}キーワードは，サポートされ
ていないコンパイラもあり，特にANSI以前のコンパイラがあげられます．

@item
@code{long double}型は，多くのコンパイラでサポートされていません．
@end itemize


@node Inter-library dependencies
@chapter ライブラリ内部の依存
@cindex dependencies between libraries
@cindex inter-library dependencies

定義では，すべての共有ライブラリシステムは，シンボル解決が実行時まで延期
されるように，実行形式をライブラリに依存させる方法を提供します．

@dfn{ライブラリ内部の依存性}は，他のライブラリに依存するライブラリにあり
ます．例えば，libtoolライブラリ@file{libhello}が@code{cos}関数を使用する
場合，それは@file{libm}に対するライブラリ内部の依存性があり，数学ライブ
ラリが@code{cos}を実装しています．

共有ライブラリシステムには，内部で一貫した方法で，この機能を提供するもの
もあります．これらのシステムは，潜在的に無限長の依存性の連鎖を認めます．

しかし，ほとんどの共有ライブラリのシステムは，単一レベルの依存のみを認め
るという制限があります．これらのシステムでは，プログラムは共有ライブラリ
に依存しますが，共有ライブラリは他の共有ライブラリに依存しません．

あらゆる事象で，ライブラリ内部の依存性を宣言するため，libtoolは単純なメ
カニズムを提供します．独自のライブラリに依存するすべてのライブラリ
@file{lib@var{name}}に対しライブラリを作成するとき，対応する
@code{-l@var{name}}オプションをリンク行に単純に加えます．@file{libm}に依
存する@file{libhello}の例をビルドしてみます．

@example
burger$ @kbd{libtool gcc -g -O -o libhello.la foo.lo hello.lo \
                -rpath /usr/local/lib -lm}
burger$
@end example

プログラムを@file{libhello}に対しリンクするとき，@samp{-l}オプションを再
び指定する必要はありません．必要なライブラリがすべて見つかることを保証す
るため，libtoolがそれを行います．この制約は，静的なライブラリシステムと，
単純な動的ライブラリシステムとの互換性を保つために必要です．

AIXのように，この柔軟性さえ許可されないプラットフォームもあります．共有
ライブラリをビルドするため，それは完全に自己内蔵型である必要があり(すな
わち，@samp{.lo}ファイルや@samp{-l}で指定されたライブラリでシンボルが見
つかるもののみを参照する)，@var{-no-undefined}フラグを指定する必要があり
ます．デフォルトで，libtoolはこの種のプラットフォームではスタティックラ
イブラリのみをビルドします．

1.2以前のlibtoolのリリースのコードにおける，単純に考えられたライブラリ内
部の依存性の追跡は，ライブラリを他のライブラリとリンクすることが可能なと
きが明白でないため，それが利用ができず，複雑な異常終了が発生します．この
概念のより複雑な実装は，リリース1.3の前に再導入されましたが，libtoolがサ
ポートするすべてのプラットフォームに移植されませんでした．デフォルトで，
保守的な動作は，ライブラリが他のライブラリとリンクすることを避け，プログ
ラムがリンクされるときのみに，その内部依存性が導入されます．


@node Dlopened modules
@chapter dlopenモジュール
@findex dlopen
@findex dlsym
@findex dlclose
@findex shl_load
@cindex dynamic linking, applications
@cindex dlopening modules
@cindex modules, dynamic
@cindex application-level dynamic linking

@dfn{ダイナミックリンク}の議論では，その用語が２つの異なる概念を述べると
きに使用されるので，混乱することがあります．

@enumerate 1
@item
共有ライブラリに対しプログラムをコンパイルとリンクし，それは，ダイナミッ
クリンカにより実行時に自動的に解決される．この処理では，ダイナミックリン
クはアプリケーション透過です．

@item
アプリケーションの，@code{dlopen}@footnote{HP-UXでは異なり，
@code{shl_load}という名の関数が使用されます．}のような関数の呼び出しで，
それは，ユーザが指定したモジュールを実行時に任意にロードします．この形式
のダイナミックリンクは，アプリケーションで明示的に制御されます．
@end enumerate

混乱を軽減するため，このマニュアルは２番目の形式のダイナミックリンクを
@dfn{dlopen}モジュールとして述べることにします．

dlopenモジュールの主な利点は，プログラムを拡張するために，インタプリタ言
語を使用するのではなく，コンパイルされたオブジェクトコードにアクセスする
能力です．実際，dlopenは，言語を拡張する効果的な方法を提供するため，イン
タプリタ言語でよく使用されます．

バージョン@value{VERSION}の現在は，libtoolはdlopenされるモジュールのサポー
トを提供します．しかし，パッケージがそのようなサポートを行うことを，
@file{configure.in}で，マクロ@samp{AC_LIBTOOL_DLOPEN}を使用して指示した
方が良いでしょう．このマクロが使用されない(または@samp{AC_PROG_LIBTOOL} 
の@emph{後で}使用される)場合，libtoolはdlopenメカニズムが利用不可能と仮
定し，シミュレーションを試みます．

この章ではdlopenでアクセス可能なモジュールを生成するため，dlopenアプリケー
ション開発者がlibtoolを使用する方法を議論します．

@menu
* Building modules::            Creating dlopenable objects and libraries.
* Dlpreopening::                Dlopening that works on static platforms.
* Finding the dlname::          Choosing the right file to @code{dlopen}.
* Dlopen issues::               Unresolved problems that need your attention.
@end menu

@node Building modules
@section dlopenのためのモジュールのビルド

オペレーティングシステムには，プログラムシンボルを@code{dlsym}(またはそ
の等価)関数を用いて動的に解決するために，特別に宣言する必要があるものも
あります．

libtoolは，@samp{-export-dynamic}と@samp{-module}リンクフラグを提供し
(@pxref{Link mode})，それはこの宣言を行います．他のモジュールやdlopenさ
れているlibtoolライブラリをdlopenするアプリケーションプログラムをリンク
する場合，これらのフラグを使用する必要があります．

例えば，後でアプリケーションにdlopenされる共有ライブラリ@file{libhello} 
をビルドしたい場合，他のリンクオプションに@samp{-module}を加えます．

@example
burger$ @kbd{libtool gcc -module -o libhello.la foo.lo \
                hello.lo -rpath /usr/local/lib -lm}
burger$
@end example

@emph{実行形式}からのシンボルが，dlopenしたいライブラリの未解決の参照を
満足させる必要がある場合，フラグ@samp{-export-dynamic}を使用する必要があ
ります．dlopenを呼び出す実行形式をリンクするとき，@samp{-export-dynamic} 
を使用してください．

@example
burger$ @kbd{libtool gcc -export-dynamic -o hell-dlopener main.o}
burger$
@end example


@node Dlpreopening
@section dlopen

libtoolは，dlopenするlibtoolオブジェクトとlibtoolライブラリファイルに対
し，@emph{たとえ@code{dlopen}と@code{dlsym}関数が無いプラットフォームで
も}，そのシンボルが解決できるように，特別のサポートを提供します．

``laziness''の増加順にプログラムにコードをロードする，以下の別の方法を考
慮します．

@enumerate 1
@item
参照するしないに関わらない，実行形式の一部となるオブジェクトファイルへの
リンクです．オブジェクトファイルが見つからない場合，リンカは実行形式の作
成を停止します．

@item
上記のオブジェクトファイルでの未定義の参照を満足させるように，リンク時に
検索されるようにするための，リンカに対するスタティックライブラリの宣言で
す．スタティックライブラリが見つからない場合，リンカは実行形式の作成を停
止します．

@item
上記のファイルでの未定義の参照を満足させるために，実行時に検索されるよう
にするための，実行時リンクの共有ライブラリの宣言です．共有ライブラリが見
つからない場合，ダイナミックリンカは実行形式の作成を停止します．

@item
アプリケーション自身が解決することができるように，参照を動的解決する
dlopenモジュールです．モジュールを開くときエラーが発生したり，モジュール
が見つからない場合，アプリケーションは壊れることなく回復します．
@end enumerate

libtoolは，コンパイル時にオブジェクトファイルをプログラムにリンクし，プ
ログラムのシンボルテーブルを表現するデータ構造を作成することで，スタティッ
クなプラットフォームで@samp{-dlopen}オプションをエミュレートします．

この特徴を使用するため，プログラムのリンク時(@pxref{Link mode})に
@samp{-dlopen}や@samp{-dlpreopen}フラグを使用することで，アプリケーショ
ンでdlopenしたいオブジェクトを宣言する必要があります．

@deftypefn {Structure} {struct} lt_dlsymlist @{ @w{const char *@var{name};} @w{lt_ptr @var{address};} @}
@var{name}属性は，@code{"fprintf"}のような，シンボル名のNULL終端されてい
る文字列です．@var{address}属性は，@code{&fprintf}のような対応するオブジェ
クトへの一般的なポインタです．
@end deftypefn

@deftypevar {const lt_dlsymlist *} lt_preloaded_symbols
@var{lt_symbol}構造体の配列で，プログラムにリンクされる，プリロードされ
ているすべてのシンボルを表現します．それぞれの@samp{-dlpreloaded}ファイ
ルに対し，ファイルの@var{name}を用いた要素と，@code{0}の@var{address}が
あり，このファイルからエクスポートされるすべてのシンボルが続きます．実行
形式自身に対し，特別の名前@@PROGRAM@@が使用されます．最後の要素は，
@var{name}と@code{0}の@var{address}を持ちます．
@end deftypevar

ドル記号のような，ANSI Cでは有効ではない識別子を許可するコンパイラもあり
ます．libtoolはANSI Cで有効なシンボル(最初がASCII文字またはアンダースコ
アで，0以上のASCII文字，数字，そしてアンダースコアが続くもの)のみ認識す
るので，非ASCIIシンボルは@var{lt_preloaded_symbols}に出現しません．


@node Finding the dlname
@section dlopenで正しい名前の検索
@cindex names of dynamic modules
@cindex dynamic modules, names

@samp{-module}を用いてライブラリがリンクされた後，dlopen可能になります．
残念ながら ライブラリ名が変更されるため，パッケージでdlopenの正しいファ
イルを決定する必要があります．

最も率直で柔軟な実装は，インストールされた@samp{.la}ファイルを探し，以下
の行を検索することで実行時に決定することです．

@example
# The name that we can @code{dlopen}.
dlname='@var{dlname}'
@end example

@var{dlname}が空の場合，ライブラリはdlopenされません．それ以外では，それ
でライブラリのdlnameを与えます．そのため，ライブラリが
@file{/usr/local/lib/libhello.la}にインストールされていて，@var{dlname}
が@file{libhello.so.3}の場合，@file{/usr/local/lib/libhello.so.3}が
dlopenされます．

プログラムがこのアプローチを行っている場合，ライブラリが最終的にインストー
ルされるディレクトリと同じように，@code{LD_LIBRARY_PATH}@footnote{AIXで
の@code{LIBPATH}とHP-UXでの@code{SHLIB_PATH}です．}環境変数でリストアッ
プされているディレクトリで検索します．この変数(または同等物)を検索するこ
とで，インストール前でも，プログラムがlibtoolを使用してリンクし提供され
ているdlopenモジュールを見つけることを保証します．


@node Dlopen issues
@section 未解決のdlopenの問題
@cindex pitfalls with dlopen
@cindex dlopening, pitfalls
@cindex trouble with dlopen

以下の問題は，libtoolのdlopenサポートを使用しても解決しません．

@itemize @bullet
@item
dlopen関数は一般に，共有ライブラリプラットフォームでのみ利用可能です．パッ
ケージをスタティックなプラットフォームに移植したい場合，libltdl
(@pxref{Using libltdl})を使用する，または，代わりとなる独自のdlopenダイ
ナミックコードを開発する必要があります．最も妥当な解決方法は，
@code{dlopen}ファミリーのラッパー関数を書くことを必要とし，それは，与え
られたプラットフォームでdlopenがサポートされていないまたは利用不可能なと
きの，パッケージ特有のトリックです．

@item
関数の@code{dlopen}ファミリーの実装には大きな違いがあります．同じ関数名
を用いないプラットフォーム(特にHP-UXでは@code{shl_load}ファミリーを用い
ます)さえ存在します．

@item
アプリケーション開発者は，@code{dlopen}に渡す正しいモジュール名を発見す
るために，カスタムの検索関数を書く必要があります．
@end itemize


@node Using libltdl
@chapter libltdlの使用
@findex libltdl
@findex dlopen
@findex dlsym
@findex dlclose
@findex dlerror
@findex shl_load
@cindex dynamic linking, applications
@cindex dlopening modules
@cindex modules, dynamic
@cindex application-level dynamic linking

libtoolは，@file{libltdl}と呼ばれる小さなライブラリを提供し，それは，
dlopenライブラリの様々な困難をプログラマから隠すことを目指します．それは，
dlopenの機能で必要とされるアプリケーションとともに配布可能な，ヘッダファ
イルと小さなCソースファイルから成り立ちます．@file{libltdl}サービスの単
純な実装に対し，あまりに制限が多いダイナミックリンカをもつプラットフォー
ム上では，GNU DLDを要求したり，libtoolのdlpreopenメカニズムを用いてダイ
ナミックリンクをエミュレートするだけのものもあります．

@noindent
libltdlは，現在以下のダイナミックリンクメカニズムをサポートします．

@itemize @bullet
@item
@code{dlopen} (Solaris，Linux，そして様々なBSD)
@item
@code{shl_load} (HP-UX)
@item
@code{LoadLibrary} (Win16とWin32)
@item
@code{load_add_on} (BeOS)
@item
GNU DLD (スタティックライブラリに対するダイナミックリンクのエミュレーション)
@item
libtoolのdlpreopen (@pxref{Dlpreopening})
@end itemize

@noindent
以下の例外で，libltdlはGNUライブラリ公有使用許諾書の条件下でライセンスさ
れています．

@quotation
GNU Lesser General Public Licenseの特別な例外として，GNU libtoolを使用し
てビルドされるプログラムやライブラリの一部としてこのファイルを配布する場
合，プログラムの残りに対して使用する配布条件と同じものにして，それを含め
ることができます．
@end quotation

@menu
* Libltdl interface::           How to use libltdl in your programs.
* Modules for libltdl::         Creating modules that can be @code{dlopen}ed.
* Thread Saftey in libltdl::	Registering callbacks for multi-thread safety.
* User defined module data::    Associating data with loaded modules.
* Module loaders for libltdl::  Creating user defined module loaders.
* Distributing libltdl::        How to distribute libltdl with your package.
@end menu

@node Libltdl interface
@section プログラムでのlibltdlの使用法

@noindent
libltdl APIは，強力なSolarisとLinuxのdlopenインターフェースに似ていて，
それは，非常に簡単ですが強力です．

@noindent
プログラムでlibltdlを使用するために，ヘッダファイル@file{ltdl.h}をインク
ルードする必要があります．

@example
#include <ltdl.h>
@end example

@noindent
libltdlの前回のリリースでは，@sc{posix}名前空間の慣習に違反していたシン
ボルを，いくつか使用していました．これらのシンボルは，現在非難され，ここ
で記述されるように置換されました．古い非難されているシンボル名に依存した
コードがある場合，@file{ltdl.h}をインクルードする前に
@samp{LT_NON_POSIX_NAMESPACE}を定義すると，変換されたマクロが提供されま
す．使用するシンボルの組が何であっても，新しいAPIは前回のものとバイナリ
互換ではないので，このバージョンのlibltdlを使用するため，アプリケーショ
ンを再コンパイルする必要があるでしょう．

@noindent
libltdlがスレッドセーフでない，すなわち，マルチスレッドアプリケーション
は，libtoolに対しミューテックスを使用する必要があることに注意してくださ
い．それは，GNU/Linuxのglibc 2.0の@samp{RTLD_LAZY}を用いた@code{dlopen} 
が(デフォルトでlibtoolを使用します)，スレッドセーフではないことが報告さ
れていますが，この問題は，glibc 2.1でおそらく修正されるでしょ．一方，
@samp{RTLD_NOW}は，FreeBSD上のマルチスレッドアプリケーションで問題が生じ
たと報告されています．これらの問題に関する作業は，読者の演習として残って
います．貢献は，きっと歓迎されます．

@noindent
以下の型は@file{ltdl.h}で定義されています．

@deftp {Type} lt_ptr
@code{lt_ptr}は，汎用ポインタです．
@end deftp

@deftp {Type} lt_dlhandle
@code{lt_dlhandle}はモジュール"ハンドル"です．すべてのlt_dlopenされるモ
ジュールはそれに関連付けされたハンドルがあります．
@end deftp

@deftp {Type} lt_dlsymlist
@code{lt_dlsymlist}はdlpreopenされるモジュールのシンボルリストです．この
構造体は，@pxref{Dlpreopening}で記述されます．
@end deftp

@page
@noindent
libltdlは以下の関数を提供します．

@deftypefun int lt_dlinit (void)
libltdlを初期化します．この関数は，libltdl使用する前に呼び出す必要があり，
複数回呼び出すことが可能です．成功したら0，それ以外ではエラーの番号を返
します．
@end deftypefun

@deftypefun int lt_dlexit (void)
libltdlを終了し，すべてのモジュールを閉じます．この関数は，
@code{lt_dlinit}が正常に呼び出された回数と同じだけ呼び出されたとき，
libltdlを終了するだけです．成功したら0，それ以外ではエラーの番号を返しま
す．
@end deftypefun

@deftypefun lt_dlhandle lt_dlopen (const char *@var{filename})
ファイル名@var{filename}を用いてモジュールを開き，そのハンドルを返します．
@code{lt_dlopen}は，libtoolダイナミックモジュール，プリロードされたスタ
ティックモジュール，プログラム自身，そしてネイティブなダイナミックライブ
ラリを開くことが可能です．

モジュール内の未解決のシンボルは，それが依存する(まだ実装されていない)ラ
イブラリと，前もってdlopenされたモジュールを用いて解決されます．このモ
ジュールを使用している実行形式が@code{-export-dynamic}フラグでリンクされ
ている場合，実行形式の大域的なシンボルもモジュール内の参照の解決に使用さ
れます．

@var{filename}が@code{NULL}でプログラムが@code{-export-dynamic}や
@code{-dlopen self}を用いてリンクされている場合，@code{lt_dlopen}はプロ
グラム自身のハンドルを返し，それはそのシンボルのアクセスに使用可能です．

libltdlがライブラリを見つけられず，ファイル名@var{filename}がディレクト
リコンポーネントを持たない場合，それは，以下の検索パスを(以下の順番で)，
さらにモジュールを検索します．

@enumerate 1
@item
ユーザ定義の検索パス：

この検索パスは，関数@code{lt_dlsetsearchpath}と@code{lt_dladdsearchdir} 
を用いたプログラムで設定可能です．

@item
libltdlの検索パス：

この検索パスは，環境変数@var{LTDL_LIBRARY_PATH}の値です．

@item
システムのライブラリ検索パス：

システム依存のライブラリ検索パスです(例えば，Linuxでは
@var{LD_LIBRARY_PATH}になります)．
@end enumerate

それぞれの検索パスは，例えば@code{"/usr/lib/mypkg:/lib/foo"}のような，コ
ロンで分けられた絶対的なディレクトリのリストにする必要があります．

同じモジュールが複数回ロードされた場合，同じハンドルが返されます．あらゆ
る原因で@code{lt_dlopen}が失敗した場合，@code{NULL}が返されます．
@end deftypefun

@deftypefun lt_dlhandle lt_dlopenext (const char *@var{filename})
ファイル名に異なるファイル名の拡張子を追加を試みる以外は，
@code{lt_dlopen}と同じです．ファイル名@var{filename}を持つファイルが見つ
からない場合，libltdlは，以下の拡張子の追加を試みます．

@enumerate 1
@item
libtoolのアーカイブ拡張子@samp{.la}です．

@item
ホストプラットフォームの本来のダイナミックライブラリに使用される拡張子で，
例えば，@samp{.so}，@samp{.sl}等です．
@end enumerate

この探索手法は，本来のダイナミックライブラリの命名規則を知らないプログラ
ムが，そのようなライブラリを，libtoolモジュールと同様に，透過的に
@code{dlopen}することを可能にするために設計されています．
@end deftypefun

@deftypefun int lt_dlclose (lt_dlhandle @var{handle})
モジュール@var{handle}の参照カウントを減らします．ゼロになったり，このモ
ジュールに依存する他のモジュールがない場合，モジュールはアンロードされま
す．成功時には0を返します．
@end deftypefun

@deftypefun lt_ptr lt_dlsym (lt_dlhandle @var{handle}, const char *@var{name})
モジュール@var{handle}内のアドレスを返し，そこでは，ヌルで終端された文字
列@var{name}で与えられるシンボルがロードされています．シンボルが見つから
ない場合は@code{NULL}を返します．
@end deftypefun

@deftypefun {const char *}lt_dlerror (void)
libltdlのあらゆる関数から発生した最も新しいエラーを記述する，可読性の高
い文字列を返します．初期化からまたは最後に呼び出されてからエラーが発生し
ていない場合，@code{NULL}を返します．
@end deftypefun

@deftypefun int lt_dlpreload (const lt_dlsymlist *@var{preloaded})
プリロードされているモジュール@var{preloaded}のリストを登録します．
@var{preloaded}が@code{NULL}の場合，@code{lt_dlpreload_default}で設定さ
れているリスト以外の，これまで登録されているすべてのシンボルリストが検出
されます．成功時には0を返します．
@end deftypefun

@deftypefun int lt_dlpreload_default (const lt_dlsymlist *@var{preloaded})
プリロードされているモジュールリストのデフォルトを@var{preloaded}に設定
し，それは@code{lt_dlpreload}で検出されません．この関数は，
@code{lt_dlinit}を使用して初期化されるためにlibltdlを要求し@emph{ない}こ
とと，デフォルトでプリロードされるモジュールを登録するためにプログラムで
使用できることに注意してください．この関数を直接呼び出す代わりに，ほとん
どのプログラムはマクロ@code{LTDL_SET_PRELOADED_SYMBOLS}を使用します．

成功時には0を返します．
@end deftypefun

@defmac LTDL_SET_PRELOADED_SYMBOLS()
プリロードされるシンボルのデフォルトリストを設定します．プリロードされる
libltdlのモジュールを初期化するために，プログラムで使用した方が良いでしょ
う．

@example
#include <ltdl.h>

int main() @{
  /* ... */
  LTDL_SET_PRELOADED_SYMBOLS();
  /* ... */
@}
@end example
@end defmac

@deftypefun int lt_dladdsearchdir (const char *@var{search_dir})
検索ディレクトリ@var{search_dir}をユーザー定義のライブラリ検索パスに追加
します．成功時には0を返します．
@end deftypefun

@deftypefun int lt_dlsetsearchpath (const char *@var{search_path})
現在のユーザ定義のライブラリ検索パスを@var{search_path}で置換し，それは
コロンで分けられた絶対的なディレクトリのリストにする必要があります．成功
時には0を返します．
@end deftypefun

@deftypefun {const char *}lt_dlgetsearchpath (void)
現在のユーザ定義のライブラリ検索パスを返します．
@end deftypefun

@deftypefun int lt_dlmakeresident (lt_dlhandle @var{handle})
モジュールを@samp{lt_dlclose}できないように印を付けます．モジュールがプ
ロジェクトの中心部の機能を実装している場合，削除されるとコードが壊れるの
で，これは役に立つはずです．成功すると0を返します．

実行しているバイナリに対する@var{handle}を取得するために@samp{lt_dlopen
(NULL)}を使用する場合，そのハンドルは常駐しているような印が常に付き，し
たがってうまく@samp{lt_dlclose}することができません．
@end deftypefun

@deftypefun int lt_dlisresident (lt_dlhandle @var{handle})
特定のモジュールが常駐しているように印が付いているかどうか調査し，その場
合は1を返し，それ以外では0を返します．この関数の実行中にエラーがある場合， 
-1 が返され，@code{lt_dlerror}を用いて回収されるエラーメッセージが設定さ
れます．
@end deftypefun

@deftypevar {lt_ptr (*) (size_t @var{size})} lt_dlmalloc
@deftypevarx {void (*) (lt_ptr @var{ptr})} lt_dlfree
これらの変数は，デフォルトで@code{malloc}と@code{free}に設定されますが，
同等の機能を提供する他の関数に設定可能です．しかし，
@code{lt_dlpreopen_default}やマクロ@code{LTDL_SET_PRELOADED_SYMBOLS}以外
のあらゆるlibltdl関数の呼び出し後に，その値を編集すべきではありません．
@end deftypevar


@node Modules for libltdl
@section @code{dlopen}可能なモジュールの作成

libtoolモジュールは，いくつかの例外はありますが，通常のlibtoolライブラリ
に似ています．

libtoolの@samp{-module}スイッチを用いて，モジュールとリンクする必要があ
り，そして，dlopenをサポートしていないプラットフォームでlibtoolが
dlpreopenできるよう，@samp{-dlopen modulename.la}を用いてモジュールを
dlopenするために，あらゆるプログラムとリンクすべきです．モジュールが，あ
らゆる他のライブラリに依存する場合，モジュールとリンクするときや，それを
dlopenするプログラムをリンクするとき，それらを確実に指定してください．特
定のモジュールに対し@pxref{Versioning}を使用禁止にしたい場合，
@samp{-avoid-version}スイッチを用いてリンクすべきです．libtoolモジュール
は，"lib"接頭辞が不要なことに注意してください．しかし，automake 1.4やそ
れ以降のものは，そのようなモジュールのビルドが必要です．

通常，その内部を知る必要なしにプログラムがdlopenできるよう，一組のモジュー
ルは同じインターフェース提供し，すなわち同じシンボルをエクスポートします．
すべてのエクスポートされたシンボルで，シンボルの衝突を避けるため，
"modulename_LTX_"を前置する必要があります(@samp{modulename}はモジュール
名です)．内部シンボルは，例えば"_modulename_"を前置するといった，他のモ
ジュールと衝突しないような方法で命名する必要があります．一回以上宣言され
た，同じシンボルを持つことをサポートするシステムもありますが，それは通常
移植性がなく，そのようなモジュールをdlpreopenすることを不可能にします．
libltdlは，シンボルの本当の名前を得るとき，自動的に接頭辞を切り取ります．
さらに，非libtoolモジュールもdlopenできるよう，接頭辞を使用していないモ
ジュールをサポートします．

@file{foo1.c}は移植可能なlibtoolモジュールの例です．エクスポートされたシ
ンボルは"foo1_LTX_"，内部シンボルは"_foo1_"が前置されています．コードの
可読性を高めるため，エイリアスは最初に定義されています．

@example
/* aliases for the exported symbols */
#define foo	foo1_LTX_foo
#define bar	foo1_LTX_bar

/* a global variable definition */
int bar = 1;

/* a private function */
int _foo1_helper() @{
  return bar;
@}

/* an exported function */
int foo() @{
  return _foo1_helper();
@}
@end example

@noindent
@file{Makefile.am}は，モジュール@file{foo1.la}をビルドするのに必要な規則
を含んでいます．

@example
...
lib_LTLIBRARIES = foo1.la

foo1_la_SOURCES = foo1.c
foo1_la_LDFLAGS = -module
...
@end example


@node Thread Saftey in libltdl
@section マルチスレッド環境でのlibtldlの使用

@code{lt_dlmutex_register()}関数を使用し，適切なコールバック関数の定義を
提供することで，libltdlをマルチスレッド環境で使用することが可能です．

@deftypefn {Type} void lt_dlmutex_lock (void)
これは，ミューテックスロックが必要なlibltdlの実装コードの部分の，最初に
呼び出される関数のアドレスを持っている，関数のポインタ型です．

libltdlは本質的に再帰的なので，これらのコールバック関数によって使用され
るロックメカニズムがリエントリー可能であることは重要で，そうでなければ，
おかしな問題が発生します．
@end deftypefn

@deftypefn {Type} void lt_dlmutex_unlock (void)
アンロック関数に一致する型です．
@end deftypefn

@deftypefn {Type} void lt_dlmutex_seterror @w{(const char *@var{error});}
libltdl @sc{api}の関数の多くは，エラーを発生したクライアントを示す，特殊
な戻り値をとります．通常(シングルスレッドアプリケーションでは)，内部から
回収することができるエラーを記述する文字列は，@code{lt_dlerror()}に保存
されます．

この形式の関数は，それがマルチスレッドのコンテクストで動作するように，ラ
イブラリに登録される必要があります．関数は，スレッドローカルストレージに
渡されるあらゆるエラーメッセージを保存すべきです．
@end deftypefn

@deftypefn {Type} {const char *} lt_dlmutex_geterror (void)
スレッドローカルのストレージに，最後にエラーメッセージを保存したものに関
連するコールバック関数に一致する型です．

正しく登録されたとき，クライアントに対するエラーメッセージを回収するため
に，全てのスレッドから@code{lt_dlerror())}によって，この関数は使用されま
す．
@end deftypefn

@deftypefn {Function} int lt_dlmutex_register (@w{lt_dlmutex_lock *@var{lock}}, @w{lt_dlmutex_unlock *@var{unlock}}, @w{lt_dlmutex_set_error *@var{seterror}}, @w{lt_dlmutex_geterror *@var{geterror})}
libltdlのマルチスレッドの準備で，上記のそれぞれの関数の型を登録するため
に，この関数を使用してください．全ての引数は，有効な@code{NULL}でない関
数アドレスにする必要があり，また，そうでない場合は，シングルスレッドオペ
レーションへの戻り値として，全て@code{NULL}にする必要があります．
@end deftypefn


@node User defined module data
@section ロードされたモジュールに関連するデータ

libltdlが管理している，それぞれのロードされたモジュールに関する内部情報
には，ユーザが利用可能なものもあり，それは以下のような構造体の形式です．

@deftypefn {Type} {struct} lt_dlinfo @{ @w{char *@var{filename};} @w{char *@var{name};} @w{int @var{ref_count};} @}
@code{lt_dlinfo}は，モジュールの情報を保存するために使用されます．
@var{filename}属性は，@code{NULL}で終端された，実際のモジュールファイル
名の文字列です．モジュールがlibtoolモジュールの場合，@var{name}はそのモ
ジュール名(例えば，@code{"dir/libfoo.la"}に対する@code{"libfoo"})で，そ
れ以外では@code{NULL}に設定されます．@var{ref_count}属性は，現在ロードさ
れている同じモジュールの回数を記述する参照カウンタです．
@end deftypefn

以下の関数は，与えられた@var{handle}に対するこの構造体のlibltdlの内部の
コピーへのポインタを返します．

@deftypefun {const lt_dlinfo *} lt_dlgetinfo (@w{lt_dlhandle @var{handle}})
モジュール@var{handle}に関するいくつかの情報を含む構造体の，ポインタを返
します．構造体の内容は編集してはなりません．失敗時には@code{NULL}が返り
ます．
@end deftypefun

さらに，ロードした全てのモジュールのハンドルリストを保持する手助けをする
ために，これらの関数で，ロードされているモジュールのlibltdlのリスト全体
を繰り返すことが可能となります．

@deftypefun int lt_dlforeach (@w{int (*@var{func}) (lt_dlhandle @var{handle}, lt_ptr @var{data})}, @w{lt_ptr @var{data}})
ロードされているそれぞれのモジュールに対し関数@var{func}を呼び出します．
引数の@var{handle}は，ロードされているモジュールのハンドルの一つで，
@var{data}は，@code{lt_dlforeach}に渡す@var{data}引数です．@var{func}が
ハンドルの一つに対し，ゼロでない値を返すとすぐに，@code{lt_dlforeach}は
@var{func}の呼び出しを停止し，直ちに１を返します．それ以外は0が返ります．
@end deftypefun

@deftypefun lt_dlhandle lt_dlhandle_next (@w{lt_dlhandle place})
@var{place}が@code{NULL}の場合は，リスト内の最初のハンドルを返し，そして
順番に次ものを呼び出すことで，ロードされているモジュール全体を繰り返しま
す．@var{place}が，ロードされているモジュールリスト内の最後の要素の場合，
この関数は@code{NULL}を返します．
@end deftypefun

もちろん，アプリケーションの目的のために，それぞれのハンドルに関連付けす
る必要があるデータがある場合，libltdlで管理されるリストと平行して，ロー
ドされたモジュールハンドルの独自のリストの管理が必要になります．しかし，
個別のモジュールハンドルを用いたアプリケーションデータに，ロードされたも
のとして関連付けさせるために，以下の@sc{api}の呼び出しを使用する場合には，
実際にはそうする必要はありません．前もって保存したデータを回収するために
後で利用するlibltdlからのユニークな呼び出しidを，最初に取得する必要があ
ります．これで，ロードされているモジュールに対する独自のデータを個別に保
存したい異なるライブラリが，もう一つの(ライブラリ)のデータへのインター
フェースなしでそれを行うことが可能となります．

@deftp {Type} lt_dlcaller_id
個別のデータセットのキーを保つ，透過でない型です．
@end deftp

@deftypefun lt_dlcaller_id lt_dlcaller_register (void)
モジュールデータ毎に個別のセットを，保存し回収するためのユニークなキーを
取得するために，これを使用してください．
@end deftypefun

@deftypefun lt_ptr lt_dlcaller_set_data (@w{lt_dlcaller_id @var{key}}, @w{lt_dlhandle @var{handle}}, @w{lt_ptr @var{data}})
後で回収するために，@var{key}と@var{handle}にユニークに関連付けされたデー
タのセットとして，@var{data}を設定します．この関数は，以前に関連付けされ
た@var{key}と@var{handle}がある場合は，その@var{data}を返します．0の結果
は，前回のエラー(が存在する場合)に対する診断結果が，@code{lt_dlerror()}
で利用可能であることを示している可能性があります．

例えば，いくつかの関連データを正しく削除するために，以下のようにします．

@example
    lt_ptr stale = lt_dlcaller_set_data (key, handle, 0);
    if (stale == NULL)
      @{
        char *error_msg = lt_dlerror ();

        if (error_msg != NULL)
          @{
            my_error_handler (error_msg);
            return STATUS_FAILED;
          @}
      @}
    else
      @{
        free (stale);
      @}
@end example
@end deftypefun

@deftypefun lt_ptr lt_dlcaller_get_data (@w{lt_dlcaller_id @var{key}}, @w{lt_dlhandle @var{handle}})
@var{key}と@var{handle}に関連付けされている@var{data}のアドレス，または，
無い場合は@code{NULL}を返します．
@end deftypefun

ここまでの関数は，アプリケーションにロードされたりアンロードされたりした
モジュールを追跡させる必要なく，オペレーションの検索と適用を実装するため
に，@code{lt_dlforeach}と組み合わせることが可能です．

@example
int
my_dlcaller_callback (lt_dlhandle handle, lt_ptr key_ptr)
@{
  struct my_module_data *my_data;

  my_data = lt_dlcaller_get_data (handle, (lt_dlcaller_id) *key_ptr);

  return process (my_data);
@}

int
my_dlcaller_foreach (lt_dlcaller_id key)
@{
  lt_dlforeach (my_dlcaller_callback, (lt_ptr) &key);
@}
@end example


@node Module loaders for libltdl
@section 新しいモジュールローダの作成方法と登録方法

モジュールにアクセスするためのlibltdlの方法は多いけれど，プロジェクトの
目的に十分でないときもあります．独自のローダを書き，@code{lt_dlopen}が利
用できるように，libltdlでそれを登録することが可能です．

ローダを書くことは，@code{lt_dlopen}，@code{lt_dlsym}そして
@code{lt_dlclose}で呼び出し可能な，少なくとも3つの関数を書くことを必要と
します．オプションで，@code{lt_dlexit}が実行されるときクリーンアップ処理
を実行する終了関数と，@code{lt_dlsym}に渡されるあらゆるシンボルに前置さ
れるシンボルの前置文字を提供することも可能です．これらの関数は，以下の関
数のポインタ型に一致する必要があり，その後，それらを
@code{lt_user_dlloader}の代わりに関連付けし，登録することが可能です．

ローダの登録には，@code{lt_dlloader_find}が認識でき，
@code{lt_dlloader_remove}で削除できるように，それに対する名前を選択する
ことが必要です．選択した名前はユニークである必要があり，libltdlの組み込
みローダで既に使用しているものはいけません．

@table @asis
@item "dlopen"
存在する場合は，システムのダイナミックローダ．
@item "dld"
libltdlがビルドされたときに@file{libdld}がインストールされている場合は，
@sc{gnu} dldローダ．
@item "dlpreload"
プリロードされているスタティックモジュールの@code{lt_dlopen}のためのロー
ダ．
@end table

前置される"dl"は，libltdlの将来のバージョンで提供されるローダとして予約
されているので，独自のローダ名に使用すべきではありません．

@noindent
以下の型は，@file{ltdl.h}で定義されています．

@deftp {Type} lt_module
@code{lt_module}はモジュール依存のdlloaderです．ダイナミックモジュールロー
ダの拡張は，これらの低レベルの型を使用して通信を行ないます．
@end deftp

@deftp {Type} lt_dlloader
@code{lt_dlloader}はモジュールローダの型に対するハンドルです．
@end deftp

@deftp {Type} lt_dlloader_data
@code{lt_dlloader_data}はローダのインスタンスデータに対して使用されます．
@end deftp

@deftypefn {Type} {struct} lt_user_dlloader @{@w{const char *@var{sym_prefix};} @w{lt_module_open *@var{module_open};}@w{lt_module_close *@var{module_close};} @w{lt_find_sym *@var{find_sym};} @w{lt_dlloader_exit *@var{dlloader_exit};} @w{lt_dlloader_data @var{dlloader_data};} @}
ダイナミックモジュールを開くために新しい方法を定義したくて，それを使用し
た@code{lt_dlopen} @sc{api}がある場合，これらの構造体のインスタンスを作
成し，それを@code{lt_dlloader_add}に渡す必要があります．好みの
@var{dlloader_data}フィールドで渡すことが可能で，それは，関数ポインタフィー
ルドで指定されている，それぞれの関数への最初のパラメータの値として戻りま
す．
@end deftypefn

@deftypefn {Type} lt_module lt_module_open (@w{lt_user_data @var{loader_data},} @w{const char *@var{filename}})
@code{lt_dlloader}モジュールローダに対するローダ関数の型です．
@code{struct lt_user_dlloader}構造体のdlloader_dataフィールドに設定され
る値は，@var{loader_data}パラメータで，この関数に渡されます．そのような
関数の実装は，指名されたモジュールのロードを試み，関連する
@code{lt_module_close}と@code{lt_sym_find}関数のポインタに渡すのに適切な
@code{lt_module}を返すべきです．関数が失敗した場合は@code{NULL}を返し，
@code{lt_dlseterror}を用いてエラーメッセージを設定すべきです．
@end deftypefn

@deftypefn {Type} int lt_module_close (@w{lt_dlloader_data @var{loader_data},} @w{lt_module @var{module}})
ユーザが定義したモジュールローダに対するアンローダの型です．そのような関
数の実装は，@var{module}モジュールに結び付けられたあらゆるリソースの解放
を試み，その後でメモリからアンロードすべきです．理由があって関数が失敗し
た場合，@code{lt_dlseterror}を用いてエラーメッセージを設定し，ゼロ以外を
返すべきです．
@end deftypefn

@deftypefn {Type} lt_ptr lt_find_sym (@w{lt_user_data @var{loader_data},} @w{lt_module @var{module},} @w{const char *@var{symbol}})
ユーザが定義したモジュールローダに対する，シンボルルックアップ関数の型で
す．そのような関数の実装は，モジュール@var{module}内の指名された
@var{symbol}のアドレスを返す，もしくは，検査が失敗した場合は，エラーメッ
セージを@code{lt_dlseterror}で設定し，@code{NULL}を返すべきです．
@end deftypefn

@deftypefn {Type} int lt_dlloader_exit (@w{lt_user_data @var{loader_data}})
ユーザが定義したモジュールローダに対する，終了関数の型です．そのような関
数の実装は，ローダに関連するあらゆるリソースを解放すべきで，それには
@code{lt_user_dlloader}の@code{dlloader_data}フィールド内部にあるユーザ
が指定したあらゆるデータを含みます．@code{NULL}でない場合は，関数は
@code{lt_dlexit}と@code{lt_dlloader_remove}から呼び出されます．
@end deftypefn

例えば，以下のようにします．

@example
int
register_myloader (void)
@{
  lt_user_dlloader dlloader;

  /* User modules are responsible for their own initialisation. */
  if (myloader_init () != 0)
    return MYLOADER_INIT_ERROR;

  dlloader.sym_prefix    = NULL;
  dlloader.module_open   = myloader_open;
  dlloader.module_close  = myloader_close;
  dlloader.find_sym      = myloader_find_sym.
  dlloader.dlloader_exit = myloader_exit;
  dlloader.dlloader_data = (lt_user_data)myloader_function;

  /* Add my loader as the default module loader. */
  if (lt_dlloader_add (lt_dlloader_next (NULL), &dlloader, "myloader") != 0)
    return ERROR;

  return OK;
@}
@end example

ローダに対する必要な初期化がある場合は，ローダが登録される前に手動で実行
する必要があることに注意してください -- libltdlはユーザローダの初期化を
扱いません．

終了はlibltdlで扱われ@emph{ます}が，@code{dlloader_exit}のコールバックが
初期化フェーズの間に要求された，あらゆるリソースを解放することを確かめる
ことは重要です．

@page
@noindent
libltdlは，独自のモジュールローダを書くために，以下の関数を提供します．

@deftypefun int lt_dlloader_add (@w{lt_dlloader *@var{place},} @w{lt_user_dlloader *@var{dlloader},} @w{const char *@var{loader_name}})
新しいモジュールローダを全てのローダリストに加え，それは，(@var{place}が
@code{NULL}の場合は)最後のローダとして，それ以外では@var{place}として渡
されたローダの直前に加えます．@var{loader_name}は，新しく登録されたロー
ダが渡された場合，@code{lt_dlloader_name}を返します，これらの
@var{loader_name}は，ユニークである必要があり，そうでない場合は，
@code{lt_dlloader_remove}と@code{lt_dlloader_find}は動作不可能です．成功
に対し0を返します．

@example
@{
  /* Make myloader be the last one. */
  if (lt_dlloader_add (NULL, myloader) != 0)
    perror (lt_dlerror ());
@}
@end example
@end deftypefun

@deftypefun int lt_dlloader_remove (@w{const char *@var{loader_name}})
ユニークな名前@var{loader_name}で識別されているローダを削除します．これ
が成功可能となる前に，指名されたローダにより開かれている全てのモジュール
を，閉じておく必要があります．成功に対し0を返し，それ以外では，エラーメッ
セージが@code{lt_dlerror}から取得可能です．

@example
@{
  /* Remove myloader. */
  if (lt_dlloader_remove ("myloader") != 0)
    perror (lt_dlerror ());
@}
@end example
@end deftypefun

@deftypefun {lt_dlloader *}lt_dlloader_next (@w{lt_dlloader *@var{place}})
ローダモジュール全体を繰り返し，それは，@var{place}が@code{NULL}の場合は
最初のローダを返し，順番に次を呼び出すことで行います．ハンドルは，
@code{lt_dlloader_add}用です．

@example
@{
  /* Make myloader be the first one. */
  if (lt_dlloader_add (lt_dlloader_next (NULL), myloader) != 0)
    return ERROR;
@}
@end example
@end deftypefun

@deftypefun {lt_dlloader *}lt_dlloader_find (@w{const char *@var{loader_name}})
@var{loader_name}識別子に一致する最初のローダを返し，識別子が見つからな
い場合は@code{NULL}を返します．

libltdl自身で使用可能な識別子は，ホストアーキテクチャがサポートしている
場合は@dfn{dlopen}@footnote{これは，モジュールをロードしている@sc{api} 
に依存します -- 例えば，@code{shl_load}と@code{LoadLibrary}です}，
@dfn{dld}，そして@dfn{dlpreload}です．

@example
@{
  /* Add a user loader as the next module loader to be tried if
     the standard dlopen loader were to fail when lt_dlopening. */
  if (lt_dlloader_add (lt_dlloader_find ("dlopen"), myloader) != 0)
    return ERROR;
@}
@end example
@end deftypefun

@deftypefun {const char *}lt_dlloader_name (@w{lt_dlloader *@var{place}})
@code{lt_dlloader_next}や@code{lt_dlloader_find}で取得される，
@var{PLACE}の識別名を返します．この関数が失敗する場合，@code{NULL}を返し，
@code{lt_dlerror}で回収するためのエラーを設定します．
@end deftypefun

@deftypefun {lt_user_data *}lt_dlloader_data (@w{lt_dlloader *@var{place}})
@code{lt_dlloader_next}や@code{lt_dlloader_find}で取得される，
@var{PLACE}のアドレスを返します．この関数が失敗する場合，@code{NULL}を返
し，@code{lt_dlerror}で回収するためのエラーを設定します．
@end deftypefun


@subsection ユーザモジュールローダでのエラー処理

@deftypefun int lt_dladderror (@w{const char *@var{diagnostic}})
この関数で，独自のエラーメッセージを@code{lt_dlerror}に組み込むことが可
能となります．@code{lt_dlerror}で返すための適切な診断メッセージに渡すも
のと，@code{lt_dlseterror}で使用されるエラー識別子が返されます．

識別子の割り当てが失敗した場合，この関数は-1を返します．

@example
int myerror = lt_dladderror ("Doh!");
if (myerror < 0)
  perror (lt_dlerror ());
@end example
@end deftypefun

@deftypefun int lt_dlseterror (@w{int @var{errorcode}})
独自のモジュールローダを書くとき，@code{lt_dlerror}インターフェースを通
じて伝搬されるようにエラーを発生させるために，この関数を使用すべきです．
libltdlで使用される標準エラーの全ては，@file{ltdl.h}で宣言されていて，そ
うでなければ，@code{lt_dladderror}を用いて独自に書き加えることが可能です．

@example
if (lt_dlseterror (LTDL_ERROR_NO_MEMORY) != 0)
  perror (lt_dlerror ());
@end example
@end deftypefun


@node Distributing libltdl
@section パッケージとともにlibltdlを配布する方法

libltdlはlibtoolとともにインストールされるのですが，libtoolやlibltdlをイ
ンストールしていないパッケージユーザの利便性のため，パッケージの配布物に
libltdlを含めたいと思うかもしれません．この場合，手動でパッケージに加え
る@code{ltdl}オブジェクト，または，使用したいlibltdlの特色を決定する必要
があります．それは，便利なライブラリやインストール可能なlibtoolライブラ
リです．

@code{libltdl}をッケージに加える最も簡単な方法は，ソースファイルの
@file{ltdl.c}と@file{ltdl.h}をパッケージのソースディレクトリにコピーし，
ソースの残りと一緒にリンクすることです．これの手助けをするため，autoconf 
のm4マクロが@file{ltdl.m4}で利用可能です．autoconfを実行する前に，それら
が@file{aclocal.m4}で利用可能かどうかを確かめる必要があります --
automakeを使用している場合は@file{ltdl.m4}の内容を@file{acinclude.m4}に
加え，そうでない場合は@file{aclocal.m4}に加えます．マクロを利用可能にし
た後，@file{ltdl.o}を正しくビルドするために必要なコンフィグレーション時
の調査を実行するため，@samp{AC_LIB_LTDL}マクロの呼び出しを，パッケージの
@file{configure.in}に加える必要があります．インストールされているlibltdl 
やlibltdlに依存しているライブラリと，パケージのバイナリをリンクしようと
する場合，この手法には問題があります．シンボルの二重定義の問題があるかも
しれません．

便利なライブラリの利点の一つは，インストールされていないということなので，
libtoolを使用するという事実はユーザにとって明白ではなく，ユーザが以前に
インストールしているlibtoolのバージョンを上書きしません．一方，(例えば，
バグフィックスといった)理由があり，libltdlをアップグレードしたい場合，イ
ンストールされているバージョンのlibtoolを置き換える代わりに，パッケージ
を再コンパイルする必要があります．しかし，プログラムやライブラリが以前に
インストールされているバージョンのlibltdlを使用しているライブラリとリン
クする場合，リンカエラーが発生し実行時にクラッシュするかもしれません．も
う一つの問題は，一つ以上のlibtoolライブラリへ便利なライブラリをリンクで
きないことで，複製されたシンボルを得る可能性があるので，そのときは，これ
らのライブラリを用いた単一のプログラムとリンクしてください．一般的に，
libtoolを使用している他のライブラリに依存しないプログラムでは，便利なラ
イブラリを問題なく使用可能です．libltdlのこの特徴を利用可能にするため，
@samp{AC_LIBLTDL_CONVENIENCE}行を@file{configure.in}に，
@samp{AC_PROG_LIBTOOL}の@emph{前に}加えた方が良いでしょう．

インストール可能なバージョンのlibltdlを選択するために，マクロ
@samp{AC_LIBLTDL_INSTALLABLE}の呼び出しを@file{configure.in}に，
@samp{AC_PROG_LIBTOOL}の@emph{前に}加えた方が良いでしょう．このマクロは，
libltdlが既にインストールされているかどうか調査し，そうでない場合，ビル
ドしインストールされるパッケージlibltdlを埋め込むことを要求します．しか
し，バージョン調査は実行されないことに注意してください．ユーザは，コンフィ
グレーションスイッチ@samp{--enable-ltdl-install}を使用することで，他のバー
ジョンの存在に関係なく，テストを優先し，埋め込まれたlibtoolをインストー
ルする必要があるか決定することができます．

libtoolをパッケージに埋め込むため，@code{libtoolize}コマンドラインに
@samp{--ltdl}のみ加えてください．それで，パッケージのサブディレクトリ
@samp{libltdl}にlibtoolのソースをコピーします．どちらのマクロも，
@samp{libltdl}ディレクトリの位置を指定する追加の引数を受け入れます．デフォ
ルトで，どちらのマクロも@samp{$@{top_srcdir@}/libltdl}を仮定します．

どのマクロを使用しても，@file{configure.in}は@samp{AC_CONFIG_SUBDIRS}を
使用して，libltdlをコンフィグレーションし，@file{Makefile}が，例えば，
automakeの@var{SUBDIRS}を使用して，libtoolのディレクトリでサブmakeを開始
することを確実にするのはあなたです．どちらのマクロも，libltdlでリンクす
るために使用するリンクフラグのシェル変数@var{LIBLTDL}と，@file{ltdl.h}を
インクルードするプログラムをコンパイルするために使用するプリプロセッサフ
ラグ@var{INCLTDL}を定義します．この変数が@file{Makefile}で利用可能にする
ことを確実にするため@samp{AC_SUBST}を使用したり，デフォルトで
@samp{AC_SUBST}される，@var{LIBS}と@var{CPPFLAGS}のような変数に加えるの
はあなた次第です．

便利なlibltdlを使用している場合，@var{LIBLTDL}は便利なlibltdlのバージョ
ンに対するパス名で，@var{INCLTDL}はlibltdlを含むディレクトリが続く
@samp{-I}になり，どちらも@samp{$@{top_builddir@}/}，または，
@samp{$@{top_srcdir@}/}で，それぞれ始まります．

インストールされているlibltdlのバージョンを要求し，それが見つかった場合
@footnote{たとえ，libltdlがインストールされていても，libltdlがCライブラ
リ以外のライブラリが提供するシンボルに依存する場合，
@samp{AC_LIBLTDL_INSTALLABLE}は検出に失敗する可能性があります．この場合，
libltdlのビルドとインストールは不必要です．}，@var{LIBLTDL}は
@samp{-lltdl} に，@var{INCLTDL}は空に設定されます(それは，libltdlがライ
ブラリパスにある場合，@file{ltdl.h}がインクルードパスのどこかにあるとい
う，暗黙の仮定です)．インストール可能なlibltdlのバージョンをビルドする必
要がある場合，@samp{$@{top_builddir@}/}で始まるそのパス名は，
@var{LIBLTDL}に保存され，@var{INCLTDL}は便利なライブラリの場合と同様に設
定されます．

そのため，libltdlとプログラムをリンクしたいときは，それをインストールさ
れたまたはインストール可能な便利なライブラリにし，すなわち，libtoolを使
用して，@samp{$(INCLTDL)}を用いてコンパイルし，@samp{$(LIBLTDL)}を用いて
リンクしてください．

おそらく@samp{AC_LIBTOOL_DLOPEN}も@file{configure.in}に，
@samp{AC_PROG_LIBTOOL}の@emph{前に}加えた方が良く，そうしない場合は，
libtoolはdlopenメカニズムがサポートされていないと仮定し，おそらく希望し
ていないdlpreopenに逆戻りします．

libltdlとプログラムをリンクするとき，@code{-static}や@code{-all-static} 
スイッチの使用を避けてください．dlopen関数はスタティックリンクに対して利
用可能でない可能性があるので，これはすべてのプラットフォームで動作するわ
けではありません．

以下の例は，パッケージに便利なlibltdlを埋め込む方法を示します．インストー
ル可能な形態を使用するために，@samp{AC_LIBLTDL_CONVENIENCE}を
@samp{AC_LIBLTDL_INSTALLABLE}で置換してください．我々は，libltdlが
@samp{libtoolize --ltdl}を使用して埋め込まれていると仮定しています．

configure.inは以下のようになります．
@example
...
dnl Enable building of the convenience library
dnl and set LIBLTDL accordingly
AC_LIBLTDL_CONVENIENCE
dnl Substitute INCLTDL and LIBLTDL in the Makefiles
AC_SUBST(INCLTDL)
AC_SUBST(LIBLTDL)
dnl Check for dlopen support
AC_LIBTOOL_DLOPEN
dnl Configure libtool
AC_PROG_LIBTOOL
dnl Configure libltdl
AC_CONFIG_SUBDIRS(libltdl)
...
@end example

Makefile.amは以下のようになります．
@example
...
SUBDIRS = libltdl

INCLUDES = $(INCLTDL)

myprog_LDFLAGS = -export-dynamic
# The quotes around -dlopen below fool automake <= 1.4 into accepting it
myprog_LDADD = $(LIBLTDL) "-dlopen" self "-dlopen" foo1.la
myprog_DEPENDENCIES = $(LIBLTDL) foo1.la
...
@end example


@node Other languages
@chapter 他の言語でlibtoolを使用する
@cindex C, not using
@cindex languages, non-C
@cindex C++, using

libtoolは最初に，C言語での共有ライブラリを書くことに対するサポートを加え
るために実装されました．しかし，時間が経ち，プログラマが好みのプログラム
言語での共有ライブラリの便利さを自由に得られるように，libtoolは他の言語
と統合されています．

この章は，libtoolが他の言語と相互作用する方法と，Cを用いない場合に必要と
される特記事項を記述します．

@menu
* C++ libraries::
@end menu

@node C++ libraries
@section C++に対するライブラリを書く
@c FIXME: in the TOC, the ++ is too large (seems to be math mode)
@cindex trouble with C++
@cindex pitfalls using C++
@cindex C++, pitfalls

C++コードのライブラリを作成することは，そのオブジェクトファイルがCのもの
と３つの点で異なっているだけので，かなり簡単な処理になります．

@enumerate 1
@item
名前をmangleするため，C++ライブラリはC++コンパイラで作成されたものだけ利
用可能です．この決定は，コンストラクタ，例外処理，そしてRTTIのような機能
の実装との衝突からユーザを守るため，C++の設計者によってなされました．

@item
システムによっては，ダイナミックリンカが動的(すなわち実行時)に初期化の実
行するため，C++コンパイラは特別な動作を行なう必要があります．これは，そ
のようなライブラリとリンクするため，@file{ld}を直接呼び出すべきではなく，
その代わりにC++コンパイラを使用するべきだということを意味します．

@item
C++コンパイラは，いくつかの標準C++ライブラリとデフォルトでリンクしますが，
libtoolは，これらのライブラリがどれかを知らないため，それに対してリンク
する方法を調査するため，ライブラリ内部の依存の解析さえ実行できません．そ
れゆえ，C++プログラムやライブラリとリンクするため@file{ld}を実行すると失
敗すると思われます．しかし，C++コンパイラを直接実行することは，ライブラ
リ内部の依存に関係する問題を生じる可能性があります．
@end enumerate

結論として，libtoolはC++ライブラリに対する一般的な使用のための準備ができ
ていません．標準Cコンパイラでコンパイルする場合は，``初期化要素は一定で
はない''というエラーの原因となる，あらゆるグローバルまたはスタティック変
数の初期化を避けるべきです．

この問題に関して動作する他の方法もありますが，それらはこのマニュアルの範
囲を越えています．

さらに，C++コンパイラがデフォルトでリンクするC++標準ライブラリと，リンク
コマンドラインの明示的なリストは，コンフィグレーション時に分かった方が良
いでしょう．たぶん将来，libtoolはこの仕事を単独で可能となるでしょう．


@node Troubleshooting
@chapter トラブルシューティング
@cindex troubleshooting
@cindex problems, solving
@cindex solving problems
@cindex problems, blaming somebody else for

libtoolは，現在のオペレーティングシステムで最新を保つよう変更しながら，
コンスタントに開発されていています．libtoolがプラットフォーム上で思った
ように動作しない場合，問題点と解決方法を決定する助けとなる，この章を読ん
だ方が良いでしょう．

@menu
* Libtool test suite::          Libtool's self-tests.
* Reporting bugs::              How to report problems with libtool.
@end menu

@node Libtool test suite
@section libtoolのテストスイート
@cindex test suite

libtoolは，その能力をテストし，libtoolプログラムの明らかなバグを報告する，
プログラムの独自のセットとともにあります．これらのテストは，libtoolの過
去の問題と他のオペレーティングシステム内の既知の欠陥を基にして，絶えず進
化もしています．

@file{INSTALL}ファイルに記述されているように，libtoolのビルド後，基本的
な機能要求に合っていることを確めるために，@kbd{make check}を実行すること
が可能です．

@menu
* Test descriptions::           The contents of the test suite.
* When tests fail::             What to do when a test fails.
@end menu

@node Test descriptions
@subsection テストスイートの記述

テストスイートの現在のプログラムと，それらがテストするもののリストは以下
のようになっています．

@table @file

@item cdemo-conf.test
@itemx cdemo-exec.test
@itemx cdemo-make.test
@itemx cdemo-static.test
@itemx cdemo-shared.test
@pindex cdemo-conf.test
@pindex cdemo-exec.test
@pindex cdemo-make.test
@pindex cdemo-static.test
@pindex cdemo-shared.test
これらのプログラムは，libtool配布物の@file{cdemo}サブディレクトリが，正
しくコンフィグレーションされ，ビルドされることを知るために調査します．

@file{cdemo}サブディレクトリは，libtoolの便利なライブラリのデモンストレー
ションと，ビルド時にスタティックライブラリの作成を可能とするメカニズムを
含んでいて，コンポーネントが共有ライブラリであったとしても，プログラムや
他のライブラリと遅れてリンクされることを可能とする方法です．

@file{cdemo-make.test}と@file{cdemo-exec.test}のテストは，３つの異なる
libtoolコンフィグレーションで，３回実行されます．@file{cdemo-conf.test} 
は，スタティックライブラリと共有ライブラリの両方をビルドするために(両方
サポートしているプラットフォームではデフォルトです)@file{cdemo/libtool} 
をコンフィグレーションし，@file{cdemo-static.test}はスタティックライブラ
リのみビルドし(@samp{--disable-shared})，そして@file{cdemo-shared.test} 
は共有ライブラリのみビルドします(@samp{--disable-static})．

@item demo-conf.test
@itemx demo-exec.test
@itemx demo-inst.test
@itemx demo-make.test
@itemx demo-unst.test
@itemx demo-static.test
@itemx demo-shared.test
@itemx demo-nofast.test
@itemx demo-pic.test
@itemx demo-nopic.test
@pindex demo-conf.test
@pindex demo-exec.test
@pindex demo-inst.test
@pindex demo-make.test
@pindex demo-unst.test
@pindex demo-static.test
@pindex demo-shared.test
@pindex demo-nofast.test
@pindex demo-pic.test
@pindex demo-nopic.test
これらのプログラムは，libtool配布物の@file{demo}サブディレクトリが，コン
フィグレーション，ビルド，インストール，そしてアンインストールが正しくで
きることを知るために調査します．

@file{demo}サブディレクトリは，libtoolを使用する平凡なパッケージのデモン
ストレーションを含みます．テストの@file{demo-make.test}，
@file{demo-exec.test}，@file{demo-inst.test}，そして
@file{demo-unst.test}は，４つの異なるlibtoolのコンフィグレーションの下で，
４回実行されます．@file{demo-conf.test}は，スタティックと共有の両方のラ
イブラリをビルドするために@file{demo/libtool}をコンフィグレーションし，
@file{demo-static.test}は，スタティックライブラリのみビルドし
(@samp{--disable-shared})，そして@file{demo-shared.test}は，共有ライブラ
リのみをビルドします(@samp{--disable-static})．@file{demo-nofast.test}は，
高速インストールモードを使用禁止にするために
(@samp{--enable-fast-install=no})，@file{demo/libtool}をコンフィグレーショ
ンします．@file{demo-pic.test}は，PICコードをビルドしたいときは
(@samp{--with-pic})，非PICコードをビルドしたいときは
(@samp{--without-pic}) にするように，@file{demo/libtool}をコンフィグレー
ションします．

@item deplibs.test
@pindex deplibs.test
スタティックライブラリを共有ライブラリにリンク不可能なシステムもたくさん
あります．そのような場合を避けるため，libtoolは
@code{deplibs_check_method}を使用します．このテストは，libtoolの
@code{deplibs_check_method}が正しく動作するかどうか調査します．

@item hardcode.test
@pindex hardcode.test
共有ライブラリを持つすべてのシステムで，実行形式に対しリンクされるライブ
ラリの位置が実行形式の内部に符号化されるはずです@pxref{Linking
executables}．このテストは，システムリンカがライブラリの位置をハードコー
ドし，libtool自身のリンカの動作方法の概念と一致することを保証する条件を
調査します．

@item build-relink.test
@pindex build-relink.test
変数@var{shlibpath_overrides_runpath}が正しく設定されているかどうか調査
します．テストが失敗し，@var{VERBOSE}が設定されている場合，それは変数を
設定する必要がないことを示します．

@item noinst-link.test
@pindex noinst-link.test
libtoolが，たった今ビルドされたライブラリにリンクする方が良い時，以前に
インストールされているバージョンにリンクしようとしないかどうか調査します．

@item depdemo-conf.test
@itemx depdemo-exec.test
@itemx depdemo-inst.test
@itemx depdemo-make.test
@itemx depdemo-unst.test
@itemx depdemo-static.test
@itemx depdemo-shared.test
@itemx depdemo-nofast.test
@pindex depdemo-conf.test
@pindex depdemo-exec.test
@pindex depdemo-inst.test
@pindex depdemo-make.test
@pindex depdemo-unst.test
@pindex depdemo-static.test
@pindex depdemo-shared.test
@pindex depdemo-nofast.test
これらのプログラムは，libtool配布物の@file{depdemo}サブディレクトリの，
コンフィグレーション，ビルド，インストール，そしてアンインストールを，正
しく行えることを判定するための調査を行います．

@file{depdemo}サブディレクトリは，libtoolに依存する内部ライブラリのデモ
ンストレーションを含みます．このテストプログラムは，いくつかの交互依存し
ているライブラリをリンクします．

テストの，@file{depdemo-make.test}，@file{depdemo-exec.test}，
@file{depdemo-inst.test}，そして@file{depdemo-unst.test}は，４つの異なる
libtoolのコンフィグレーションの下で，４回実行されます．
@file{depdemo-conf.test}は，スタティックと共有の両方のライブラリをビルド
するために，@file{depdemo/libtool}をコンフィグレーションし，
@file{depdemo-static.test}はスタティックライブラリのみビルドし
(@samp{--disable-shared})，@file{depdemo-shared.test}は共有ライブラリの
みビルドします(@samp{--disable-static})．@file{depdemo-nofast.test}は高
速インストールモード(@samp{--enable-fast-install=no})を利用不可能にする
ために，@file{depdemo/libtool}をコンフィグレーションします．

@item mdemo-conf.test
@itemx mdemo-exec.test
@itemx mdemo-inst.test
@itemx mdemo-make.test
@itemx mdemo-unst.test
@itemx mdemo-static.test
@itemx mdemo-shared.test
@pindex mdemo-conf.test
@pindex mdemo-exec.test
@pindex mdemo-inst.test
@pindex mdemo-make.test
@pindex mdemo-unst.test
@pindex mdemo-static.test
@pindex mdemo-shared.test
これらのプログラムは，libtool配布物の@file{mdemo}サブディレクトリが，コ
ンフィグレーション，ビルド，インストール，そしてアンインストールが正しく
できることを知るために調査します．

@file{mdemo}サブディレクトリは，libtoolと，システム非依存のモジュールロー
ドのための，dlopenラッパー@file{libltdl}を使用するパッケージのデモンスト
レーションを含みます．ライブラリ@file{libltdl}は，様々なプラットフォーム
(Linux，Solaris，HP/UX等)に対する，dlpreopenモジュールに対するサポートを
含む(@pxref{Dlpreopening})dlopenラッパーを提供します．

テストの@file{mdemo-make.test}，@file{mdemo-exec.test}，
@file{mdemo-inst.test}，そして@file{mdemo-unst.test}は，３つの異なる
libtoolのコンフィグレーションの下で，３回実行されます．
@file{mdemo-conf.test}は，スタティックと共有の両方のライブラリをビルドす
るために@file{mdemo/libtool}をコンフィグレーションし，
@file{mdemo-static.test}は，スタティックライブラリのみビルドし
(@samp{--disable-shared})，そして@file{mdemo-shared.test}は，共有ライブ
ラリのみをビルドします(@samp{--disable-static})．

@item dryrun.test
@pindex dryrun.test
このテストは，libtoolの@code{--dry-run}モードが正しく働くかどうかを調査
します．

@item assign.test
@pindex assign.test
libtoolスクリプト内の割り当てられている同じ行で，停止したり，続けたりし
ないかどうか調査します．

@item link.test
@pindex link.test
このテストは，libtoolでないスタティックライブラリに対する直接的なリンク
が正しく動作することを保証します．

@item link-2.test
@pindex link-2.test
このテストは，@samp{.lo}で終わるファイルがプログラムファイルに直接リンク
されないことを確かめます．

@item nomode.test
@pindex nomode.test
実際にlibtoolの助けが可能かどうか調査します．

@item quote.test
@pindex quote.test
このプログラムはlibtoolのメタ文字を引用符で囲むことを調査します．

@item sh.test
@pindex sh.test
`test'コマンドがlibtoolに忘れていないか調査します．

@item suffix.test
@pindex suffix.test
他のプログラミング言語がlibtoolで使用されるとき(@pxref{Other languages})，
ソースファイルは@samp{.c}以外の接尾子で終わるかもしれません．このテスト
は，サポートするすべてのファイル形式に対する接尾子を扱うこと可能で，接尾
子が不当なときは失敗することを確認します．

@end table

@node When tests fail
@subsection テストが失敗するとき
@cindex failed tests
@cindex tests, failed

上記のそれぞれのテストは，@kbd{make check}を実行するとき出力を生成しない
ように設計されています．それぞれのプログラムの終了ステータスで，テストが
成功しなかったかどうかを@file{Makefile}に伝えます．

テストが失敗した場合，それはlibtool内のプログラムエラー，またはプログラ
ム自身のエラーのどちらかが存在することを意味します．

特定のテストを調査するために，通常のプログラムで行うように，直接実行する
ことが可能です．テストがこの方法で呼び出されたとき，それは，問題を決定す
るのに役に立ちそうな出力を生成します．

テストプログラムに出力を生成させるもうひとつの方法は，実行前に
@var{VERBOSE}環境変数を@samp{yes}に設定することです．例えば，@kbd{env
VERBOSE=yes make check}ですべてのテストが実行され，それぞれについてデバッ
グ情報の表示が得られます．


@node Reporting bugs
@section バグの報告
@cindex bug reports
@cindex reporting bugs
@cindex problem reports

libtoolにバグを発見したと考えた場合，もう一度考えた直したほうが良いでしょ
う．libtool管理者は，責任転嫁(または``バグを通過させる''かもしれません)
で有名です@footnote{訳注：原文では，passing the buck(責任転嫁)とpassing
the bug(バグを通過させる)をかけています}．libtoolは，共有ライブラリの実
装で既知の欠陥を修正するために開発されたので，libtoolのバグのほとんどは，
ある程度は，他のオペレーティングシステムのバグになります．しかし，
libtool の管理者は，他人のバギーなオペレーティングシステムに対するサポー
トを加えることを，確かに楽しんでいます．[Texinfoでウインクしている笑顔を
表示する，いい方法があれば良いのですが．]

libtoolの純粋なバグは，シェルスクリプトの移植性の問題，ドキュメントのエ
ラー，そしてテストスイートの失敗(@pxref{Libtool test suite})を含みます．

最初に，問題と考えられる動作が，既に特徴として言及されていないことを確か
めるために，ドキュメントとへルプ画面を調査してください．

そして，バグを報告することに関するEmacsガイド(@pxref{Bugs, , Reporting
Bugs, emacs, The Emacs Manual})を読んでください．リストアップされている
詳細は，Emacs特有のものもありますが，基本的な原則は一般的なものです．

最後に，テストスイートの出力(@pxref{When tests fail})，バグを再生成する
のに必要なすべての詳細，そして，動作がバグだと考えられる理由の概要のよう
な適切なあらゆる@emph{事実}とともに，@value{BUGADDR}にバグの報告を送って
ください．サブジェクト行に，単語``libtool''と，同様に使用しているバージョ
ンナンバー(それは，@kbd{ltconfig --version}の入力で分かります)が含まれて
いることを確認してください．


@node Maintaining
@chapter libtoolの管理用メモ

この章は，libtool管理者が見つける重要な情報を含みます．新しいシステムへ
の移植や，独自のlibtoolを書くことを考慮しない場合，役に立たないでしょう．

@menu
* New ports::                   How to port libtool to new systems.
* Tested platforms::            When libtool was last tested.
* Platform quirks::             Information about different library systems.
* libtool script contents::     Configuration information that libtool uses.
* Cheap tricks::                Making libtool maintainership easier.
@end menu

@node New ports
@section 新しいシステムへのlibtoolの移植

サポートされていないシステムへのlibtoolの移植に乗り出す前に，既存の仕事
と重複していないことを確認するために，@value{MAILLIST}に電子メールを送る
価値はあります．

移植の文章が見つからない場合，文句を言ってください！ パッチを用いた苦情
と，ドキュメントやlibtool自身の改良は十分に歓迎されます．

@menu
* Information sources::         Where to find relevant documentation
* Porting inter-library dependencies::  Implementation details explained
@end menu

@node Information sources
@subsection 情報源

新たな移植の必要性が明らかになると，通常，以下の情報が必要となります．

@table @asis
@item 標準的なシステム名
他のシステムに影響しないようにlibtoolのコンフィグレーション処理を変更可
能にするため，このシステムに対する@code{config.guess}の出力が必要です．

@item @code{ld}と@code{cc}に対するmanページ
共有ライブラリを作成するため，共有ライブラリのみにリンクするため，そして，
PICを生成するために使用するフラグを，通常これらは記述しています．必要な
情報を見つけるため，以下の相互参照が必要かもしれません．

@item @code{ld.so}，@code{rtld}，または，その同等物のmanページ
これらは，システムで共有ライブラリがロードされる仕組みを理解するための，
有益な情報源です．

@item @code{ldconfig}やその同等物のmanページ
このページは，通常，共有ライブラリをインストールする方法を記述します．

@item @kbd{ls -l /lib /usr/lib}の出力
これは，システムの共有ライブラリの命名規則を表示し，それは，シンボリック
リンクの名前も含んでいます．

@item あらゆる追加の文章
共有ライブラリの構築とインストール方法の特別な文章があるシステムもありま
す．
@end table

Bourneシェルプログラムの方法を知っている場合，完全に自分で移植することが
可能です．それ以外の場合，関連する作業を行う腕のある人を探す必要がありま
す．libtoolメーリングリストの人々は，新たな移植への援助を志願する意思が
あるので，彼らに情報を送ることができます．

独自に移植するためには，プラットフォーム特有のコンフィグレーションプロセ
スの変更を行うため，@code{libtool.m4}マクロを明確に修正する必要がありま
す．@code{PORTME}キーワードに対するファイルを検索する必要があり，それで，
変更に必要なヒントを得られるでしょう．一般的に，呼び出されるものは，適切
なコンフィグレーション変数の編集です(@pxref{libtool script contents})．

最善策は，既にサポートされている良く似たシステムを見つけ，変更の基本とす
ることです．しかし，システムが他のサポートされているシステムと，大きく異
なる場合や，新しいコンフィグレーション変数を加え，それに応じて
@code{ltmain.in}スクリプトを変更する必要がある場合もあります．欲しいもの
を達成するための，最も効果的な方法の助言がある可能性があるので，
@code{ltmain.in}を変更する前に，メーリングリストに書いて確認してください．


@node Porting inter-library dependencies
@subsection ライブラリ内部の依存性のサポートの移植
@cindex inter-library dependency
@vindex deplibs_check_method

バージョン1.2c以降，libtoolは，Toshio Kuratomi
@email{badger@@prtr-13.ucsc.edu}のパッチのおかげで，ライブラリ内部の依存
性を可能とする機能が再導入されてるプラットフォームもあります．パッチに含
まれるメッセージの短いバージョンは以下のようになります．

基本的な体系はこのようになります．@file{libtool.m4}で，libtoolを書いてい
る人は，@samp{$deplibs}が@samp{$archive_cmds}のどこかに含まれていること，
また，変数@samp{$deplibs_check_method}と，@samp{deplibs_check_method}が
ファイルマジックの場合は@samp{$file_magic_cmd}が設定されていることを確認
します．

@samp{deplibs_check_method}は，以下の５つの内の一つのはずです．
@table @samp
@item file_magic [@var{regex}]
@vindex file_magic
@vindex file_magic_cmd
@vindex file_magic_test_file
ライブラリリンクパスで正しいlibnameを持つライブラリを探します．そして，
ライブラリで@samp{$file_magic_cmd}を実行し，@code{egrep}を使用した
@var{regex}に一致することを調査します．@var{file_magic_test_file}が
@file{libtool.m4}によって設定されているとき，正規表現がその出力と一致す
るかどうかを検証し，それ以外ではユーザが警告を受けるようにするため，それ
は@samp{$file_magic_cmd}への引数として使用されます．

@item test_compile
@vindex test_compile
ライブラリリストの出力以外とプログラムがリンク可能かどうかのみを調査し，
それらが@code{ldd}の出力でリストアップされていることを調査します．それは
現在，使用されておらず，将来は打ち切る可能性があります．

@item pass_all
@vindex pass_all
調査せず，すべて通過します．例えばDEC OSF/1 3 と 4のような，デフォルトで，
コードが位置に依存せず，ライブラリ内部の依存性がダイナミックリンカで適切
にサポートされているプラットフォームで，これは動作するでしょう．

@item none
@vindex none
deplibsをdeplibs=""に再設定します．そのように，@samp{archive_cmds}は，す
べてのプラットフォームでdeplibsを含むはずですが，deplibは必要がなければ
使用されません．

@item unknown
@vindex unknown
@file{libtool.m4}で優先されない場合，すべてのシステムでデフォルトです．
それは@samp{none}と同じですが，正しい値が何か，我々が本当に知らないこと
を文章化していて，我々はそれを改善するパッチを歓迎します．
@end table

@file{ltmain.in}で，我々は本当に一生懸命作業しました．それは，
(libname_spec等の評価を使用するための変数を設定/リリース行う)小さな初期
化と移植，そして使用するメソッドを決定するケース文です．これは，実際には
コードです...  もう少し凝縮できれば良かったのですが，関数呼び出しを用い
ずにできるとは思えませんでした．私はほとんどの(ループの外に出す等の)最適
化を行いましたが，余分なものがあるかもしれません．明確な最適化を考える前
に，前進を止め，発見されたバグに対して作業すべきだと考えました．


@node Tested platforms
@section テストされたプラットフォーム

この表は，共有ライブラリのサポートを謡っているプラットフォームで，
libtoolがテストされたことが分かっている最後の時期を記述しています．

@example
@include PLATFORMS-ja
@end example

注：ベンダー配布されているHP-UXの@code{sed}(1)プログラムは，ひどく壊れて
いて，libtoolの要求を処理することができないため，ユーザは異常の問題を報
告する可能性があります．これらのシステムで動作する(GNU @code{sed})のよう
な@code{sed}をインストールする以外に，回避方法はありません．

注：ベンダー配布されているNCR MP-RAS @code{cc}プログラムは，標準エラーに
著作権を出力し，@file{conftest.err}の大きさのテストで混乱します．回避方
法は，@code{configure}を実行するとき，@kbd{CC='cc -Hnocopyr'}を用いて
@code{CC} を指定します．


@node Platform quirks
@section プラットフォームの癖

このセクションは，libtoolの管理者の健康に捧げます．それは，libtoolが使用
するプログラム，システムごとの違い，そしてテストの方法を記述します．

libtoolはシェルスクリプトなので，最初から最後まで読むだけで理解すること
は難しいはずです．このセクションは，libtoolが特定の方法で行う理由の理解
を助けます．スクリプト自身が組み合わされているので，libtoolの改善や，独
自に書く方法の，より良いセンスが必要でしょう．

@menu
* References::                  Finding more information.
* Compilers::                   Creating object files from source files.
* Reloadable objects::          Binding object files together.
* Multiple dependencies::	Removing duplicate dependant libraries.
* Archivers::                   Programs that create static archives.
@end menu

@node References
@subsection リファレンス

以下は，価値のある文章の参照リストです．

@itemize @bullet
@item
SGIのIRIXのマニュアルページで，それは
@url{http://techpubs.sgi.com/cgi-bin/infosrch.cgi?cmd=browse&db=man}で見
つかります．

@item
Sunのフリーサービス領域
(@url{http://www.sun.com/service/online/free.html})とドキュメントサーバ
(@url{http://docs.sun.com/})．

@item
CompaqのTru64 UNIXオンラインドキュメントは
(@url{http://tru64unix.compaq.com/faqs/publications/pub_page/doc_list.html}) 
にあり，C++ドキュメントは
(@url{http://tru64unix.compaq.com/cplus/docs/index.htm})です．

@item
Hewlett-Packardは(@url{http://docs.hp.com/index.html})にオンラインドキュ
メントがあります．

@item
IBMは(@url{http://www.rs6000.ibm.com/resource/aix_resource/Pubs/})にオン
ラインドキュメントがあります．
@end itemize


@node Compilers
@subsection コンパイラ

libtoolに影響するコンパイラの特徴は，PICオブジェクトを生成するための(存
在する場合は)必要なフラグのみです．一般的に，Cコンパイラが特定のPICフラ
グをサポートする場合，あらゆる派生的なコンパイラは同じフラグをサポートし
ます．この規則に対し，注目すべき若干の例外があるまでは，このセクションで
はCコンパイラのみを説明します．

プラットフォームに関係なく，以下のCコンパイラは，標準のコマンドライオプ
ションがあります．

@table @code
@item gcc

これはGNU Cコンパイラで，多くのフリーオペレーティングシステム(少し例をあ
げると，FreeBSD，GNU/Hurd，GNU/Linux，Lites，NetBSD，そしてOpenBSDです)
に対する，システムコンパイラでもあります．

@samp{-fpic}や@samp{-fPIC}フラグは，位置に依存しないコードを生成するため
に使用可能です．@samp{-fPIC}は動作するコードを生成することを保証しますが，
m68k，m88k，そしてSparcチップ上ではコードは遅くなります．しかし，これら
のチップで@samp{-fpic}を使用すると，共有ライブラリでの自由なサイズが強制
的に制限されます．
@end table

このサブセクションの残りは，バンドルされているオペレーティングシステムの
コンパイラをリストアップします．

@c FIXME these should all be better-documented

@table @code
@item aix3*
@itemx aix4*
AIXはPowerPCとRS/6000チップのみに移植されているので，AIXコンパイラはPIC 
フラグはありません．@footnote{PowerPCとRS/6000チップ(@code{powerpc-*-*}，
@code{powerpcle-*-*}，そして@code{rs6000-*-*})に対しコンパイルされている
すべてのコードは，オペレーティングシステムやコンパイラスイートに関係なく
位置に依存しません．そのため，``標準オブジェクト''はこれらのシステムの共
有ライブラリの構築で使用され，特別なPICコンパイラフラグは要求されません．}

@item hpux10*
PICを生成するために@samp{+Z}を使用してください

@item osf3*
Digital/UNIX 3.xは，少なくともPowerPCプラットフォームでなければ，PICフラ
グはありません．

@item solaris2*
PICを生成するために@samp{-KPIC}を使用してください．

@item sunos4*
PICを生成するために@samp{-PIC}を使用してください．
@end table


@node Reloadable objects
@subsection リロード可能なオブジェクト

すべての既知のシステム上で，リロード可能なオブジェクトは@kbd{ld -r -o
@var{output}.o @var{input1}.o @var{input2}.o}を実行することで生成可能で
す．このリロード可能なオブジェクトは，他のオブジェクトと完全な同義語とし
て扱うことが可能です．


@node Multiple dependencies
@subsection 複数の依存性

ほとんどの近代的なプラットフォームでは，依存するライブラリがリストアップ
される順序はオブジェクトの生成で影響がありません．理論上，シンボルを提供
しているライブラリの後に，リストアップされている他のライブラリに足りない
シンボルを提供するライブラリを要求するプラットフォームがあります．

特に，一組のスタティックアーカイブのそれぞれが，他のシンボルのいくつかを
解決する場合，それらのアーカイブの前後両方に他のものをリストアップするこ
とが必要かもしれません．複製されたライブラリはリンク行から削除されるので，
libtoolは，現在この状況に十分に対処していません．

正しくリンクされたオブジェクトを生成するために，ライブラリを複数回リスト
アップすることを要求するホストで開発していることが分かった場合，以下のよ
うにして，libtoolの除去アルゴリズムを無効にすることが可能です．

@example
$ libtool ... -lfoo -lbar -Wl,-lfoo
@end example


@node Archivers
@subsection アーカイバ

すべての既知のシステム上で，スタティックライブラリのビルドは，@kbd{ar
cru lib@var{name}.a @var{obj1}.o @var{obj2}.o @dots{}}の実行で完成するは
ずで，そこでは，@samp{.a}ファイルは出力ライブラリで，それぞれの@samp{.o}
ファイルはオブジェクトファイルです．

すべての既知のシステム上で，@code{ranlib}という名のプログラムがある場合，
リンクする前に@kbd{ranlib lib@var{name}.a}コマンドを用いて，作成されるラ
イブラリを``祝福''するために使用する必要があります．Irixのように，代わり
に@code{ar ts}を使用するシステムもあります．


@node libtool script contents
@section @code{libtool}スクリプトの内容
@cindex implementation of libtool
@cindex libtool implementation

バージョン1.4からは，@code{libtool}スクリプトは@code{configure}によって
生成されます(@pxref{Configuring}．以前のバージョンでは，@file{ltconfig} 
と呼ばれるへルパースクリプトを呼び出すことで，@code{configure}はそれを達
成していました．libtoolのバージョン0.7から1.0までは，このスクリプトは，
単純にシェル変数を設定し，libtoolのバックエンドの@code{ltmain.sh}の源と
なっていました．libtoolバージョン1.1から1.3までの@code{ltconfig}は，
@code{ltmain.sh}の内容を，生成された@code{libtool}にインライン化し，それ
は多くのシステムでパフォーマンスを改善しました．@file{ltconfig}が実行す
るために使用するテストは，現在@file{libtool.m4}にあり，そこで我々は
Autoconfを使用して書くことが可能となっています．これは，インライン化され
た@code{ltmain.sh}の実行時の動作に有利で，@emph{そして}，管理が必要な生
のシェルコードの量をかなり取り除くことで，構築時間を短くする改善を行いま
した．

後で評価するもの対するシェルコマンドを保持する変数の命名に使用される規則
は，有効な単一行のシェルスクリプトが必要とされるところで接尾子
@code{_cmd}，複数行のシェルスクリプトが後で評価することが@strong{可能な} 
ところで接尾子@code{_cmds}を使用することです．規則では，@code{_cmds}変数
は，必要なところで，@code{~}文字で評価ユニットを区切ります．

それぞれのコンフィグレーション変数と，@code{ltmain.sh}で使用する方法のリ
ストは，以下のようになります(@pxref{Configuring})．

@defvar AR
システムライブラリアーカイバの名前です．
@end defvar

@defvar CC
libtoolをコンフィグレーションするために使用するCコンパイラの名前です．
@end defvar

@defvar LD
リロード可能にするリンクとおそらく共有ライブラリに対し，libtoolが内部で
使用するリンカの名前です．
@end defvar

@defvar NM
BSD互換の@code{nm}プログラムの名前で，それは以下の書式の一つで，大域的な
シンボルを生成します．

@example
@var{address} C @var{global-variable-name}
@var{address} D @var{global-variable-name}
@var{address} T @var{global-function-name}
@end example
@end defvar

@defvar RANLIB
存在する場合，ranlibプログラムの名前を設定します．
@end defvar

@defvar allow_undefined_flag
結果として生じる共有ライブラリに，未解決のシンボルがあることを宣言するた
めに，@samp{archive_cmds}で使用されるフラグです．そのようなフラグが不要
な場合は空です．ライブラリで定義されていないシンボルを参照して，共有ライ
ブラリを生成する方法がない場合，@samp{unsupported}を設定します．
@end defvar

@defvar always_export_symbols
アーカイブとリンクする前に，@var{export_symbols_cmds}を使用してエクスポー
トされるシンボルのリストを，libtoolが自動的に生成するかどうかです．
@samp{yes}または@samp{no}に設定します．デフォルトは@samp{no}です．
@end defvar

@defvar archive_cmds
@defvarx archive_expsym_cmds
@defvarx old_archive_cmds
それぞれ，共有ライブラリ，@samp{-export-symbols}を用いた共有ライブラリ，
そしてスタティックライブラリを生成するために使用するコマンドです．
@end defvar

@defvar old_archive_from_new_cmds
共有ライブラリがスタティックライブラリに依存する場合，
@samp{old_archive_from_new_cmds}はスタティックライブラリを生成するために
使用するコマンドを含みます．この変数が空の場合，@samp{old_archive_cmds}
は使用されません．
@end defvar

@defvar old_archive_from_expsyms_cmds
スタティックライブラリが，共有ライブラリで正しくリンクするために，エクス
ポートシンボルリストから作成される必要がある場合，
@samp{old_archive_from_expsyms_cmds}は，そのスタティックライブラリを作成
するために必要なコマンドを含みます．これらのコマンドが実行されるとき，変
数@var{soname}は，共有ライブラリの名前を疑問符の中に含み，
@var{$objdir/$newlib}は，これらのコマンドがビルドする静的ライブラリのパ
スを含みます．これらのコマンドを実行した後，libtoolは，@var{soname}の代
わりに@var{$objdir/$newlib}に対してリンクするための処理を行います．
@end defvar

@defvar build_libtool_libs
このシステムで，libtoolが共有ライブラリをビルドできるかどうかです．
@samp{yes}または@samp{no}に設定します．
@end defvar

@defvar build_old_libs
このシステムで，libtoolがスタティックライブラリをビルドできるかどうかで
す．@samp{yes}または@samp{no}に設定します．
@end defvar

@defvar compiler_c_o
コンパイラが，同時に@code{-c}と@code{-o}オプションをサポートするかどうか
です．@samp{yes}または@samp{no}に設定します．
@end defvar

@defvar compiler_o_lo
コンパイラが，直接".lo"ファイルへのコンパイルをサポートするかどうかで，
例えば，オブジェクトファイルが，接尾子".o"を持つ必要があるかどうかです．
@samp{yes}または@samp{no}に設定します．
@end defvar

@defvar dlopen_support
プラットフォームで，@code{dlopen}をサポートするかどうかです．@samp{yes} 
または@samp{no}に設定します．
@end defvar

@defvar dlopen_self
実行形式自身が@code{dlopen}可能かどうかです．@samp{yes}または@samp{no} 
に設定します．
@end defvar

@defvar dlopen_self_static
静的にリンクされているとき(@samp{-all-static})，実行形式自身が
@code{dlopen}可能かどうかです．@samp{yes}または@samp{no}に設定します．
@end defvar

@defvar echo
バックスラッシュをエスケープ文字と解釈しない@code{echo}プログラムです．
@end defvar

@defvar exclude_expsyms
プリリードされているシンボルにリストアップされないシンボルのリストです．
@end defvar

@defvar export_dynamic_flag_spec
dlopenされる共有ライブラリが，プログラムで定義されているシンボルへの参照
を可能にするコンパイラリンクフラグです．
@end defvar

@defvar export_symbols_cmds
@var{libobjs}からファイル@var{export_symbols}へエクスポートされたシンボ
ルを抽出するコマンドです．
@end defvar

@defvar extract_expsyms_cmds
共有ライブラリからエクスポートされたシンボルリストを抽出するコマンドです．
これらのコマンドは，ファイル@var{$objdir/$soname-def}が無い場合に実行さ
れ，@samp{old_archive_from_expsyms_cmds}が使用するため，エクスポートされ
たシンボル名をそのファイルに書き出します．
@end defvar

@defvar fast_install
libtoolが特権を与える人を，インストール者または開発者のどちらかに決定し
ます．インストール者がビルドツリーでプログラムを実行することは滅多になく，
開発者は滅多にインストールしないしないと仮定します．これは，
@var{shlibpath_overrides_runpath}が@samp{yes}でないプラットフォーム上で
のみ意味があるので，この場合，@var{fast_install}は@samp{needless}設定さ
れます．@var{fast_install}が@samp{yes}に設定される場合，libtoolはインス
トールされたライブラリを検索するプログラムを作成し，プログラムがビルドツ
リーで実行される場合，まだインストールされていないライブラリを使用するた
め，要求があれば，新しいコピーがリンクされます．@samp{no}に設定されてい
る場合，libtoolは，まだインストールされていないライブラリを使用するプロ
グラムを作成し，インストール時にプログラムの新しいコピーをリンクします．
デフォルト値は@samp{yes}または@samp{needless}で，それは，プラットフォー
ムとコンフィグレーションフラグに依存し，コンフィグレーションフラグ
@samp{--disable-fast-install}を用いると，@samp{yes}から@samp{no}に切り替
えられます．
@end defvar

@defvar finish_cmds
指定されたディレクトリで共有ライブラリを見つける方法を，ダイナミックリン
カに伝えるコマンドです．
@end defvar

@defvar finish_eval
コマンドが表示されない以外，@var{finish_cmds}と同じです．
@end defvar

@defvar fix_srcfile_path
コンパイラに対するシェル変数$srcfileを修正する式です．
@end defvar

@defvar global_symbol_pipe
@var{NM}の出力を受け，Cの名前が続く生のシンボルのリストを生成するパイプ
ラインです．例えば，以下のようになります．

@example
$ @kbd{eval "$NM progname | $global_symbol_pipe"}
D @var{symbol1} @var{C-symbol1}
T @var{symbol2} @var{C-symbol2}
C @var{symbol3} @var{C-symbol3}
@dots{}
$
@end example

最初の列は，(いくつかのプラットフォーム上でコードからデータを伝えるため
に使用される)シンボル形式を含みますが，その意味はシステムに依存します．
@end defvar

@defvar global_symbol_to_cdecl
@var{global_symbol_pipe}の出力を厳密なC宣言に変換するパイプラインです．
HP/UXのような，リンカがコードとデータを区別するプラットフォームでは，デー
タシンボルはそのように宣言され，コードシンボルは関数として宣言されます．
気にしないプラットフォームではすべてがデータと仮定されます．
@end defvar

@defvar hardcode_action
@samp{immediate}または@samp{relink}のいずれかで，共有ライブラリパスがイ
ンストールされる前に実行形式にハードコードされるか，または，再リンクする
必要があるかに依存します．
@end defvar

@defvar hardcode_direct
@var{hardcode_libdir_flag_spec}が指定されたとき，
(@samp{@var{dir}/lib@var{name}.a}のような)コマンド行でライブラリが直接し
ていされる場合，リンカがディレクトリをハードコードするかどうかに依存し，
@samp{yes}または@samp{no}に設定します．
@end defvar

@defvar hardcode_into_libs
ライブラリ内の実行パスのハードコードをプラットフォームがサポートするかど
うかです．可能な場合，プログラムのリンクはより単純になりますが，ライブラ
リはインストール時に再リンクが必要です．@samp{yes}または@samp{no}に設定
します．
@end defvar

@defvar hardcode_libdir_flag_spec
実行時に，共有ライブラリに対しダイナミックリンカが@var{libdir}を検索する
ために，バイナリに@var{libdir}変数をハードコードするためのフラグです．空
の場合，libtoolは他のハードコーディングメカニズムの使用を試みます．
@end defvar

@defvar hardcode_libdir_separator
コンパイラが単一の@var{hardcode_libdir_flag}のみ受け入れる場合，この変数
はそのフラグに対する複数の引数を分ける文字列を含みます．
@end defvar

@defvar hardcode_minus_L
@var{hardcode_libdir_flag_spec}が指定されたとき，結果として生じる実行形
式に@samp{-L}フラグで指定されるディレクトリを，リンカがハードコードする
かどうかに依存し，@samp{yes}または@samp{no}に設定します．
@end defvar

@defvar hardcode_shlibpath_var
@var{hardcode_libdir_flag_spec}が指定されたとき，結果として生じる実行形
式に@samp{$shlibpath_var}の内容を書き込むことで，リンカがディレクトリを
ハードコードするかどうかに依存し，@samp{yes}または@samp{no}に設定します．
@samp{$shlibpath_var}で指定されたディレクトリが，リンク時ではなく実行時
に検索される場合，@samp{unsupported}に設定します．
@end defvar

@defvar host
@defvarx host_alias
情報を目的として，libtoolがコンフィグレーションされたシステムの指定され
た標準名に設定します．
@end defvar

@defvar include_expsyms
@var{export_symbols}の使用時に，常にエクスポートされる必要があるシンボル
のリストです．
@end defvar

@defvar libext
標準的な，古いアーカイブの接尾子(通常は"a")です．
@end defvar

@defvar libname_spec
ライブラリ名の接頭辞の書式です．Unixシステムでは，スタティックライブラリ
は@samp{lib@var{name}.a}と呼ばれますが，(OS/2やMS-DOSのような)システムで
は，ライブラリは@samp{@var{name}.a}のみで呼ばれることもあります．
@end defvar

@defvar library_names_spec
共有ライブラリ名のリストです．最初はファイル名で，残りはファイルへのシン
ボリックリンクです．リスト内の名前は，@samp{-l@var{name}}で与えられたと
きリンカが見つけるファイル名です．
@end defvar

@defvar link_all_deplibs
libtoolが，全ての依存するプログラムに対しプログラムをリンクする必要があ
るかどうかです．@samp{yes}または@samp{no}に設定します．デフォルトは
@samp{unknown}で，それは@samp{yes}と同じです．
@end defvar

@defvar link_static_flag
ダイナミックリンクを避けるために使用する(Cコンパイラに渡す)リンカフラグ
です．
@end defvar

@defvar need_lib_prefix
自動的にモジュール名に'lib'接尾子を付けるかどうかです．@samp{yes}または
@samp{no}に設定します．デフォルトで，それは@samp{unknown}になり，それは
@samp{yes}と同じ意味ですが，本当に確かめたわけではないことを告げています．
@samp{yes}は@code{dlopen}と'lib'接頭辞がないライブラリにリンク可能なこと
を意味し，すなわち，それは@var{hardcode_direct}を@samp{yes}にすることを
要求します．
@end defvar

@defvar need_version
バージョン管理がライブラリに必要とされるかどうかで，すなわち，ダイナミッ
クリンカが，すべてのライブラリに対しバージョンの接尾子を必要とするかどう
かです．@samp{yes}または@samp{no}に設定します．デフォルトで，それは
@samp{unknown}で，それは@samp{yes}と同じ意味を持ちますが，それを実際には
確かめていないことを告げています．
@end defvar

@defvar need_locks
同時にコンパイルするとき，衝突を避けるためにファイルをロックする必要があ
るかどうかです．@samp{yes}または@samp{no}に設定します．
@end defvar

@defvar no_builtin_flag
@code{char}として外部グローバルシンボルを宣言することと衝突する組み込み
関数を，利用不可能にするコンパイラフラグです．
@end defvar

@defvar no_undefined_flag
結果として生じる共有ライブラリに，未解決のシンボルがないことを宣言するた
めの，@samp{archive_cmds}で使用されるフラグです．
@end defvar

@defvar objdir
一時的なlibtoolファイルが含まれるディレクトリ名です．
@end defvar

@defvar objext
標準的なオブジェクトファイルの接尾子(通常は"o")です．
@end defvar

@defvar pic_flag
ライブラリオブジェクトファイルをビルドするための，あらゆる追加のコンパイ
ルフラグです．
@end defvar

@defvar postinstall_cmds
@defvarx old_postinstall_cmds
それぞれ，共有またはスタティックライブラリをインストールした後に実行する
コマンドです．
@end defvar

@defvar postuninstall_cmds
@defvarx old_postuninstall_cmds
それぞれ，共有またはスタティックライブラリをアンインストールした後に実行
するコマンドです．
@end defvar

@defvar reload_cmds
@defvarx reload_flag
リロード可能なオブジェクトを作成するコマンドです．
@end defvar

@defvar runpath_var
結果として生じる実行形式内にハードコードするディレクトリをリンカに伝える
環境変数です．
@end defvar

@defvar shlibpath_overrides_runpath
環境変数でプログラムのハードコードされたライブラリ検索パスを優先可能かど
うかを示します．これが@samp{no}に設定されている場合，libtoolはビルドツリー
にプログラムのコピーを２つ作成する必要がある可能性があり，一つはインストー
ルされ，もう一つはビルドツリーのみで実行されます．これらのコピーのどちら
かが作成されるとき，@code{fast_install}の値に依存します．デフォルト値は
@samp{unknown}で，それは@samp{no}と同じです．
@end defvar

@defvar shlibpath_var
ダイナミックリンカに共有ライブラリを探す場所を伝える環境変数です．
@end defvar

@defvar soname_spec
共有ライブラリがファイルの本当の名前と異なる場合，その中に符号化されたコー
ドされた名前です．
@end defvar

@defvar striplib
@defvarx old_striplib
共有(@code{striplib})やスタティック(@code{old_striplib})のライブラリを
stripするコマンドです．これらの変数が空の場合，インストールモードのstrip
フラグは，ライブラリに対し無視されます(@pxref{Install mode})．
@end defvar

@defvar sys_lib_dlsearch_path_spec
実行時にライブラリの検索パスを取得する式です．このリストに現れるディレク
トリが実行形式にハードコードされることは決してありません．
@end defvar

@defvar sys_lib_search_path_spec
コンパイル時にライブラリの検索パスを取得する式です．この変数は，特定のラ
イブラリが共有かスタティックかをテストする必要があるとき，libtoolが使用
します．@var{shlibpath_var}でリストアップされるディレクトリは，このリス
トに自動的に現れ，ライブラリ検索パスを拡張するためにこの変数を使用するリ
ンカもあるので，毎回(すなわち，コンフィグレーション時以外)libtoolは実行
します．リンカは@code{-L}のような検索パス引数も切り替えます．
@end defvar

@defvar thread_safe_flag_spec
スレッドセーフなライブラリを生成するために使用する(Cコンパイラに渡す)リ
ンカフラグです．
@end defvar

@defvar version_type
ライブラリバージョンナンバーの形式です．@samp{libtool}，
@samp{freebsd-aout}，@samp{freebsd-elf}，@samp{irix}，@samp{linux}，
@samp{osf}，@samp{sunos}，@samp{windows}，または@samp{none}の一つです．
@end defvar

@defvar whole_archive_flag_spec
便利なアーカイバから共有ライブラリを生成するコンパイラフラグです．
@end defvar

@defvar wl
libtoolが直接リンカにフラグを渡すことを可能とするCコンパイラフラグです．
@code{$@{wl@}@var{some-flag}}として使用されます．
@end defvar

@samp{_cmds}や@samp{_eval}で終わる変数は，@samp{~}で分けられた，順番に
@code{eval}されるコマンドのリストを含みます．ゼロ以外の終了ステータスを
返すコマンドがある場合，libtoolは一般的にエラーメッセージとともに終了し
ます．

@samp{_spec}で終わる変数は，libtoolで使用される前に@code{eval}されます．


@node Cheap tricks
@section 安っぽい手段

より簡単にメンテナーシップを作成するために使用することが可能な手段は以下
のようになっています．

@itemize @bullet
@item
人々がバグを報告したとき，彼らを助けたいと思う場合は，@samp{--config}，
@samp{--debug}，または@samp{--features}フラグを使用したかどうかを尋ねて
ください．これらのフラグは，中古の調査を信頼しなければならない代わりに，
情報を直接得る手助けとなるものです．

@item
@code{ltmain.in}を変更するたび毎に再コンフィグレーションする代わりに，
@var{PATH}に永久的な@code{libtool}スクリプトを保持し，それは直接
@code{ltmain.in}の元となります．

以下のステップは，そのようなスクリプトを作成する方法を記述し，そこでは
@code{/home/src/libtool}はlibtoolソースツリーを含むディレクトリ，
@code{/home/src/libtool/libtool}はプラットフォームに対し以前にコンフィグ
レーションしたlibtooolスクリプト，そして@code{~/bin}は@var{PATH}にあるディ
レクトリになっています．

@example
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$
@end example
@end itemize

@samp{libtool --version}コマンドの最終的な出力は，@code{ltmain.in}スクリ
プトが直接使用されていることを示します．@code{configure}を再実行する必要
なく新しい変更をテストするため，すぐに，@code{~/bin/libtool}や
@code{/home/src/libtool/ltmain.in}を編集してください．

@include fdl.texi

@page
@node Index
@unnumbered 索引

@printindex cp

@c summarycontents
@contents
@bye
