\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
@c This file documents GNU Libtool @value{VERSION}
@c 
このファイルは，GNU Libtool @value{VERSION}を説明します．

Copyright (C) 1996-2003 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-2003 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

@c This file documents GNU Libtool, a script that allows package developers
@c to provide generic shared library support.  This edition documents
@c version @value{VERSION}.
@c 
このファイルはGNU Libtoolの説明で，それは，パッケージ開発者が一般的な
共有ライブラリを提供することを可能にするスクリプトです．このエディショ
ンはバージョン@value{VERSION}を説明します．

@c @xref{Reporting bugs}, for information on how to report problems with
@c libtool.
@c 
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.

@c @detailmenu --- The Detailed Node Listing ---
@c 
@detailmenu
 --- 詳細なノードリスト ---

@c Introduction
@c 
はじめに

* 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.

@c Using libtool
@c 
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.

@c Invoking @code{libtool}
@c 
@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.

@c Integrating libtool with your package
@c 
パッケージと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.

@c Configuring libtool
@c 
libtoolのコンフィグレーション

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

@c Including libtool in your package
@c 
パッケージにlibtoolを含める

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

@c Library interface versions
@c 
ライブラリインターフェースのバージョン

* 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 Tips for interface design
@c 
インターフェースデザインへの助言

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

@c Dlopened modules
@c 
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.

@c Using libltdl
@c 
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.

@c Using libtool with other languages
@c 
他の言語でlibtoolを使用する

* C++ libraries::

@c Troubleshooting
@c 
トラブルシューティング

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

@c The libtool test suite
@c 
libtoolのテストスイート

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

@c Maintenance notes for libtool
@c 
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.

@c Porting libtool to new systems
@c 
新しいシステムへlibtoolを移植する

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

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

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

@end detailmenu
@end menu

@end ifnottex

@node Introduction
@c @chapter Introduction
@chapter はじめに

@c In the past, if a source code package developer wanted to take advantage
@c of the power of shared libraries, he needed to write custom support code
@c for each platform on which his package ran.  He also had to design a
@c configuration interface so that the package installer could choose what sort of
@c libraries were built.
@c 
これまで，ソースコードパッケージの開発者が共有ライブラリの能力を利用し
たい場合，パッケージを実行するそれぞれのプラットフォームに対し，カスタ
ムサポートコードを書く必要がありました．パッケージインストーラがビルド
されるライブラリの種類を選択できるように，コンフィグレーションインター
フェースを設計する必要もありました．

@c GNU Libtool simplifies the developer's job by encapsulating both the
@c platform-specific dependencies, and the user interface, in a single
@c script.  GNU Libtool is designed so that the complete functionality of
@c each host type is available via a generic interface, but nasty quirks
@c are hidden from the programmer.
@c 
GNU Libtoolは，一つのスクリプトでプラットフォーム特有の依存性とユーザ
インターフェースの両方をカプセル化することで，開発者の仕事を単純にしま
す．GNU Libtoolは，それぞれのホストの形式の完全な機能を，一般的なイン
タフェースを通して利用できるが，やっかいな癖はプログラマから隠されるよ
うに設計されています．

@c GNU Libtool's consistent interface is reassuring@dots{} users don't need
@c to read obscure documentation in order to have their favorite source
@c package build shared libraries.  They just run your package
@c @code{configure} script (or equivalent), and libtool does all the dirty
@c work.
@c 
GNU Libtoolの一貫したインターフェースは再保証されます@dots{} ユーザは
好みのソースコードパッケージを共有ライブラリにビルドするため，不明瞭な
ドキュメントを読む必要がありません．パッケージの@code{configure}スクリ
プト(またはその同等品)を実行するだけで，libtoolがいやな仕事をすべて行っ
てくれます．

@c There are several examples throughout this document.  All assume the
@c same environment: we want to build a library, @file{libhello}, in a
@c generic way.
@c 
このドキュメント全体にいくつかの例があります．すべて同じ環境を仮定して
います．我々は，ライブラリ@file{libhello}を一般的な方法でビルドしたい
と思っています．

@c @file{libhello} could be a shared library, a static library, or
@c both@dots{} whatever is available on the host system, as long as libtool
@c has been ported to it.
@c 
@file{libhello}は，共有ライブラリ，スタティックライブラリ，または，そ
の両方になります@dots{} libtoolで移植できるホストシステムで利用可能な
すべてのものです．

@c This chapter explains the original design philosophy of libtool.  Feel
@c free to skip to the next chapter, unless you are interested in history,
@c or want to write code to extend libtool in a consistent way.
@c 
この章では，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
@c @section Motivation for writing libtool
@section libtoolを書いた動機

@cindex motivation for writing libtool
@cindex design philosophy
@c Since early 1995, several different GNU developers have recognized the
@c importance of having shared library support for their packages.  The
@c primary motivation for such a change is to encourage modularity and
@c reuse of code (both conceptually and physically) in GNU programs.
@c 
1995年初頭から，数人のGNU開発者はそれぞれ，パッケージに対する共有ライ
ブラリのサポートの重要性を認識していました．そのように変更する主な動機
は，GNUプログラムでのコードのモジュール化と再利用を(概念的，物理的の両
方で)促進するためです．

@c Such a demand means that the way libraries are built in GNU packages
@c needs to be general, to allow for any library type the package installer
@c might want.  The problem is compounded by the absence of a standard
@c procedure for creating shared libraries on different platforms.
@c 
そのような要求は，パッケージのインストーラが要求するすべてのライブラリ
の形式が可能になるように，GNUパッケージにライブラリを組み込む方法を一
般的なものにする必要があることを意味します．問題は，異なるプラットフォー
ムで共有ライブラリを作成する標準的な手法が無いことです．

@c The following sections outline the major issues facing shared library
@c support in GNU, and how shared library support could be standardized
@c with libtool.
@c 
以下のセクションで，GNUでの共有ライブラリのサポートが直面している重大
な問題と，共有ライブラリのサポートをlibtoolで標準化した方法を概説しま
す．

@cindex specifications for libtool
@cindex libtool specifications
@c The following specifications were used in developing and evaluating this
@c system:
@c 
以下の仕様書が，このシステムの開発と評価で使用されました．

@enumerate
@item
@c The system must be as elegant as possible.
@c 
システムはできる限り簡潔である必要があります．

@item
@c The system must be fully integrated with the GNU Autoconf and Automake
@c utilities, so that it will be easy for GNU maintainers to use.  However,
@c the system must not require these tools, so that it can be used by
@c non-GNU packages.
@c 
システムは，GNU管理者がより簡単に使用できるように，GNU Autoconfと
Automakeユーティリティと完全に統合する必要があります．しかし，GNUパッ
ケージ以外でも使用できるように，これらのツールを要求してはなりません．

@item
@c Portability to other (non-GNU) architectures and tools is desirable.
@c 
他の(GNUでない)アーキテクチャとツールへの移植が望まれます．
@end enumerate

@node Issues
@c @section Implementation issues
@section 問題の実装

@cindex tricky design issues
@cindex design issues
@c The following issues need to be addressed in any reusable shared library
@c system, specifically libtool:
@c 
以下の問題は，再利用可能なあらゆる共有ライブラリシステム，特にlibtool
で解決する必要があります．

@enumerate
@item
@c The package installer should be able to control what sort of libraries
@c are built.
@c 
パッケージのインストーラで，ビルドされるライブラリの種類を制御可能にす
べきです．

@item
@c It can be tricky to run dynamically linked programs whose libraries have
@c not yet been installed.  @code{LD_LIBRARY_PATH} must be set properly (if
@c it is supported), or programs fail to run.
@c 
インストールされていないライブラリとダイナミックにリンクされるプログラ
ムの実行を巧妙に行うことを可能にします．@code{LD_LIBRARY_PATH}が(サポー
トしている場合は)正しく設定されている必要があり，そうでなければプログ
ラムの実行に失敗するでしょう．

@item
@c The system must operate consistently even on hosts which don't support
@c shared libraries.
@c 
システムは，共有ライブラリをサポートしていないホストでさえ，堅実に処理
する必要があります．

@item
@c The commands required to build shared libraries may differ wildly from
@c host to host.  These need to be determined at configure time in
@c a consistent way.
@c 
共有ライブラリをビルドするときに必要なコマンドは，ホストごとに大きく異
なる可能性があります．これらは，コンフィグレーション時に一定の方法で決
定する必要があります．

@item
@c It is not always obvious with which suffix a shared library should be
@c installed.  This makes it difficult for @file{Makefile} rules, since they
@c generally assume that file names are the same from host to host.
@c 
インストールされる共有ライブラリの接尾子が常に明確なわけではありません．
通常，ファイル名はホストごとに同じだということを仮定されるので，
@file{Makefile}規則が難しくなります．

@item
@c The system needs a simple library version number abstraction, so that
@c shared libraries can be upgraded in place.  The programmer should be
@c informed how to design the interfaces to the library to maximize binary
@c compatibility.
@c 
共有ライブラリをその場でアップグレード可能なように，システムは，単純な
ライブラリバージョンナンバーの抽象化が必要です．バイナリ互換を最大にす
るため，ライブラリへのインターフェースの設計方法を，プログラマに伝える
べきです．

@item
@c The install @file{Makefile} target should warn the package installer to set
@c the proper environment variables (@code{LD_LIBRARY_PATH} or equivalent),
@c or run @code{ldconfig}.
@c 
インストールする@file{Makefile}ターゲットは，パッケージインストーラに
特定の環境変数(@code{LD_LIBRARY_PATH}または同等のもの)を設定したり，
@code{ldconfig}を実行するよう，警告する必要があります．
@end enumerate

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

@c Even before libtool was developed, many free software packages built and
@c installed their own shared libraries.  At first, these packages were
@c examined to avoid reinventing existing features.
@c 
libtoolが開発されるまで，多くのフリーソフトウエアパッケージは，独自の
共有ライブラリをビルドしインストールしていました．既存の機能の再発明を
避けるために，これらのパッケージを最初に調査しました．

@c Now it is clear that none of these packages have documented the details
@c of shared library systems that libtool requires.  So, other packages
@c have been more or less abandoned as influences.
@c 
さて，これらのパッケージに，libtoolが必要としている共有ライブラリシス
テムの詳細な文章が無いのは明らかです．そのため，それ以外のパッケージは
影響するので多少断念されました．

@node Postmortem
@c @section A postmortem analysis of other implementations
@section その他の実装の近代的な解析

@cindex other implementations, flaws in
@cindex reusability of library systems
@c In all fairness, each of the implementations that were examined do the
@c job that they were intended to do, for a number of different host
@c systems.  However, none of these solutions seem to function well as a
@c generalized, reusable component.
@c 
調査されたそれぞれの実装は，多くの異なるホストシステムに対して，予定し
ていた仕事をすべて公平に行いました．しかし，再利用できるコンポーネント
として一般的に機能するものは，これらの解決法にはないようでした．

@cindex complexity of library systems
@c Most were too complex to use (much less modify) without understanding
@c exactly what the implementation does, and they were generally not
@c documented.
@c 
ほとんどのものは，実装で行なわれていることを正確に理解すること無く使用
する(まして，変更する)には複雑すぎ，それらは通常，文章化されていません
でした．

@c The main difficulty is that different vendors have different views of
@c what libraries are, and none of the packages which were examined seemed
@c to be confident enough to settle on a single paradigm that just
@c @emph{works}.
@c 
異なるベンダーはライブラリについて異なる見解を持つこと，そして，当然
@emph{動作する}という単一のパラダイムを自信を持って定めているものが調
査したパッケージには無かったことが主な難点です．

@c Ideally, libtool would be a standard that would be implemented as seri|!|es
@c of extensions and modifications to existing library systems to make them
@c work consistently.  However, it is not an easy task to convince
@c operating system developers to mend their evil ways, and people want to
@c build shared libraries right now, even on buggy, broken, confused
@c operating systems.
@c 
理想としては，既存のライブラリシステムが一貫して動作するような一連の拡
張と変更として実装されている標準物に，libtoolがなることです．しかし，
オペレーティングシステム開発者に悪い方法を修正させることは簡単な仕事で
はなく，バグが多く，壊れていて，混乱したオペレーティングシステム上でさ
え，今すぐに共有ライブラリをビルドしたいと，人々は思っていました．

@c For this reason, libtool was designed as an independent shell script.
@c It isolates the problems and inconsistencies in library building that
@c plague @file{Makefile} writers by wrapping the compiler suite on
@c different platforms with a consistent, powerful interface.
@c 
このため，libtoolは独立したシェルスクリプトとして設計されました．それ
は，異なるプラットフォーム上のコンパイラスイートを，堅実で強力なインター
フェースを用いて包み隠すことで，@file{Makefile}の書き手を悩ませるライ
ブラリのビルドでの問題と矛盾から隔離しています．

@c With luck, libtool will be useful to and used by the GNU community, and
@c that the lessons that were learned in writing it will be taken up by
@c designers of future library systems.
@c 
運が良ければ，libtoolは役に立ち，GNUコミュニティで使用され，そして，そ
れを書くとき学んだ教訓は，将来のライブラリシステムの設計に採用されるで
しょう．

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

@c At first, libtool was designed to support an arbitrary number of library
@c object types.  After libtool was ported to more platforms, a new
@c paradigm gradually developed for describing the relationship between
@c libraries and programs.
@c 
最初は，ライブラリのオブジェクト形式の不特定多数をサポートするように
libtoolは設計されました．その後，libtoolはより多くのプラットフォームに
移植され，ライブラリとプログラムの間の関係を記述するため，新しいパラダ
イムが徐々に開発されました．

@cindex definition of libraries
@cindex libraries, definition of
@c In summary, ``libraries are programs with multiple entry points, and
@c more formally defined interfaces.''
@c 
要約すると，``ライブラリは複数のエントリポイントと，より正式に定義され
たインターフェースがあるプログラムである．''ということです．

@c Version 0.7 of libtool was a complete redesign and rewrite of libtool to
@c reflect this new paradigm.  So far, it has proved to be successful:
@c libtool is simpler and more useful than before.
@c 
libtoolのバージョン0.7は，この新しいパラダイムを反映するため，完全に再
設計され書き換えられました．今のところ成功しているようです．libtoolは，
以前よりより単純になり，より役に立ちます．

@c The best way to introduce the libtool paradigm is to contrast it with
@c the paradigm of existing library systems, with examples from each.  It
@c is a new way of thinking, so it may take a little time to absorb, but
@c when you understand it, the world becomes simpler.
@c 
libtoolパラダイムを導入する最善の方法は，それぞれの例を用いて，既存の
ライブラリシステムのパラダイムと比較することです．それは新しい考え方な
ので吸収するまで少し時間がかかるかもしれませんが，理解したとき世界がよ
り単純化されるでしょう．

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

@cindex examples of using libtool
@cindex libtool examples
@c It makes little sense to talk about using libtool in your own packages
@c until you have seen how it makes your life simpler.  The examples in
@c this chapter introduce the main features of libtool by comparing the
@c standard library building procedure to libtool's operation on two
@c different platforms:
@c 
libtoolが人生をより単純にする方法が分かるまで，独自のパッケージで
libtoolを使用することを話す意味はありません．この章の例は，標準的なラ
イブラリのビルド処理と，libtoolの処理を，二つの異なるプラットフォーム
で比較することで，主な特徴を紹介します．

@table @samp
@item a23
@c An Ultrix 4.2 platform with only static libraries.
@c 
スタティックライブラリのみのUltrix 4.2プラットフォーム．

@item burger
@c A NetBSD/i386 1.2 platform with shared libraries.
@c 
共有ライブラリを持つ，NetBSD/i386 1.2プラットフォーム．
@end table

@c You can follow these examples on your own platform, using the
@c preconfigured libtool script that was installed with libtool
@c (@pxref{Configuring}).
@c 
独自のプラットフォームの例をこれに続けることが可能で，それは，libtool 
でインストールされた，前もってコンフィグレーションされているlibtoolス
クリプトを使用します(@pxref{Configuring})．

@c Source files for the following examples are taken from the @file{demo}
@c subdirectory of the libtool distribution.  Assume that we are building a
@c library, @file{libhello}, out of the files @file{foo.c} and
@c @file{hello.c}.
@c 
以下の例のソースファイルは，libtool配布物の@file{demo}サブディレクトリ
から持ってきています．ファイル@file{foo.c}と@file{hello.c}からライブラ
リ@file{libhello}をビルドしていると仮定してください．

@c Note that the @file{foo.c} source file uses the @code{cos} math library
@c function, which is usually found in the standalone math library, and not
@c the C library (@pxref{Trig Functions, , Trigonometric Functions, libc,
@c The GNU C Library Reference Manual}).  So, we need to add @kbd{-lm} to
@c the end of the link line whenever we link @file{foo.o} or @file{foo.lo}
@c into an executable or a library (@pxref{Inter-library dependencies}).
@c 
@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 The same rule applies whenever you use functions that don't appear in
@c the standard C library@dots{} you need to add the appropriate
@c @kbd{-l@var{name}} flag to the end of the link line when you link
@c against those objects.
@c 
同じ規則は，標準Cライブラリに無い関数を使用するとき，常に当てはまりま
す@dots{}これらのオブジェクトに対しリンクするときは，適切な
@kbd{-l@var{name}}フラグをリンク行の終りに加える必要があります．

@c After we have built that library, we want to create a program by linking
@c @file{main.o} against @file{libhello}.
@c 
ライブラリをビルドした後，@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
@c @section Creating object files
@section オブジェクトファイルの作成

@cindex compiling object files
@cindex object files, compiling
@c To create an object file from a source file, the compiler is invoked
@c with the `-c' flag (and any other desired flags):
@c 
ソースファイルからオブジェクトファイルを作成するため，コンパイラは`-c'
フラグ(とその他の必要なあらゆるフラグ)とともに呼び出されます．

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

@c The above compiler command produces an object file, @file{main.o}, from
@c the source file @file{main.c}.
@c 
上記のコンパイラコマンドは，ソースファイル@file{main.c}からオブジェク
トファイル@file{main.o}を生成します．

@c For most library systems, creating object files that become part of a
@c static library is as simple as creating object files that are linked to
@c form an executable:
@c 
ほとんどのライブラリシステムでは，スタティックライブラリの一部となるオ
ブジェクトファイルを作成することは，実行可能な形式にリンクされるオブジェ
クトファイルを作成することと同じくらい単純です．

@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)
@c Shared libraries, however, may only be built from
@c @dfn{position-independent code} (PIC).  So, special flags must be passed
@c to the compiler to tell it to generate PIC rather than the standard
@c position-dependent code.
@c 
しかし，共有ライブラリは@dfn{position-independent code} (PIC)のみから
ビルドされます．そのため，標準のposition-dependent codeではなくPICを生
成するようコンパイラに伝えるため，特定のフラグを渡す必要があります．

@cindex library object file
@cindex @samp{.lo} files
@cindex object files, library
@c Since this is a library implementation detail, libtool hides the
@c complexity of PIC compiler flags by using separate library object files
@c (which end in @samp{.lo} instead of @samp{.o}).  On systems without shared
@c libraries (or without special PIC compiler flags), these library object
@c files are identical to ``standard'' object files.
@c 
これがライブラリ実装の詳細なので，libtoolは個別の(@samp{.o}の代わりに
@samp{.lo}で終わる)ライブラリオブジェクトファイルを用いて，複雑なPICコ
ンパイラフラグを隠蔽します．共有ライブラリが無い(または，特定のPICフラ
グが無い)システムでは，これらのライブラリオブジェクトファイルは``標準
の''オブジェクトファイルと同じです．

@c To create library object files for @file{foo.c} and @file{hello.c},
@c simply invoke libtool with the standard compilation command as
@c arguments (@pxref{Compile mode}):
@c 
@file{foo.c}と@file{hello.c}に対するライブラリオブジェクトファイルを作
成するため，単純に標準のコンパイルコマンドを引数として，libtoolを呼び
出してください(@pxref{Compile mode})．

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

@c Note that libtool creates two files for each invocation.  The @samp{.lo}
@c file is a library object, which may be built into a shared library, and
@c the @samp{.o} file is a standard object file.  On @samp{a23}, the
@c library objects are just timestamps, because only static libraries are
@c supported.
@c 
それぞれの呼び出しで，libtoolが二つのファイルを作成することに注意して
ください．@samp{.lo}ファイルはライブラリオブジェクトで，それは共有ライ
ブラリにビルドされ，@samp{.o}ファイルは標準的なオブジェクトファイルで
す．@samp{a23}では，スタティックライブラリのみサポートされているので，
ライブラリオブジェクトはタイムスタンプのみです．

@c On shared library systems, libtool automatically inserts the PIC
@c generation flags into the compilation command, so that the library
@c object and the standard object differ:
@c 
共有ライブラリのあるシステムでは，ライブラリオブジェクトと標準オブジェ
クトが異なるように，libtoolはPIC生成フラグをコンパイルコマンドに自動的
に挿入します．

@example
burger$ @kbd{libtool --mode=compile 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 --mode=compile 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

@c Notice that the second run of GCC has its output discarded.  This is
@c done so that compiler warnings aren't annoyingly duplicated.
@c 
二番目に実行されるGCCがその出力を破棄していることに注意してください．
これは，コンパイラの警告がうるさく重複しないために行われます．

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

@pindex ar
@c Without libtool, the programmer would invoke the @code{ar} command to
@c create a static library:
@c 
libtoolを用いない場合，スタティックライブラリを作成するため，プログラ
マは@code{ar}コマンドを呼び出していました．

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

@pindex ranlib
@c But of course, that would be too simple, so many systems require that
@c you run the @code{ranlib} command on the resulting library (to give it
@c better karma, or something):
@c 
しかしもちろん，それだけではあまりに単純すぎて，多くのシステムでは(そ
れ以上のカルマや何かを与えるため)結果として生成されたライブラリ上で，
@code{ranlib}コマンドを実行する必要があります．

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

@c It seems more natural to use the C compiler for this task, given
@c libtool's ``libraries are programs'' approach.  So, on platforms without
@c shared libraries, libtool simply acts as a wrapper for the system
@c @code{ar} (and possibly @code{ranlib}) commands.
@c 
libtoolの``ライブラリはプログラム''というアプローチであるといるこの作
業に対して，Cコンパイラを使用することはより自然に感じられます．その
ため，共有ライブラリが無いプラットフォームでは，libtoolは単純にシステ
ムの@code{ar}(そして可能なら@code{ranlib})コマンドのラッパーとして動作
します．

@cindex libtool libraries
@cindex @samp{.la} files
@c Again, the libtool library name differs from the standard name (it has a
@c @samp{.la} suffix instead of a @samp{.a} suffix).  The arguments to libtool are
@c the same ones you would use to produce an executable named
@c @file{libhello.la} with your compiler (@pxref{Link mode}):
@c 
また，libtoolのライブラリ名は，標準の名前(@samp{.a}接尾子の代わりに
@samp{.la}接尾子を持ちます)とは異なります．libtoolの引数は，コンパイラで
@file{libhello.la}という名の実行形式を生成するために使用したのと同じも
のです(@pxref{Link mode})．

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

@c Aha!  Libtool caught a common error@dots{} trying to build a library
@c from standard objects instead of library objects.  This doesn't matter
@c for static libraries, but on shared library systems, it is of great
@c importance.
@c 
あぁ！libtoolは通常のエラーを得てしまいましたた@dots{}ライブラリオブジェ
クトの代わりに，標準のオブジェクトからライブラリをビルドしています．こ
れはスタティックライブラリでは問題ありませんが，共有ライブラリシステム
では非常に重要です．

@c So, let's try again, this time with the library object files.  Remember
@c also that we need to add @kbd{-lm} to the link command line because
@c @file{foo.c} uses the @code{cos} math library function (@pxref{Using
@c libtool}).
@c 
そのため，今回はライブラリオブジェクトファイルを用いて，もう一度試して
みましょう．@file{foo.c}が@code{cos}数学ライブラリを使用しているので，
コマンドラインに@kbd{-lm}を加える必要があることも忘れないでください
(@pxref{Using libtool})．

@c Another complication in building shared libraries is that we need to
@c specify the path to the directory in which they (eventually) will be
@c installed (in this case, @file{/usr/local/lib})@footnote{If you don't
@c specify an @code{rpath}, then libtool builds a libtool convenience
@c archive, not a shared library (@pxref{Static libraries}).}:
@c 
共有ライブラリをビルドするその他の複雑なことは，(最終的に)インストール
されるディレクトリパス(この場合は，@file{/usr/local/lib})
@footnote{@code{rpath}を指定しない場合，libtoolはコンビニエンスアーカ
イブをビルドしますが，それは共有ライブラリではありません(@pxref{Static
libraries})}を指定する必要があることです．

@example
a23$ @kbd{libtool --mode=link 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

@c Now, let's try the same trick on the shared library platform:
@c 
さて，共有ライブラリのプラットフォーム上で同じトリックを試してみましょ
う．

@example
burger$ @kbd{libtool --mode=link 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

@c Now that's significantly cooler@dots{} libtool just ran an obscure
@c @code{ld} command to create a shared library, as well as the static
@c library.
@c 
さてそれはかなり賢いです@dots{}libtoolは共有ライブラリを作成するため，
スタティックライブラリと同様に，曖昧な@code{ld}コマンドを実行しただけ
です．

@cindex @file{@value{objdir}} subdirectory
@c Note how libtool creates extra files in the @file{@value{objdir}}
@c subdirectory, rather than the current directory.  This feature is to
@c make it easier to clean up the build directory, and to help ensure that
@c other programs fail horribly if you accidentally forget to use libtool
@c when you should.
@c 
libtoolが，現在のディレクトリではなく，@file{@value{objdir}}サブディレ
クトリに余分なファイルを作成することに注意してください．この機能は，ビ
ルドディレクトリをきれいにするのをより簡単にするためと，たまたま
libtoolの使用を忘れていて他のプログラムを実行するとき，確実に手ひどく
失敗するので役に立ちます．

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

@cindex linking against installed libraries
@c If you choose at this point to @dfn{install} the library (put it in a
@c permanent location) before linking executables against it, then you
@c don't need to use libtool to do the linking.  Simply use the appropriate
@c @samp{-L} and @samp{-l} flags to specify the library's location.
@c 
ライブラリを実行形式とリンクする前に，@dfn{インストール}する(恒久的な
場所にそれを配置する)場所を選択した場合，リンクするためにlibtoolを使用
する必要はありません．ライブラリの位置を指定するため，単純に適切な
@samp{-L}と@samp{-l}フラグを使用してください．

@cindex buggy system linkers
@c Some system linkers insist on encoding the full directory name of each
@c shared library in the resulting executable.  Libtool has to work around
@c this misfeature by special magic to ensure that only permanent directory
@c names are put into installed executables.
@c 
システムのリンカによっては，結果として生じる実行形式に，共有ライブラリ
の完全なディレクトリ名の符号化を強要するものもあります．libtoolは，恒
久的なディレクトリ名のみをインストールされた実行形式に書き込むことを確
実にするため，特別な魔法でこの設計ミスに関して動作する必要があります．

@cindex security problems with buggy linkers
@cindex bugs, subtle ones caused by buggy linkers
@c The importance of this bug must not be overlooked: it won't cause
@c programs to crash in obvious ways.  It creates a security hole,
@c and possibly even worse, if you are modifying the library source code
@c after you have installed the package, you will change the behaviour of
@c the installed programs!
@c 
このバグの重要性は見落としてはなりません．それによるプログラムの暴走は
明白ではありません．それはセキュリティホールを作成し，さらに悪いことに
は，パッケージのインストール後にライブラリソースコードを編集した場合，
インストールされたプログラムの動作を変更してしまうでしょう！

@c So, if you want to link programs against the library before you install
@c it, you must use libtool to do the linking.
@c 
そのため，インストールする前にライブラリとプログラムをリンクさせたい場
合，リンクするためにlibtoolを使用する必要があります．

@cindex linking against uninstalled libraries
@c Here's the old way of linking against an uninstalled library:
@c 
インストールされていないライブラリとリンクする古い方法は，以下のように
なります．

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

@c Libtool's way is almost the same@footnote{However, you should avoid using
@c @samp{-L} or @samp{-l} flags to link against an uninstalled libtool
@c library.  Just specify the relative path to the @samp{.la} file, such as
@c @file{../intl/libintl.la}.  This is a design decision to eliminate any
@c ambiguity when linking against uninstalled shared libraries.}
@c (@pxref{Link mode}):
@c 
libtoolの方法は，ほとんど同じです@footnote{しかし，インストールされて
いないlibtoolライブラリにリンクするために，@samp{-L}や@samp{-l}フラグ
の使用は避けたほうがいいでしょう．@samp{.la}ファイルに対する，
@file{../intl/libintl.la}のような相対パスのみを指定してください．これ
は，インストールされていない共有ライブラリに対しリンクするとき，あらゆ
る曖昧さを取り除くため決定された設計です．}(@pxref{Link mode})．

@example
a23$ @kbd{libtool --mode=link 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

@c That looks too simple to be true.  All libtool did was transform
@c @file{libhello.la} to @file{./@value{objdir}/libhello.a}, but remember
@c that @samp{a23} has no shared libraries.
@c 
真実としてはあまりに単純に見えます．libtoolが行うことは，
@file{libhello.la}を@file{./@value{objdir}/libhello.a}に変換することが
すべてですが，@samp{a23}には共有ライブラリがないことを忘れないでくださ
い．

@c On @samp{burger} the situation is different:
@c 
@samp{burger}では，状況が異なります．

@example
burger$ @kbd{libtool --mode=link 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

@c Now assume @file{libhello.la} had already been installed, and you want
@c to link a new program with it.  You could figure out where it lives by
@c yourself, then run:
@c 
さて，@file{libhello.la}が既にインストールされていると仮定し，新しいプ
ログラムをそれとリンクしたいとします．自分でそれがある場所を探し，以下
を実行します．

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

@c However, unless @file{/usr/local/lib} is in the standard library search
@c path, you won't be able to run @code{test}.  However, if you use libtool
@c to link the already-installed libtool library, it will do The Right
@c Thing (TM) for you:
@c 
しかし，@file{/usr/local/lib}が標準のライブラリ検索パスに無い場合，
@code{test}を実行することはできません．しかし，既にインストールされて
いるlibtoolライブラリとリンクするためlibtoolを使用する場合，それは The
Right Thing (TM) (正解)となります．

@example
burger$ @kbd{libtool --mode=link 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

@c Note that libtool added the necessary run-time path flag, as well as
@c @samp{-lm}, the library libhello.la depended upon.  Nice, huh?
@c 
libtoolが，ライブラリlibhello.laが依存している@samp{-lm}同様，必要なラ
ンタイムパスフラグを追加していることに注意してください．いいですね，ふっ
ふ？

@c Since libtool created a wrapper script, you should use libtool to
@c install it and debug it too.  However, since the program does not depend
@c on any uninstalled libtool library, it is probably usable even without
@c the wrapper script.  Libtool could probably be made smarter to avoid the
@c creation of the wrapper script in this case, but this is left as an
@c exercise for the reader.
@c 
libtoolがラッパースクリプトを作成したので，インストールとデバッグにも
libtoolを使用したほうがいいでしょう．しかし，プログラムはインストール
されていないlibtoolライブラリには全く依存しないので，ラッパースクリプ
トを用いない場合でもおそらく有用でしょう．この場合は，ラッパースクリプ
トの作成を避けるため，おそらくより賢くlibtoolを作成できたでしょうが，
これは読者の演習として残しておきます．


@cindex wrapper scripts for programs
@cindex program wrapper scripts
@c Notice that the executable, @code{hell}, was actually created in the
@c @file{@value{objdir}} subdirectory.  Then, a wrapper script was created
@c in the current directory.
@c 
実行形式@code{hell}は，実際には@file{@value{objdir}}サブディレクトリに
作成されることに注意してください．そして，ラッパースクリプトは現在のディ
レクトリに作成されます．

@c On NetBSD 1.2, libtool encodes the installation directory of
@c @file{libhello}, by using the @samp{-R/usr/local/lib} compiler flag.
@c Then, the wrapper script guarantees that the executable finds the
@c correct shared library (the one in @file{./@value{objdir}}) until it is
@c properly installed.
@c 
NetBSD 1.2では，libtoolは@samp{-R/usr/local/lib}コンパイラフラグを使用
して，@file{libhello}のディレクトリのインストールを符号化します．そし
て，ラッパースクリプトは，正しくインストールされるまで実行形式が正しい
(@file{./@value{objdir}}にある)共有ライブラリを見つけることを保証しま
す．

@c Let's compare the two different programs:
@c 
二つの異なるプログラムを比較してみましょう．

@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

@c The wrapper script takes significantly longer to execute, but at least
@c the results are correct, even though the shared library hasn't been
@c installed yet.
@c 
ラッパースクリプトは実行にかなり時間がかかりますが，共有ライブラリがイ
ンストールされていなくても，少なくとも結果は正しくなります．

@c So, what about all the space savings that shared libraries are supposed
@c to yield?
@c 
そのため，共有ライブラリがもたらした，全体的なスペース削減ははどうなっ
ているのでしょう？

@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

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

@c Actually, it just proves an important point: shared libraries incur
@c overhead because of their (relative) complexity.  In this situation, the
@c price of being dynamic is eight kilobytes, and the payoff is about four
@c kilobytes.  So, having a shared @file{libhello} won't be an advantage
@c until we link it against at least a few more programs.
@c 
実際，それは重要なことを証明しています．共有ライブラリには，それが(関
連する)複雑さのため，オーバーへッドをがあります．この状況では，ダイナ
ミックの価値は8キロバイトで，報酬は約4キロバイトです．そのため，少なく
とも二，三個以上のプログラムとリンクするまで，共有される
@file{libhello}を維持することは利点になりません．

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

@c If @file{hell} was a complicated program, you would certainly want to
@c test and debug it before installing it on your system.  In the above
@c section, you saw how the libtool wrapper script makes it possible to run
@c the program directly, but unfortunately, this mechanism interferes with
@c the debugger:
@c 
@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

@c Sad.  It doesn't work because GDB doesn't know where the executable
@c lives.  So, let's try again, by invoking GDB directly on the executable:
@c 
残念です．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

@c Argh.  Now GDB complains because it cannot find the shared library that
@c @file{hell} is linked against.  So, we must use libtool in order to
@c properly set the library path and run the debugger.  Fortunately, we can
@c forget all about the @file{@value{objdir}} directory, and just run it on
@c the executable wrapper (@pxref{Execute mode}):
@c 
あぁ．さて，GDBは，@file{hell}がリンクしている共有ライブラリを見つける
ことができないため文句を言いました．そのため，正しいライブラリパスを設
定してデバッガを実行するために，libtoolを使う必要があります．幸い，
@file{@value{objdir}}ディレクトリを完全に忘れて，そのままの実行形式の
ラッパーで実行可能です(@pxref{Execute mode})．

@example
burger$ @kbd{libtool --mode=execute 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
@c @section Installing libraries
@section ライブラリのインストール

@pindex strip
@c Installing libraries on a non-libtool system is quite
@c straightforward@dots{} just copy them into place:@footnote{Don't
@c accidentally strip the libraries, though, or they will be unusable.}
@c 
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

@c Oops, don't forget the @code{ranlib} command:
@c 
おっと，@code{ranlib}コマンドを忘れないでください．

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

@pindex install
@c Libtool installation is quite simple, as well.  Just use the
@c @code{install} or @code{cp} command that you normally would
@c (@pxref{Install mode}):
@c 
libtoolのインストールは，同様に全く単純です．通常使用する，
@code{install}や@code{cp}コマンドをそのまま使用してください
(@pxref{Install mode})．

@example
a23# @kbd{libtool --mode=install 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

@c Note that the libtool library @file{libhello.la} is also installed, to
@c help libtool with uninstallation (@pxref{Uninstall mode}) and linking
@c (@pxref{Linking executables}) and to help programs with dlopening
@c (@pxref{Dlopened modules}).
@c 
アンインストールでlibtoolを助け(@pxref{Uninstall mode})，リンクし
(@pxref{Linking executables})，dlopenでプログラムを助ける
(@pxref{Dlopened modules})ため，libtoolのライブラリ@file{libhello.la}
もインストールされることに注意してください．

@c Here is the shared library example:
@c 
共有ライブラリの例は，以下のようになります．

@example
burger# @kbd{libtool --mode=install 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
@c It is safe to specify the @samp{-s} (strip symbols) flag if you use a
@c BSD-compatible install program when installing libraries.
@c Libtool will either ignore the @samp{-s} flag, or will run a program
@c that will strip only debugging and compiler symbols from the library.
@c 
ライブラリインストール時にBSD互換のinstallプログラムを使用する場合，
@samp{-s}(シンボルのstrip)フラグを指定すると安全です．libtoolは
@samp{-s} フラグを無視する，またはライブラリからデバッグとコンパイラシ
ンボルのみをstripするプログラムを実行します．

@c Once the libraries have been put in place, there may be some additional
@c configuration that you need to do before using them.  First, you must
@c make sure that where the library is installed actually agrees with the
@c @samp{-rpath} flag you used to build it.
@c 
ライブラリを一度配置すると，使用する前に必要な追加のコンフィグレーショ
ンを行います．最初に，ビルド時に使用した@samp{-rpath}フラグと同じ場所
に，ライブラリが実際にインストールされていることを確かめる必要がありま
す．

@cindex postinstallation
@cindex installation, finishing
@cindex libraries, finishing installation
@c Then, running @samp{libtool -n --mode=finish @var{libdir}} can give you
@c further hints on what to do (@pxref{Finish mode}):
@c 
そして，@samp{libtool -n --mode=finish @var{libdir}}を実行すると，行う
ことのヒントが与えられるはずです(@pxref{Finish mode})．

@example
burger# @kbd{libtool -n --mode=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

@c After you have completed these steps, you can go on to begin using the
@c installed libraries.  You may also install any executables that depend
@c on libraries you created.
@c 
これらのステップを完了した後，インストールされたライブラリの使用開始が
可能になります．作成されたライブラリに依存する実行形式もインストールで
きます．

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

@c If you used libtool to link any executables against uninstalled libtool
@c libraries (@pxref{Linking executables}), you need to use libtool to
@c install the executables after the libraries have been installed
@c (@pxref{Installing libraries}).
@c 
インストールされていないlibtoolライブラリに対して，実行形式をリンクす
るためにlibtoolを使用した場合(@pxref{Linking executables})，ライブラリ
をインストールした後に実行形式をインストールするため，libtoolを使用す
る必要があります．

@c So, for our Ultrix example, we would run:
@c 
それでは，Ultrixの例を対象に，以下のように実行します．

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

@c On shared library systems, libtool just ignores the wrapper script and
@c installs the correct binary:
@c 
共有ライブラリシステムでは，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
@c @section Linking static libraries
@section スタティックライブラリとのリンク

@cindex static linking
@cindex convenience libraries
@c Why return to @code{ar} and @code{ranlib} silliness when you've had a
@c taste of libtool?  Well, sometimes it is desirable to create a static
@c archive that can never be shared.  The most frequent case is when you
@c have a set of object files that you use to build several different
@c programs.  You can create a ``convenience library'' out of those
@c objects, and link programs with the library, instead of listing all
@c object files for every program.  This technique is often used to
@c overcome GNU automake's lack of support for linking object files built
@c from sources in other directories, because it supports linking with
@c libraries from other directories.  This limitation applies to GNU
@c automake up to release 1.4; newer releases should support sources in
@c other directories.
@c 
libtoolの旨味を知って，@code{ar}と@code{ranlib}の愚かさへなぜ戻るので
しょう？さて，決して共有されるはずがないスタティックアーカイブをつくる
ことが望ましいときもあります．最もよくある状況として，複数の異なるプロ
グラムをビルドするために使用する，オブジェクトファイルの集まりを持って
いるときがあります．個々のプログラムに対し，すべてのオブジェクトファイ
ルをリストアップする代わりに，それらのオブジェクトから``コンビニエンス
ライブラリ''を作成し，ライブラリとプログラムをリンクすることが可能です．
この技術は，他のディレクトリのライブラリへのリンクをサポートするので，
他のディレクトリのソースからビルドされるオブジェクトファイルをリンクす
るサポートが欠けている，GNU automakeを補うためによく使用されます．この
制限は，リリース1.4までのGNU automakeに当てはまります．より新しいリリー
スは，他のディレクトリのソースをサポートするでしょう．

@c If you just want to link this convenience library into programs, then
@c you could just ignore libtool entirely, and use the old @code{ar} and
@c @code{ranlib} commands (or the corresponding GNU automake
@c @samp{_LIBRARIES} rules).  You can even install a convenience library
@c (but you probably don't want to) using libtool:
@c 
このコンビニエンスライブラリとプログラムをリンクしたいだけの場合，完全
にlibtoolを無視し，古い@code{ar}と@code{ranlib}コマンド(や，対応する
GNU automake @samp{_LIBRARIES}規則)が使用可能です．(おそらく使用したく
はないでしょうが)libtoolを使用して，コンビニエンスライブラリをインストー
ルすることさえ可能です．

@example
burger$ @kbd{libtool --mode=install ./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

@c Using libtool for static library installation protects your library from
@c being accidentally stripped (if the installer used the @samp{-s} flag),
@c as well as automatically running the correct @code{ranlib} command.
@c 
スタティックライブラリのインストールにlibtoolを使用すると，ライブラリ
が(@samp{-s}フラグを使用したインストーラの場合のように)偶然stripされる
ことから守り，自動的に実行される正しい@code{ranlib}コマンドと同様にな
ります．

@c But libtool libraries are more than just collections of object files:
@c they can also carry library dependency information, which old archives
@c do not.  If you want to create a libtool static convenience library, you
@c can omit the @samp{-rpath} flag and use @samp{-static} to indicate that
@c you're only interested in a static library.  When you link a program
@c with such a library, libtool will actually link all object files and
@c dependency libraries into the program.
@c 
しかし，libtoolライブラリは単にオブジェクトファイルの集合以上です．そ
れらは古いアーカイブにはない，ライブラリの依存情報も伝えることが可能で
す．libtoolのスタティックなコンビニエンスライブラリを作成したい場合，
スタティックライブラリのみに興味があることを示すため，@samp{-rpath}フ
ラグを省略し@samp{-static}を使用することができます．そのようなスタティッ
クライブラリとリンクするとき，libtoolは実際にすべてのオブジェクトファ
イルと依存するライブラリをプログラムにリンクします．

@c If you omit both @samp{-rpath} and @samp{-static}, libtool will create a
@c convenience library that can be used to create other libtool
@c libraries, even shared ones.  Just like in the static case, the library
@c behaves as an alias to a set of object files and dependency libraries,
@c but in this case the object files are suitable for inclusion in shared
@c libraries.  But be careful not to link a single convenience library,
@c directly or indirectly, into a single program or library, otherwise you
@c may get errors about symbol redefinitions.
@c 
@samp{-rpath}と@samp{-static}の両方を省略した場合，libtoolは，他の
libtoolライブラリで，共有ライブラリの作成にすら使用可能なlibtoolのコン
ビニエンスライブラリを作成します．スタティックな場合のように，ライブラ
リは一組のオブジェクトファイルと依存するライブラリの別名として動作しま
すが，この場合，オブジェクトファイルは共有ライブラリに含まれるほうが適
しています．しかし，直接または間接的に，単一のプログラムやライブラリに
単一のコンビニエンスライブラリをリンクしないように注意して下さい．さも
なければ，シンボル再定義に関するエラーを得るでしょう．

@c When GNU automake is used, you should use @code{noinst_LTLIBRARIES}
@c instead of @code{lib_LTLIBRARIES} for convenience libraries, so that
@c the @samp{-rpath} option is not passed when they are linked.
@c 
GNU automakeを使用するとき，@samp{-rpath}オプションがリンク時に渡され
ないように，コンビニエンスライブラリに対する@code{lib_LTLIBRARIES}の代
わりに@code{noinst_LTLIBRARIES}を使用した方が良いでしょう．

@c As a rule of thumb, link a libtool convenience library into at most one
@c libtool library, and never into a program, and link libtool static
@c convenience libraries only into programs, and only if you need to carry
@c library dependency information to the user of the static convenience
@c library.
@c 
経験的に，最大一つのlibtoolライブラリにlibtoolのコンビニエンスライブラ
リをリンクし，プログラムにはリンクしないようにしてください，そして，
libtoolのコンビニエンススタティックライブラリを一つのプログラムにのみ
リンクし，それは，ライブラリ依存情報をコンビニエンススタティックライブ
ラリのユーザに伝えることが必要な場合のみにしてください．

@cindex standalone binaries
@c Another common situation where static linking is desirable is in
@c creating a standalone binary.  Use libtool to do the linking and add the
@c @samp{-all-static} flag.
@c 
スタティックなリンクが適している，その他の一般的な状況は，独立したバイ
ナリを作成するときです．リンクにlibtoolを使用し，@samp{-all-static}フ
ラグを加えてください．

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

@c The @code{libtool} program has the following synopsis:
@c 
@code{libtool}プログラムは以下の構文になります．

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

@noindent
@c and accepts the following options:
@c 
そして，以下のオプションを受け入れます．

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

@item --debug
@c Dump a trace of shell script execution to standard output.  This
@c produces a lot of output, so you may wish to pipe it to @code{less} (or
@c @code{more}) or redirect to a file.
@c 
シェルスクリプトの実行の追跡を標準出力にダンプします．これは多くの出力
を生成するので，@code{less}(や@code{more})にパイプしたり，ファイルにリ
ダイレクトしたいかもしれません．

@item -n
@itemx --dry-run
@c Don't create, modify, or delete any files, just show what commands would
@c be executed by libtool.
@c 
あらゆるファイルを作成，編集，削除せず，libtoolで実行されるコマンドの
みを表示します．

@item --features
@c Display basic configuration options.  This provides a way for packages
@c to determine whether shared or static libraries will be built.
@c 
基本的なコンフィグレーションオプションを表示します．これは，パッケージ
がビルドするライブラリを，スタティックまたは共有のいずれにするか決定す
る方法を提供します．

@item --preserve-dup-deps
@c Do not remove duplicate dependencies in libraries.  When building packages
@c with static libraries, the libraries may depend circularly on each other
@c (shared libs can too, but for those it doesn't matter), so there are
@c situations, where -la -lb -la is required, and the second -la may not be
@c stripped or the link will fail.  In cases where these duplications are
@c required, this option will preserve them, only stripping the libraries
@c that libtool knows it can safely.
@c 
ライブラリ内で重複する依存性を削除しません．スタティックライブラリを用
いたパッケージのビルド時に，ライブラリはお互いに回忌的に依存する可能性
があるので(共有ライブラリもそうですが，それらは問題ありません)，その状
況では，@option{-la -lb -la}が要求されるところで，二番目の@option{-la} 
を取り除いてはならず，さもないとリンクは失敗するでしょう．これらの重複
が必要な状況では，このオプションはそれらを保持し，libtoolが安全だと分
かっているライブラリだけを取り除きます．

@item --finish
@c Same as @samp{--mode=finish}.
@c 
@samp{--mode=finish}と同じです．

@item --help
@c Display a help message and exit.  If @samp{--mode=@var{mode}} is
@c specified, then detailed help for @var{mode} is
@c displayed.
@c 
へルプメッセージを表示し終了します．@samp{--mode=@var{mode}}が指定され
た場合，@var{mode}の詳細へルプを表示します．

@item --mode=@var{mode}
@c Use @var{mode} as the operation mode.  If not specified, an attempt is
@c made to inferr the operation mode from the @var{mode-args}.  Not specifying
@c the @var{mode} is currently deprecated, as there are too many situations
@c where it is not possible to guess.  Future versions of Libtool will require
@c that @var{mode} be explicity set.
@c 
処理モードとして@var{mode}を使用します．デフォルトで，処理モードは
@var{mode-args}から推測されます．推測不可能な状況があまりに多いので，
@var{mode}を指定しないことは，現在では推奨されていません．将来の
libtoolのバージョンでは，@var{mode}を明示的に設定することを要求するよ
うになるでしょう．

@c @var{mode} must be set to one of the following:
@c 
@var{mode}は以下の一つに設定する必要があります．

@table @samp
@item compile
@c Compile a source file into a libtool object.
@c 
ソースファイルをlibtoolオブジェクトにコンパイルします．

@item execute
@c Automatically set the library path so that another program can use
@c uninstalled libtool-generated programs or libraries.
@c 
インストールされていない，libtoolが生成したプログラムやライブラリを他
のプログラムが使用できるように，自動的にライブラリパスを設定します．

@item finish
@c Complete the installation of libtool libraries on the system.
@c 
libtoolライブラリのシステムへのインストールを完全に行います．

@item install
@c Install libraries or executables.
@c 
ライブラリや実行形式をインストールします．

@item link
@c Create a library or an executable.
@c 
ライブラリや実行形式を作成します．

@item uninstall
@c Delete installed libraries or executables.
@c 
インストールされたライブラリや実行形式を削除します．

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

@item --version
@c Print libtool version information and exit.
@c 
ibtoolのバージョン情報を出力し終了します．
@end table

@c The @var{mode-args} are a variable number of arguments, depending on the
@c selected operation mode.  In general, each @var{mode-arg} is interpreted
@c by programs libtool invokes, rather than libtool itself.
@c 
@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
@c @section Compile mode
@section コンパイルモード
@cindex mode, compile
@cindex compile mode

@c For @dfn{compile} mode, @var{mode-args} is a compiler command to be used
@c in creating a `standard' object file.  These arguments should begin with
@c the name of the C compiler, and contain the @samp{-c} compiler flag so
@c that only an object file is created.
@c 
@dfn{コンパイル}モードに対し，@var{mode-args}は，`標準的な'オブジェク
トファイルを作成するとき使用するコンパイルコマンドです．これらの引数は，
Cコンパイラの名前で始まり，オブジェクトファイルのみを作成するための
@samp{-c}コンパイラフラグが含まれます．

@c Libtool determines the name of the output file by removing the directory
@c component from the source file name, then substituting the source code
@c suffix (e.g. @samp{.c} for C source code) with the library object suffix,
@c @samp{.lo}.
@c 
libtoolは，ソースファイル名からディレクトリ要素を削除して出力ファイル
名を決定し，ソースコードの接尾子(例えば，Cソースコードに対する
@samp{.c})をライブラリオブジェクト接尾子@samp{.lo}に置換します．

@c If shared libraries are being built, any necessary PIC generation flags
@c are substituted into the compilation command.  You can pass link specific
@c flags to the compiler driver using @samp{-XCClinker @var{flag}} or pass
@c linker flags with @samp{-Wl,@var{flag}} and @samp{-Xlinker @var{flag}}.
@c You can also pass compile specific flags using @samp{-Wc,@var{flag}}
@c and @samp{-Xcompiler @var{flag}}.
@c 
共有ライブラリをビルドする場合は，必要なPIC生成フラグがコンパイルコマ
ンドに置換されます．@samp{-XCClinker @var{flag}}を使用したり，リンカフ
ラグ@samp{-Wl,@var{flag}}と@samp{-Xlinker @var{flag}}を渡すことで，リ
ンク指定のフラグをコンパイラドライバに渡すことが可能です．また，
@samp{-Wc,@var{flag}}と@samp{-Xcompiler @var{flag}}を使用することで，
コンパイル指定のフラグを渡すことも可能です．

@c If the @samp{-static} option is given, then a @samp{.o} file is built,
@c even if libtool was configured with @samp{--disable-static}.
@c 
@samp{-static}オプションが与えられている場合は，libtoolが
@samp{--disable-static}でコンフィグレーションされていた場合でも，
@file{.o}ファイルがビルされてます．

@c Note that the @samp{-o} option is now fully supported.  It is emulated
@c on the platforms that don't support it (by locking and moving the
@c objects), so it is really easy to use libtool, just with minor
@c modifications to your Makefiles. Typing for example
@c 
現在は@samp{-o}オプションが，完全にサポートされていることに注意してく
ださい．それがサポートされていないプラットフォームでは，(オブジェクト
のロックと移動によって)エミュレートされるので，Makefileを少し編集する
だけでlibtoolは本当に簡単に使用できます．入力例は以下のようになります．
@example
libtool gcc -c foo/x.c -o foo/x.lo
@end example
will do what you expect.

@c Note, however, that, if the compiler does not support @samp{-c} and
@c @samp{-o}, it is impossible to compile @file{foo/x.c} without
@c overwriting an existing @file{./x.o}.  Therefore, if you do have a
@c source file @file{./x.c}, make sure you introduce dependencies in your
@c @file{Makefile} to make sure @file{./x.o} (or @file{./x.lo}) is
@c re-created after any sub-directory's @file{x.lo}:
@c 
しかし，コンパイラが@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
@c This will also ensure that make won't try to use a temporarily corrupted
@c @file{x.o} to create a program or library.  It may cause needless
@c recompilation on platforms that support @samp{-c} and @samp{-o}
@c together, but it's the only way to make it safe for those that don't.
@c 
これは，プログラムやライブラリを作成するため，一時的に壊れた@file{x.o}
の使用を試みないことを確実にします．それは，@samp{-c}と@samp{-o}を同時
にサポートするプラットフォームで，不必要な再コンパイルを引き起こすかも
しれませんが，それは，そうでないものに対して安全にする唯一の方法です．

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

@c @dfn{Link} mode links together object files (including library
@c objects) to form another library or to create an executable program.
@c 
@dfn{リンク}モードは，(ライブラリオブジェクトを含む)オブジェクトファイ
ルと，その他のライブラリや作成された実行可能なプログラムをリンクします．

@c @var{mode-args} consist of a command using the C compiler to create an
@c output file (with the @samp{-o} flag) from several object files.
@c 
@var{mode-args}は，いくつかのオブジェクトファイルから(@samp{-o}フラグ
を用いた)出力ファイルを作成するためにCコンパイラが使用するコマンドから
成り立ちます．

@c The following components of @var{mode-args} are treated specially:
@c 
以下の@var{mode-args}の組は特別に扱われます．

@table @samp
@cindex undefined symbols, allowing
@cindex unresolved symbols, allowing
@item -all-static
@c If @var{output-file} is a program, then do not link it against any
@c shared libraries at all.  If @var{output-file} is a library, then only
@c create a static library.
@c 
@var{output-file}がプログラムの場合，共有ライブラリと全くリンクしませ
ん．@var{output-file}がライブラリの場合，スタティックライブラリのみ作
成します．

@item -avoid-version
@c Tries to avoid versioning (@pxref{Versioning}) for libraries and modules,
@c i.e. no version information is stored and no symbolic links are created.
@c If the platform requires versioning, this option has no effect.
@c 
ライブラリとモジュールに対しバージョン管理(@pxref{Versioning})を避けよ
うとし，すなわち，バージョン情報は保存されず，シンボリックリンクも作成
されません．プラットフォームがバージョニングを要求する場合，このオプショ
ンは効果がありません．

@item -dlopen @var{file}
@c Same as @samp{-dlpreopen @var{file}}, if native dlopening is not
@c supported on the host platform (@pxref{Dlopened modules}) or if
@c the program is linked with @samp{-static} or @samp{-all-static}.
@c Otherwise, no effect.  If @var{file} is @code{self} libtool will make
@c sure that the program can @code{dlopen} itself, either by enabling
@c @code{-export-dynamic} or by falling back to @samp{-dlpreopen self}.
@c 
ネイティブな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}
@c Link @var{file} into the output program, and add its symbols to
@c @var{lt_preloaded_symbols} (@pxref{Dlpreopening}).  If @var{file} is
@c @code{self}, the symbols of the program itself will be added to
@c @var{lt_preloaded_symbols}.
@c If @var{file} is @code{force} libtool will make sure that
@c @var{lt_preloaded_symbols} is always @emph{defined}, regardless of whether
@c it's empty or not.
@c 
@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
@c Allow symbols from @var{output-file} to be resolved with @code{dlsym}
@c (@pxref{Dlopened modules}).
@c 
@var{output-file}からのシンボルが@code{dlsym}で解決されることを可能に
します(@pxref{Dlopened modules})．

@item -export-symbols @var{symfile}
@c Tells the linker to export only the symbols listed in @var{symfile}.
@c The symbol file should end in @samp{.sym} and must contain the name of one
@c symbol per line. This option has no effect on some platforms.
@c By default all symbols are exported.
@c 
リンカに@var{symfile}でリストアップされているシンボルのみエクスポート
するよう伝えます．シンボルファイルは@samp{.sym}で終わるべきで，一行ご
とに一シンボル名を含める必要があります．このオプションに効果がないプラッ
トフォームがあります．デフォルトですべてのシンボルがエクスポートされま
す．

@item -export-symbols-regex @var{regex}
@c Same as @samp{-export-symbols}, except that only symbols matching
@c the regular expression @var{regex} are exported.
@c By default all symbols are exported.
@c 
正規表現@var{regex}に一致するシンボルのみエクスポートされる以外，
@samp{-export-symbols}と同じです．デフォルトですべてのシンボルがエクス
ポートされます．

@item -L@var{libdir}
@c Search @var{libdir} for required libraries that have already been
@c installed.
@c 
既にインストールされている，要求されているライブラリに対し，
@var{libdir}を検索します．

@item -l@var{name}
@c @var{output-file} requires the installed library @file{lib@var{name}}.
@c This option is required even when @var{output-file} is not an
@c executable.
@c 
@var{output-file}はインストールされているライブラリ
@file{lib@var{name}}を要求します．このオプションは@var{output-file}が
実行形式でないときも要求されます．

@item -module
@c Creates a library that can be dlopened (@pxref{Dlopened modules}).
@c This option doesn't work for programs.
@c Module names don't need to be prefixed with 'lib'.
@c In order to prevent name clashes, however, 'libname' and 'name'
@c must not be used at the same time in your package.
@c 
dlopen可能なライブラリを作成します(@pxref{Dlopened modules})．このオプ
ションはプログラムでは動作しません．モジュール名の'lib'の前置は不要で
す．しかし，名前の破壊を避けるため，'libname'と'name' パッケージで同時
に使用してはなりません．

@item -no-fast-install
@c Disable fast-install mode for the executable @var{output-file}.  Useful
@c if the program won't be necessarily installed.
@c 
実行形式@var{output-file}の高速インストールモードを利用不可にします．
プログラムをインストールする必要がないとき役に立ちます．

@item -no-install
@c Link an executable @var{output-file} that can't be installed and
@c therefore doesn't need a wrapper script.  Useful if the program is only
@c used in the build tree, e.g., for testing or generating other files.
@c 
インストール不可能で，そのためラップスクリプトが不要な実行形式
@var{output-file}をリンクします．プログラムがビルドツリーでのみ使用さ
れる場合，例えば，テストしたり他のファイルを生成するプログラムに対して
役に立ちます．

@item -no-undefined
@c Declare that @var{output-file} does not depend on any other libraries.
@c Some platforms cannot create shared libraries that depend on other
@c libraries (@pxref{Inter-library dependencies}).
@c 
@var{output-file}が他のライブラリに依存しないことを宣言します．他のラ
イブラリに依存する共有ライブラリを作成不可能なプラットフォームもありま
す(@pxref{Inter-library dependencies})．

@item -o @var{output-file}
@c Create @var{output-file} from the specified objects and libraries.
@c 
指定されたオブジェクトとライブラリから@var{output-file}を作成します．

@item -release @var{release}
@c Specify that the library was generated by release @var{release} of your
@c package, so that users can easily tell which versions are newer than
@c others.  Be warned that no two releases of your package will be binary
@c compatible if you use this flag.  If you want binary compatibility, use
@c the @samp{-version-info} flag instead (@pxref{Versioning}).
@c 
ユーザが他より新しいバージョンを簡単に伝えられるよう，パッケージのリリー
ス@var{release}で生成されたライブラリを指定します．このフラグを使用す
る場合，パッケージの二つのリリースがバイナリ互換でないことを警告されま
す．バイナリ互換が欲しい場合，代わりに@samp{-version-info}フラグを使用
してください(@pxref{Versioning})．

@item -rpath @var{libdir}
@c If @var{output-file} is a library, it will eventually be installed in
@c @var{libdir}.  If @var{output-file} is a program, add @var{libdir} to
@c the run-time path of the program.
@c 
@var{output-file}がlibtoolライブラリの場合，それをビルドするために，バー
ジョン情報@var{current}，@var{revision}，そして@var{age}を使用します
(@pxref{Versioning})．このフラグをパッケージのリリース情報の指定に使用
せず，そのためには@samp{-release}を参照してください．

@item -shrext @var{suffix}
@c If @var{output-file} is a libtool library, replace the system's standard
@c file name extension for shared libraries with @var{suffix} (most systems
@c use @file{.so} here).  This option is helpful in certain cases where an
@c application requires that shared libraries (typically modules) have an
@c extension other than the default one.  Please note you must supply the
@c full file name extension including any leading dot.
@c 
@var{output-file}がlibtoolライブラリの場合，システム標準の共有ライブラ
リに対するファイル名の拡張子を@var{suffix}に置換します(ほとんどのシス
テムでは，これに@file{.so}を使用します)．このオプションは，アプリケー
ションが要求する共有ライブラリ(一般的にはモジュール)の拡張子が，デフォ
ルトのものではない状況で役に立ちます．前置するドットを含めた完全なファ
イル名の拡張子を提供する必要があることに注意してください．

@item -R @var{libdir}
@c If @var{output-file} is a program, add @var{libdir} to its run-time
@c path.  If @var{output-file} is a library, add -R@var{libdir} to its
@c @var{dependency_libs}, so that, whenever the library is linked into a
@c program, @var{libdir} will be added to its run-time path.
@c 
@var{output-file}がプログラムの場合，プログラムの実行時のパスを
@var{libdir}に加えます．@var{output-file}がライブラリの場合，ライブラ
リがプログラムとリンクされるときは，常に@var{libdir}が実行時のパスに加
えられるように，その@var{dependency_libs}に-R@var{libdir}を加えます．

@item -static
@c If @var{output-file} is a program, then do not link it against any
@c uninstalled shared libtool libraries.  If @var{output-file} is a
@c library, then only create a static library.
@c 
@var{output-file}がプログラムの場合，インストールされていない共有ライ
ブラリとリンクしません．@var{output-file}がライブラリの場合，スタティッ
クライブラリのみ作成します．

@item -version-info @var{current}[:@var{revision}[:@var{age}]]
@c If @var{output-file} is a libtool library, use interface version
@c information @var{current}, @var{revision}, and @var{age} to build it
@c (@pxref{Versioning}).  Do @strong{not} use this flag to specify package
@c release information, rather see the @samp{-release} flag.
@c 
@var{output-file}がlibtoolライブラリの場合，それをビルドするために，バー
ジョン情報@var{current}，@var{revision}，そして@var{age}を使用します
(@pxref{Versioning})．このフラグをパッケージのリリース情報の指定に使用
せず，そのためには@samp{-release}を参照してください．

@item -version-number @var{major}[:@var{minor}[:@var{revision}]]
@c If @var{output-file} is a libtool library, compute interface version
@c information so that the resulting library uses the specified major, minor and
@c revision numbers.  This is designed to permit libtool to be used with
@c existing projects where identical version numbers are already used across
@c operating systems.  New projects should use the @samp{-version-info} flag
@c instead.
@c 
@var{output-file}がlibtoolライブラリの場合，結果として得られるライブラ
リが使用する指定されたメジャー，マイナーそしてリビジョンナンバーを使用
するように，インターフェースバージョンの情報を計算します．これは，特定
のバージョンナンバーがすでにオペレーティングシステムで使用されている既
存のプロジェクトで，libtoolが使用できるように設計されています．新しい
プロジェクトでは，代わりに@samp{-version-info}フラグを使用すべきです．

@item -Wl,@var{flag}
@itemx -Xlinker @var{flag}
@c Pass a linker specific flag directly to the linker.
@c 
リンカ指定のフラグを直接リンカに渡します．

@item -XCClinker @var{flag}
@c Pass a link specific flag to the compiler driver (@var{CC}) during linking.
@c 
リンク指定フラグをコンパイラドライバ(@var{CC})にリンク時に渡します．
@end table

@c If the @var{output-file} ends in @samp{.la}, then a libtool library is
@c created, which must be built only from library objects (@samp{.lo} files).
@c The @samp{-rpath} option is required.  In the current implementation,
@c libtool libraries may not depend on other uninstalled libtool libraries
@c (@pxref{Inter-library dependencies}).
@c 
@var{output-file}が@samp{.la}で終わる場合，libtoolライブラリが作成され，
それはライブラリオブジェクト(@samp{.lo}ファイル)のみから作成される必要
があります．@samp{-rpath}オプションは要求されません．現在の実装では，
libtoolライブラリが他のインストールされていないlibtoolライブラリに依存
することはできません(@pxref{Inter-library dependencies})．

@c If the @var{output-file} ends in @samp{.a}, then a standard library is
@c created using @code{ar} and possibly @code{ranlib}.
@c 
@var{output-file}が@samp{.a}で終わる場合，標準的なライブラリは
@code{ar}と，おそらく@code{ranlib}を使用して作成されます．

@cindex partial linking
@cindex linking, partial
@c If @var{output-file} ends in @samp{.o} or @samp{.lo}, then a reloadable object
@c file is created from the input files (generally using @samp{ld -r}).
@c This method is often called @dfn{partial linking}.
@c 
@var{output-file}が@samp{.o}や@samp{.lo}で終わる場合，リロード可能なオ
ブジェクトファイルは，(通常@samp{ld -r}を用いて)入力ファイルから作成さ
れます．この手法は@dfn{部分的なリンク}と呼ばれることが多いです．

@c Otherwise, an executable program is created.
@c 
それ以外の場合，実行可能なプログラムが作成されます．

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

@c For @dfn{execute} mode, the library path is automatically set, then a
@c program is executed.
@c 
@samp{実行}モードに対し，ライブラリパスは自動的に設定され，プログラム
は実行されます．

@c The first of the @var{mode-args} is treated as a program name, with the
@c rest as arguments to that program.
@c 
@var{mode-args}の最初は，プログラム名として扱われ，残りはプログラムの
引数となります．

@c The following components of @var{mode-args} are treated specially:
@c 
以下の@var{mode-args}の組は特別に扱われます．

@table @samp
@item -dlopen @var{file}
@c Add the directory containing @var{file} to the library path.
@c 
ライブラリパスに@var{file}を含むディレクトリを加えます．
@end table

@c This mode sets the library path environment variable according to any
@c @samp{-dlopen} flags.
@c 
このモードは，あらゆる@samp{-dlopen}フラグによって，ライブラリパス環境
変数を設定します．

@c If any of the @var{args} are libtool executable wrappers, then they are
@c translated into the name of their corresponding uninstalled binary, and
@c any of their required library directories are added to the library path.
@c 
すべての@var{args}がlibtoolの実行形式のラッパーの場合，それらは対応す
るインストールされていないバイナリの名前に変換され，それらが要求するす
べてのライブラリディレクトリがライブラリパスに加えられます．

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

@c In @dfn{install} mode, libtool interprets most of the elements of
@c @var{mode-args} as an installation command beginning with 
@c @code{cp}, or a BSD-compatible @code{install} program.
@c 
@dfn{インストール}モードでは，libtoolは@var{mode-args}のほとんどの要素
を，@code{cp}で始まるインストールコマンドやBSD互換の@code{install}プロ
グラムとして解釈します．

@c The following components of @var{mode-args} are treated specially:
@c 
@var{mode-args}の残りは，特別扱いされます．

@table @samp
@item -inst-prefix @var{inst-prefix-dir}
@c When installing into a temporary staging area, rather than the
@c final @var{prefix}, this argument is used to reflect the 
@c temporary path, in much the same way @code{automake} uses
@c @var{DESTDIR}.  For instance, if @var{prefix} is @code{/usr/local},
@c but @var{inst-prefix-dir} is @code{/tmp}, then the object will be
@c installed under @code{/tmp/usr/local/}.  If the installed object 
@c is a libtool library, then the internal fields of that library
@c will reflect only @var{prefix}, not @var{inst-prefix-dir}:
@c 
最終的な@var{prefix}ではなく一時的な保存領域にインストールするとき，こ
の引数は一時的なパスを反映するために使用し，それは@code{automake}で
@var{DESTDIR}を使用する方法とほとんど同じです．例えば，@var{prefix}が
@code{/usr/local}で@var{inst-prefix-dir}が@code{/tmp}の場合，オブジェ
クトは@code{/tmp/usr/local/}にインストールされます．インストールされた
オブジェクトがlibtoolライブラリの場合，ライブラリの内部フィールドは
@var{inst-prefix-dir}ではなく@var{prefix}だけに反映されます．

@example
# Directory that this library needs to be installed in:
libdir='/usr/local/lib'
@end example

@c not
@c 
以下ではありません．

@example
# Directory that this library needs to be installed in:
libdir='/tmp/usr/local/lib'
@end example

@c @code{inst-prefix} is also used to insure that if the installed 
@c object must be relinked upon installation, that it is relinked 
@c against the libraries in @var{inst-prefix-dir}/@var{prefix}, 
@c not @var{prefix}.
@c 
@code{inst-prefix}は，インストールされたオブジェクトがインストール時に
再リンクする必要がある場合にも，それが@var{prefix}ではなく
@var{inst-prefix-dir}/@var{prefix}のライブラリと再リンクするのを確実に
するためにも使用されます．

@c In truth, this option is not really intended for use when calling
@c libtool directly; it is automatically used when @code{libtool --mode=install}
@c calls @code{libtool --mode=relink}.  Libtool does this by 
@c analyzing the destination path given in the original 
@c @code{libtool --mode=install} command and comparing it to the 
@c expected installation path established during @code{libtool --mode=link}.
@c 
実際は，このオプションはlibtoolで直接呼び出すときに使用することが本当
の目的ではありません．それは@code{libtool --mode=install}が
@code{libtool --mode=relink}を呼び出すとき自動的に使用されます．
libtoolは元々の@code{libtool --mode=install}コマンドで与えられたインス
トール先のパスを解析し，@code{libtool --mode=link}で確定した予測される
インストールパスと比較することで，これを行ないます．

@c Thus, end-users need change nothing, and @code{automake}-style
@c @code{make install DESTDIR=/tmp} will Just Work(tm).
@c 
このため，エンドユーザは変更する必要はなく，@code{automake}形式の
@code{make install DESTDIR=/tmp}でJust Work(tm) (うまく動作します)にな
ります．
@end table

@c The rest of the @var{mode-args} are interpreted as arguments to the
@c @code{cp} or @code{install} command.
@c 
残りの@var{mode-args}は，@code{cp}や@code{install}コマンドの引数として
解釈されます．

@c The command is run, and any necessary unprivileged post-installation
@c commands are also completed.
@c 
コマンドが実行され，特権の不要な必要なインストール後のコマンドも完全に
実行されます．

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

@c @dfn{Finish} mode helps system administrators install libtool libraries
@c so that they can be located and linked into user programs.
@c 
@dfn{フィニッシュ}モードは，ユーザプログラムにlibtoolライブラリを配置し
リンクできるよう，システム管理者のインストールを助けます．

@c Each @var{mode-arg} is interpreted as the name of a library directory.
@c Running this command may require superuser privileges, so the
@c @samp{--dry-run} option may be useful.
@c 
それぞれの@var{mode-arg}はライブラリのディレクトリの名前として解釈され
ます．このコマンドの実行は，@samp{--dry-run}オプションが役に立つように，
スーパーユーザの特権を要求するかもしれません．

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

@c @dfn{Uninstall} mode deletes installed libraries, executables and objects.
@c 
@dfn{アンインストール}モードはインストールされているライブラリ，実行形
式，そしてオブジェクトを削除します．

@c The first @var{mode-arg} is the name of the program to use to delete
@c files (typically @file{/bin/rm}).
@c 
@var{mode-arg}の最初はファイルの削除に使用するプログラム名(通常は
@file{/bin/rm})です．

@c The remaining @var{mode-args} are either flags for the deletion program
@c (beginning with a `-'), or the names of files to delete.
@c 
残りの@var{mode-args}は，(`-'で始まる)削除プログラムに対するフラグ，ま
たは削除するファイル名です．

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

@c @dfn{Clean} mode deletes uninstalled libraries, executables, objects
@c and libtool's temporary files associated with them.
@c 
@dfn{クリーン}モードはアンインストールされたライブラリ，実行形式，オブ
ジェクト，そして，それらに関連があるlibtoolの一時ファイルを削除します．

@c The first @var{mode-arg} is the name of the program to use to delete
@c files (typically @file{/bin/rm}).
@c 
最初の@var{mode-arg}は，ファイルを削除するために使用するプログラムの名
前(通常は@file{/bin/rm})です．

@c The remaining @var{mode-args} are either flags for the deletion program
@c (beginning with a `-'), or the names of files to delete.
@c 
残りの@var{mode-args}は削除プログラムに対する(`-'で始まる)フラグ，また
は削除するファイル名です．

@node Integrating libtool
@c @chapter Integrating libtool with your package
@chapter パッケージとlibtoolの統合

@c This chapter describes how to integrate libtool with your packages so
@c that your users can install hassle-free shared libraries.
@c 
この章は，ユーザが混乱せずに共有ライブラリをインストールできるように，
パッケージと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
@c @section Writing @file{Makefile} rules for libtool
@section libtoolに対する@file{Makefile}規則を書く
@cindex Makefile
@cindex Makefile.am
@cindex Makefile.in

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

@c If you want to use libtool in a regular @file{Makefile} (or
@c @file{Makefile.in}), you are on your own.  If you're not using Automake
@c 1.2, and you don't know how to incorporate libtool into your package you
@c need to do one of the following:
@c 
通常の@file{Makefile}(や@file{Makefile.in})で，libtoolを使用したい場合
は，独自のものとなります．Automake 1.2を使用せず，パッケージにlibtool 
の組み込み方を知らない場合，以下の一つが必要になります．

@enumerate 1
@item
@c Download Automake (version 1.2 or later) from your nearest GNU mirror,
@c install it, and start using it.
@c 
Automake(バージョン1.2以降)を近くのGNUのミラーからダウンロードし，イン
ストールし，その使用を開始してください．

@item
@c Learn how to write @file{Makefile} rules by hand.  They're sometimes complex,
@c but if you're clever enough to write rules for compiling your old
@c libraries, then you should be able to figure out new rules for libtool
@c libraries (hint: examine the @file{Makefile.in} in the @file{demo}
@c subdirectory of the libtool distribution@dots{} note especially that it
@c was automatically generated from the @file{Makefile.am} by Automake).
@c 
@file{Makefile}規則の手での書き方を学んでください．複雑なときもありま
すが，古いライブラリをコンパイルするための規則を書けるぐらいの知識があ
る場合，libtoolライブラリに対する新しい規則の理解は可能でしょう(ヒント：
libtool 配布物の@file{demo}サブディレクトリの@file{Makefile.in}を調べ
てください@dots{} 特に，それがAutomakeによって@file{Makefile.am}から自
動的に生成されたことに注意してください)．
@end enumerate

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

@vindex LTLIBRARIES
@c Libtool library support is implemented under the @samp{LTLIBRARIES}
@c primary.
@c 
libtoolライブラリのサポートは，@samp{LTLIBRARIES}プライマリの下で実装
されています．

@c Here are some samples from the Automake @file{Makefile.am} in the
@c libtool distribution's @file{demo} subdirectory.
@c 
libtool配布物の@file{demo}サブディレクトリの，Automake
@file{Makefile.am}からの例は，以下のようになっています．

@c First, to link a program against a libtool library, just use the
@c @samp{program_LDADD} variable:
@c 
最初に，プログラムを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

@c The flags @samp{-dlopen} or @samp{-dlpreopen} (@pxref{Link mode}) would
@c fit better in the @var{program_LDADD} variable.  Unfortunately, GNU
@c automake, up to release 1.4, doesn't accept these flags in a
@c @var{program_LDADD} variable, so you have the following alternatives:
@c 
フラグ@samp{-dlopen}と@samp{-dlpreopen}(@pxref{Link mode})は，
@var{program_LDADD}変数で，より適切になります．残念ながら，リリース1.4 
までのGNU automakeは，@var{program_LDADD}変数でこれらのフラグを受け入
れないため，以下で代用します．

@itemize @bullet
@item
@c add them to @var{program_LDFLAGS}, and list the libraries in
@c @var{program_DEPENDENCIES}, then wait for a release of GNU automake that
@c accepts these flags where they belong;
@c 
それらを@var{program_LDFLAGS}に加え，@var{program_DEPENDENCIES}にライ
ブラリをリストアップし，それらが属するこれらのフラグを受け入れるGNU
automakeのリリースを待ってください．

@item
@c surround the flags between quotes, but then you must set
@c @var{program_DEPENDENCIES} too:
@c 
フラグの回りを引用符で囲みます，しかし，@var{program_DEPENDENCIES}も設
定する必要があります．

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

@item
@c set and @samp{AC_SUBST} variables @var{DLOPEN} and @var{DLPREOPEN} in
@c @file{configure.in} and use @samp{@@DLOPEN@@} and @samp{@@DLPREOPEN@@}
@c as replacements for the explicit flags @samp{-dlopen} and
@c @samp{-dlpreopen} in @samp{program_LDADD}.  Automake will discard
@c @samp{AC_SUBST}ed variables from dependencies, so it will behave exactly
@c as we expect it to behave when it accepts these flags in
@c @samp{program_LDADD}.  But hey!, this is ugly!
@c 
@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

@c You may use the @samp{program_LDFLAGS} variable to stuff in any flags
@c you want to pass to libtool while linking @samp{program} (such as
@c @samp{-static} to avoid linking uninstalled shared libtool libraries).
@c 
(インストールされていない共有libtoolライブラリとのリンクを避けるため
@samp{-static}を使用するような)@samp{program}をリンクしている間，
libtool に渡したいあらゆるフラグを詰め込むため，@samp{program_LDFLAGS}
変数を使用することも可能です．

@c Building a libtool library is almost as trivial@dots{} note the use of
@c @samp{libhello_la_LDFLAGS} to pass the @samp{-version-info}
@c (@pxref{Versioning}) option to libtool:
@c 
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

@c The @samp{-rpath} option is passed automatically by Automake (except for
@c libraries listed as @code{noinst_LTLIBRARIES}), so you
@c should not specify it.
@c 
@samp{-rpath}オプションは，(@code{noinst_LTLIBRARIES}としてリストアッ
プされるライブラリ以外)Automakeにより自動的に渡されるので，指定する必
要はありません．

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

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

@c Libtool requires intimate knowledge of your compiler suite and operating
@c system in order to be able to create shared libraries and link against
@c them properly.  When you install the libtool distribution, a
@c system-specific libtool script is installed into your binary directory.
@c 
libtoolは，共有ライブラリを作成し適切なものにリンクするため，コンパイ
ラセットとオペレーティングシステムの詳細な知識を必要とします．libtool
配布物をインストールするとき，システム特有のlibtoolスクリプトはバイナ
リディレクトリにインストールされます．

@c However, when you distribute libtool with your own packages
@c (@pxref{Distributing}), you do not always know which compiler suite and
@c operating system are used to compile your package.
@c 
しかし，独自のパッケージとともにlibtoolを配布するとき
(@pxref{Distributing})，パッケージをコンパイルするために使用されるコン
パイラセットとオペレーティングシステムを，常に知っているわけではありま
せん．

@c For this reason, libtool must be @dfn{configured} before it can be
@c used.  This idea should be familiar to anybody who has used a GNU
@c @code{configure} script.  @code{configure} runs a number of tests for
@c system features, then generates the @file{Makefiles} (and possibly a
@c @file{config.h} header file), after which you can run @code{make} and
@c build the package.
@c 
このため，libtoolを使用する前に@dfn{コンフィグレーション}する必要があ
ります．この考えは，GNU @code{configure}スクリプトを使用するものに似て
います．@code{configure}は，システムの特徴に対しいくつものテストを行い，
@file{Makefiles}(と，おそらく@file{config.h}ヘッダファイル)を生成し，
その後，@code{make}を実行しパケージをビルドすることが可能です．

@c Libtool adds its own tests to your @code{configure} script in order to
@c generate a libtool script for the installer's host machine.
@c 
libtoolは，インストーラのホストマシンに対するlibtoolスクリプトを生成す
るために，独自のテストを@code{configure}スクリプトに加えます．

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

@node AC_PROG_LIBTOOL
@c @subsection The @code{AC_PROG_LIBTOOL} macro
@subsection @code{AC_PROG_LIBTOOL}マクロ

@c If you are using GNU Autoconf (or Automake), you should add a call to
@c @code{AC_PROG_LIBTOOL} to your @file{configure.in} file.  This macro
@c adds many new tests to the @code{configure} script so that the generated
@c libtool script will understand the characteristics of the host:
@c 
GNU Autoconf(やAutomake)を使用している場合，@code{AC_PROG_LIBTOOL}の呼
び出しを@file{configure.in}に加える必要があります．このマクロは，生成
されたlibtoolスクリプトがホストの特徴を理解できるようにするため，多く
の新しいテストを@code{configure}スクリプトに加えます．

@defmac AC_PROG_LIBTOOL
@defmacx AM_PROG_LIBTOOL
@c Add support for the @samp{--enable-shared} and @samp{--disable-shared}
@c @code{configure} flags.@footnote{@code{AC_PROG_LIBTOOL} requires that
@c you define the @file{Makefile} variable @code{top_builddir} in your
@c @file{Makefile.in}.  Automake does this automatically, but Autoconf
@c users should set it to the relative path to the top of your build
@c directory (@file{../..}, for example).}  @code{AM_PROG_LIBTOOL} was the
@c old name for this macro, and although supported at the moment is
@c deprecated.
@c 
@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}は，このマクロに対する古い名前で，
しばらくはサポートされますが，やめた方がいいでしょう．

@c By default, this macro turns on shared libraries if they are available,
@c and also enables static libraries if they don't conflict with the shared
@c libraries.  You can modify these defaults by calling either the
@c @code{AC_DISABLE_SHARED} or @code{AC_DISABLE_STATIC} macros:
@c 
デフォルトで，このマクロは，利用可能な場合は共有ライブラリを開始し，共
有ライブラリと衝突しない場合はスタティックライブラリも可能とします．こ
れらのデフォルトは，@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

@c The user may specify modified forms of the configure flags
@c @samp{--enable-shared} and @samp{--enable-static} to choose whether
@c shared or static libraries are built based on the name of the package.
@c For example, to have shared @samp{bfd} and @samp{gdb} libraries built,
@c but not shared @samp{libg++}, you can run all three @code{configure}
@c scripts as follows:
@c 
ユーザは，パッケージ名を基にビルドされる，共有またはスタティックライブ
ラリを選択するため，@samp{--enable-shared}と@samp{--enable-static}を
@command{configure}へのフラグとして変更を指定してもかまいません．例え
ば，共有する@samp{bfd} と@samp{gdb}ライブラリをビルドし，@samp{libg++} 
を共有にしないため，以下の@code{configure}スクリプトの実行で，三つのこ
とのすべて可能となります．

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

@c In general, specifying @samp{--enable-shared=@var{pkgs}} is the same as
@c configuring with @samp{--enable-shared} every package named in the
@c comma-separated @var{pkgs} list, and every other package with
@c @samp{--disable-shared}.  The @samp{--enable-static=@var{pkgs}} flag
@c behaves similarly, but it uses @samp{--enable-static} and
@c @samp{--disable-static}. The same applies to the
@c @samp{--enable-fast-install=@var{pkgs}} flag, which uses
@c @samp{--enable-fast-install} and @samp{--disable-fast-install}.
@c 
一般的に，@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}を使用しま
す．

@c The package name @samp{default} matches any packages which have not set
@c their name in the @code{PACKAGE} environment variable.
@c 
パッケージ名@samp{default}は，@code{PACKAGE}環境変数に名前が設定されて
いない，あらゆるパッケージに一致します．

@c This macro also sets the shell variable @var{LIBTOOL_DEPS}, that you can
@c use to automatically update the libtool script if it becomes
@c out-of-date.  In order to do that, add to your @file{configure.in}:
@c 
このマクロは，シェル変数@var{LIBTOOL_DEPS}も設定し，それで，libtoolス
クリプトが時代遅れになった場合の自動的な更新に使用できるようになります．
そうするために@file{configure.in}に以下を加えてください．

@example
AC_PROG_LIBTOOL
AC_SUBST(LIBTOOL_DEPS)
@end example

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

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

@c If you are using GNU automake, you can omit the assignment, as automake
@c will take care of it.  You'll obviously have to create some dependency
@c on @file{libtool}.
@c 
GNU automakeを使用してる場合，automakeが面倒をみるので，指示の省略が可
能です．@file{libtool}での依存性を明確に作成する必要があります．

@end defmac

@defmac AC_LIBTOOL_DLOPEN
@c Enable checking for dlopen support. This macro should be used if
@c the package makes use of the @samp{-dlopen} and @samp{-dlpreopen} flags,
@c otherwise libtool will assume that the system does not support dlopening.
@c The macro must be called @strong{before} @code{AC_PROG_LIBTOOL}.
@c 
dlopenサポートの調査を可能にします．パッケージで@samp{-dlopen}と
@samp{-dlpreopen}フラグを使用する場合，このマクロ使用すべきで，そうし
ない場合，libtoolはシステムがdlopenをサポートしていないと仮定します．
マクロは@code{AC_PROG_LIBTOOL}の@strong{前で}呼び出す必要があります．
@end defmac

@defmac AC_LIBTOOL_WIN32_DLL
@c This macro should be used if the package has been ported to build clean
@c dlls on win32 platforms.  Usually this means that any library data items
@c are exported with @code{__declspec(dllexport)} and imported with
@c @code{__declspec(dllimport)}.  If this macro is not used, libtool will
@c assume that the package libraries are not dll clean and will build only
@c static libraries on win32 hosts.
@c 
このマクロは，win32プラットフォームでクリーンなdllをビルドするために移
植する場合，使用する必要があります．通常これは，あらゆるライブラリデー
タ項目を@code{__declspec(dllexport)}でエクスポートし，
@code{__declspec(dllimport)}でインポートすることを意味します．このマク
ロが使用されていない場合，libtoolはパッケージライブラリがクリーンなdll 
ではなく，win32ホストでのスタティックライブラリのみをビルドすると仮定
します．

@c This macro must be called @strong{before} @code{AC_PROG_LIBTOOL}, and
@c provision must be made to pass @samp{-no-undefined} to @code{libtool}
@c in link mode from the package @code{Makefile}.  Naturally, if you pass
@c @samp{-no-undefined}, you must ensure that all the library symbols
@c @strong{really are} defined at link time!
@c 
このマクロは@code{AC_PROG_LIBTOOL}の@strong{前で}呼び出す必要があり，
パッケージの@code{Makefile}でのリンクモードでの準備として，
@code{libtool}に@samp{-no-undefined}を渡させる必要があります．通常，
@samp{-no-undefined}を渡す場合，すべてのライブラリシンボルが，リンク時
には@strong{本当に}定義されていることを確かめる必要があります！
@end defmac

@defmac AC_DISABLE_FAST_INSTALL
@c Change the default behaviour for @code{AC_PROG_LIBTOOL} to disable
@c optimization for fast installation.  The user may still override this
@c default, depending on platform support, by specifying
@c @samp{--enable-fast-install}.
@c 
@code{AC_PROG_LIBTOOL}のデフォルトの動作を，高速インストールに対する最
適化を不可能にするよう変更します．ユーザはこのデフォルトを，プラット
フォームのサポートに依存して，@samp{--enable-fast-install}を指定するこ
とで優先させることができます．
@end defmac

@defmac AC_DISABLE_SHARED
@defmacx AM_DISABLE_SHARED
@c Change the default behaviour for @code{AC_PROG_LIBTOOL} to disable
@c shared libraries.  The user may still override this default by
@c specifying @samp{--enable-shared}.
@c 
@code{AC_PROG_LIBTOOL}のデフォルトの動作を，共有ライブラリを利用不可能
に変更します．ユーザはこのデフォルトを，@samp{--enable-shared}を指定す
ることで優先させることができます．
@end defmac

@defmac AC_DISABLE_STATIC
@defmacx AM_DISABLE_STATIC
@c Change the default behaviour for @code{AC_PROG_LIBTOOL} to disable
@c static libraries.  The user may still override this default by
@c specifying @samp{--enable-static}.
@c 
@code{AC_PROG_LIBTOOL}のデフォルトの動作を，スタティックライブラリを利
用不可能に変更します．ユーザはこのデフォルトを，@samp{--enable-static}
を指定することで優先させることができます．
@end defmac

@c The tests in @code{AC_PROG_LIBTOOL} also recognize the following
@c environment variables:
@c 
@code{AC_PROG_LIBTOOL}内のテストは，以下の環境変数も認識します．

@defvar CC
@c The C compiler that will be used by the generated @code{libtool}.  If
@c this is not set, @code{AC_PROG_LIBTOOL} will look for @code{gcc} or
@c @code{cc}.
@c 
生成された@code{libtool}が使用するCコンパイラです．これが設定されてい
ない場合，@code{AC_PROG_LIBTOOL}は@code{gcc}や@code{cc}を探します．
@end defvar

@defvar CFLAGS
@c Compiler flags used to generate standard object files.  If this is not
@c set, @code{AC_PROG_LIBTOOL} will not use any such flags.  It affects
@c only the way @code{AC_PROG_LIBTOOL} runs tests, not the produced
@c @code{libtool}.
@c 
標準的なオブジェクトファイルを生成するために使用するコンパイラフラグで
す．これが設定されていない場合，@code{AC_PROG_LIBTOOL}はそのようなフラ
グを全く使用しません．それは，@code{AC_PROG_LIBTOOL}がテストを実行する
方法にのみ効果があり，生成された@code{libtool}には効果はありません．
@end defvar

@defvar CPPFLAGS
@c C preprocessor flags.  If this is not set, @code{AC_PROG_LIBTOOL} will
@c not use any such flags.  It affects only the way @code{AC_PROG_LIBTOOL}
@c runs tests, not the produced @code{libtool}.
@c 
Cプリプロセッサフラグです．これが設定されていない場合，
@code{AC_PROG_LIBTOOL}はそのようなフラグを全く使用しません．それは，
@code{AC_PROG_LIBTOOL}がテストを実行する方法にのみ効果があり，生成され
た@code{libtool}には効果はありません．
@end defvar

@defvar LD
@c The system linker to use (if the generated @code{libtool} requires one).
@c If this is not set, @code{AC_PROG_LIBTOOL} will try to find out what is
@c the linker used by @var{CC}.
@c 
(生成された@code{libtool}が要求する場合は)システムリンカです．これが設
定されていない場合，@code{AC_PROG_LIBTOOL}は，@var{CC}で使用されるリン
カが何かを判別しようとします．
@end defvar

@defvar LDFLAGS
@c The flags to be used by @code{libtool} when it links a program.  If
@c this is not set, @code{AC_PROG_LIBTOOL} will not use any such flags.  It
@c affects only the way @code{AC_PROG_LIBTOOL} runs tests, not the produced
@c @code{libtool}.
@c 
プログラムをリンクするとき，@code{libtool}が使用するフラグです．これが
設定されていない場合，@code{AC_PROG_LIBTOOL}はそのようなフラグを全く使
用しません．それは，@code{AC_PROG_LIBTOOL}がテストを実行する方法にのみ
効果があり，生成された@code{libtool}には効果はありません．
@end defvar

@defvar LIBS
@c The libraries to be used by @code{AC_PROG_LIBTOOL} when it links a
@c program.  If this is not set, @code{AC_PROG_LIBTOOL} will not use any
@c such flags.  It affects only the way @code{AC_PROG_LIBTOOL} runs tests,
@c not the produced @code{libtool}.
@c 
プログラムのリンクとき，@code{AC_PROG_LIBTOOL}が使用するライブラリです．
これが設定されていない場合，@code{AC_PROG_LIBTOOL}はそのようなフラグを
使用しません．それは@code{AC_PROG_LIBTOOL}が実行するテストにのみに効果
があり，生成された@code{libtool}には効果はありません．
@end defvar

@defvar NM
@c Program to use rather than checking for @code{nm}.
@c 
使用するプログラムで，@code{nm}の調査ではありません．
@end defvar

@defvar RANLIB
@c Program to use rather than checking for @code{ranlib}.
@c 
使用するプログラムで，@code{ranlib}の調査ではありません．
@end defvar

@defvar LN_S
@c A command that creates a link of a program, a soft-link if possible, a
@c hard-link otherwise.  @code{AC_PROG_LIBTOOL} will check for a suitable
@c program if this variable is not set.
@c 
プログラムのリンクを作成するコマンドで，可能な場合はソフトリンク，それ
以外ではハードリンクです．この変数が設定されていない場合，
@code{AC_PROG_LIBTOOL}は適切なプログラムを調査します．
@end defvar

@defvar DLLTOOL
@c Program to use rather than checking for @code{dlltool}.  Only meaningful
@c for Cygwin/MS-Windows.
@c 
使用するプログラムで，@code{dlltool}の調査ではありません．
Cygwin/MS-Windowsでのみ意味があります．
@end defvar

@defvar OBJDUMP
@c Program to use rather than checking for @code{objdump}.  Only meaningful
@c for Cygwin/MS-Windows.
@c 
使用するプログラムで，@code{objdump}の調査ではありません．
Cygwin/MS-Windowsでのみ意味があります．
@end defvar

@defvar AS
@c Program to use rather than checking for @code{as}.  Only used on
@c Cygwin/MS-Windows at the moment.
@c 
使用するプログラムで，@code{as}の調査ではありません．しばらくは，
Cygwin/MS-Windows でのみ使用されます．
@end defvar

@pindex aclocal
@c When you invoke the @code{libtoolize} program (@pxref{Invoking
@c libtoolize}), it will tell you where to find a definition of
@c @code{AC_PROG_LIBTOOL}.  If you use Automake, the @code{aclocal} program
@c will automatically add @code{AC_PROG_LIBTOOL} support to your
@c @code{configure} script.
@c 
@code{libtoolize}プログラムを呼び出すとき(@pxref{Invoking libtoolize})，
それは@code{AC_PROG_LIBTOOL}の定義が見つかる場所を伝えます．Automakeを
使用している場合，@code{aclocal}プログラムは自動的に，@code{configure}
スクリプトに@code{AC_PROG_LIBTOOL}サポートを@code{configure}スクリプト
に加えます．

@c Nevertheless, it is advisable to include a copy of @file{libtool.m4} in
@c @file{acinclude.m4}, so that, even if @file{aclocal.m4} and
@c @file{configure} are rebuilt for any reason, the appropriate libtool
@c macros will be used.  The alternative is to hope the user will have a
@c compatible version of @file{libtool.m4} installed and accessible for
@c @code{aclocal}.  This may lead to weird errors when versions don't
@c match.
@c 
それにもかかわらず，@file{acinclude.m4}に@file{libtool.m4}のコピーを含
めることは賢明で，そのため，@file{aclocal.m4}と@file{configure}がなん
らかの理由で再びビルドされた場合も，適切なlibtoolマクロが使用されます．
代わりに，ユーザが@file{libtool.m4}の互換バージョンをインストールして
いて，@code{aclocal}にアクセス可能なことを期待します．これは，バージョ
ンが一致しない場合，不運なエラーを導くかもしれません．

@node Distributing
@c @section Including libtool in your package
@section パッケージにlibtoolを含める

@c In order to use libtool, you need to include the following files with
@c your package:
@c 
libtoolを使用するため，パッケージに以下のファイルを含める必要があります．

@table @file
@item config.guess
@pindex config.guess
@c Attempt to guess a canonical system name.
@c 
標準的なシステム名の判別を試みます．

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

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

@c Note that the libtool script itself should @emph{not} be included with
@c your package.  @xref{Configuring}.
@c 
libtoolスクリプト自身はパッケージに含まれないことに注意してください．
@xref{Configuring}.

@c You should use the @code{libtoolize} program, rather than manually
@c copying these files into your package.
@c 
手動でこれらのファイルをパッケージにコピーするより，@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
@c @subsection Invoking @code{libtoolize}
@subsection @code{libtoolize}の呼び出し
@pindex libtoolize
@cindex libtoolize command options
@cindex command options, libtoolize
@cindex options, libtoolize command

@c The @code{libtoolize} program provides a standard way to add libtool
@c support to your package.  In the future, it may implement better usage
@c checking, or other features to make libtool even easier to use.
@c 
@code{libtoolize}プログラムは，libtoolサポートをパッケージに追加する標
準的な方法を提供します．将来は，より良い調査の使用法や，より簡単に
libtoolを作成する機能を実装するかもしれません．

@c The @code{libtoolize} program has the following synopsis:
@c 
@code{libtoolize}プログラムは以下の構文です．

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

@noindent
@c and accepts the following options:
@c 
そして，以下のオプションを受け入れます．

@table @samp
@item --automake
@c Work silently, and assume that Automake libtool support is used.
@c 
静かに動作し，libtoolがサポートされているAutomakeを仮定します．

@c @samp{libtoolize --automake} is used by Automake to add libtool files to
@c your package, when @code{AC_PROG_LIBTOOL} appears in your
@c @file{configure.in}.
@c 
@samp{libtoolize --automake}は，@code{AC_PROG_LIBTOOL}が
@file{configure.in}にあるとき，Automakeがlibtoolファイルをパッケージに
追加するために使用します．

@item --copy
@itemx -c
@c Copy files from the libtool data directory rather than creating
@c symlinks.
@c 
libtoolデータディレクトリから，シンボリックリンクを作成するのではなく，
ファイルをコピーします．

@item --debug
@c Dump a trace of shell script execution to standard output.  This
@c produces a lot of output, so you may wish to pipe it to @code{less} (or
@c @code{more}) or redirect to a file.
@c 
シェルスクリプトの実行の追跡を，標準出力にダンプします．これは大量の出
力を生成するため，@code{less}(や@code{more})にパイプしたり，ファイルに
リダイレクトしたいかもしれません．

@item --dry-run
@itemx -n
@c Don't run any commands that modify the file system, just print them
@c out.
@c 
ファイルシステムを変更するコマンドは実行せず，それらを出力するだけです．

@item --force
@itemx -f
@c Replace existing libtool files.  By default, @code{libtoolize} won't
@c overwrite existing files.
@c 
既存のlibtoolのファイルを置換します．デフォルトで，@code{libtoolize}は
既存のファイルを上書きしません．

@item --help
@c Display a help message and exit.
@c 
へルプメッセージを出力し終了します．

@item --ltdl
@c Install libltdl in a subdirectory of your package.
@c 
パッケージのサブディレクトリに，libltdlをインストールします．

@item --ltdl-tar
@c Add the file libltdl.tar.gz to your package.
@c 
ファイルlibltdl.tar.gzをパッケージに追加します．

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

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

@c @code{libtoolize} displays hints for adding libtool support to your
@c package, as well.
@c 
@code{libtoolize}は，パッケージにlibtoolサポートを加えるヒントも同様に
表示します．

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

@c The Autoconf package comes with a few macros that run tests, then set a
@c variable corresponding to the name of an object file.  Sometimes it is
@c necessary to use corresponding names for libtool objects.
@c 
Autoconfパッケージは，テストを実行するいくつかのマクロをもたらし，それ
は，オブジェクトファイル名に対応して変数を設定します．libtoolオブジェ
クトに対応する名前を使用する必要があるときもあります．

@c Here are the names of variables that list libtool objects:
@c 
libtoolオブジェクトがリストアップする変数名には以下のものがあります．

@defvar LTALLOCA
@findex AC_FUNC_ALLOCA
@c Substituted by @code{AC_FUNC_ALLOCA} (@pxref{Particular Functions, Particular
@c Function Checks, The Autoconf Manual, autoconf, The Autoconf
@c Manual}).  Is either empty, or contains @samp{alloca.lo}.
@c 
@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
@c Substituted by @code{AC_REPLACE_FUNCS} (@pxref{Generic Functions, Generic
@c Function Checks, The Autoconf Manual, autoconf, The Autoconf
@c Manual}), and a few other functions.
@c 
@code{AC_REPLACE_FUNCS}(@pxref{Generic Functions, Generic Function
Checks, The Autoconf Manual, autoconf, The Autoconf Manual})とその他の
関数で置換されます．
@end defvar

@c Unfortunately, the stable release of Autoconf (2.13, at the time of
@c this writing) does not have any way for libtool to provide support for
@c these variables.  So, if you depend on them, use the following code
@c immediately before the call to @code{AC_OUTPUT} in your
@c @file{configure.in}:
@c 
残念ながら，安定版のリリースの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
@c @section 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

@c When you are developing a package, it is often worthwhile to configure
@c your package with the @samp{--disable-shared} flag, or to override the
@c defaults for @code{AC_PROG_LIBTOOL} by using the
@c @code{AC_DISABLE_SHARED} Autoconf macro (@pxref{AC_PROG_LIBTOOL, , The
@c @code{AC_PROG_LIBTOOL} macro}).  This prevents libtool from building
@c shared libraries, which has several advantages:
@c 
パッケージを開発しているとき，パッケージを@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
@c compilation is twice as fast, which can speed up your development cycle,
@c 
二回目のコンパイルを速くし，開発サイクルを高速にします．

@item
@c debugging is easier because you don't need to deal with any complexities
@c added by shared libraries, and
@c 
共有ライブラリによって加えられる複雑さの詳細が不要なので，デバッグがよ
り簡単になります．

@item
@c you can see how libtool behaves on static-only platforms.
@c 
スタティックのみのプラットフォームでのlibtoolの動作方法が分かります．
@end itemize

@c You may want to put a small note in your package @file{README} to let
@c other developers know that @samp{--disable-shared} can save them time.
@c The following example note is taken from the GIMP@footnote{GNU Image
@c Manipulation Program, for those who haven't taken the plunge.  See
@c @url{http://www.gimp.org/}.} distribution @file{README}:
@c 
パッケージの@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
@c @chapter Library interface versions
@chapter ライブラリインターフェースのバージョン
@cindex dynamic dependencies
@cindex dependency versioning
@cindex shared library versions

@c The most difficult issue introduced by shared libraries is that of
@c creating and resolving runtime dependencies.  Dependencies on programs
@c and libraries are often described in terms of a single name, such as
@c @code{sed}.  So, one may say ``libtool depends on sed,'' and that is
@c good enough for most purposes.
@c 
共有ライブラリで導入された発行物で，最も難しいものは，実行時の依存性の
作成と解決です．プログラムとライブラリの依存性は，@code{sed}のような単
一の名前の用語で，よく記述されます．そのため``libtoolはsedに依存する''
と告げ，それで十分目的を果たせます．

@c However, when an interface changes regularly, we need to be more
@c specific: ``Gnus 5.1 requires Emacs 19.28 or above.''  Here, the
@c description of an interface consists of a name, and a ``version
@c number.''
@c 
しかし，規則的にインターフェースが変更されるとき，我々はより具体的に告
げる必要があります．``Gnus 5.1はEmacs 19.28以上を要求する．''ここでは，
名前からなるインターフェースの記述と``バージョンナンバー''です．

@c Even that sort of description is not accurate enough for some purposes.
@c What if Emacs 20 changes enough to break Gnus 5.1?
@c 
種類の説明はいくつかの目的において十分でないことすらあります．Emacs 20
で変更された場合，Gnus 5.1を破壊するのに十分ではないでしょうか？

@c The same problem exists in shared libraries: we require a formal version
@c system to describe the sorts of dependencies that programs have on
@c shared libraries, so that the dynamic linker can guarantee that programs
@c are linked only against libraries that provide the interface they
@c require.
@c 
同じ問題は，共有ライブラリでも存在します．我々は，プログラムが必要とし
ているインターフェースを提供するライブラリのみとリンクされることを，ダ
イナミックリンカが保証できるように，プログラムが依存する共有ライブラリ
を記述するために，公式なバージョン管理システムが必要です．

@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
@c @section What are library interfaces?
@section ライブラリインターフェースとは？
@cindex library interfaces

@c Interfaces for libraries may be any of the following (and more):
@c 
ライブラリのインターフェースは，以下の何か(またはそれ以上)でしょう．

@itemize @bullet
@item
@c global variables: both names and types
@c 
グローバル変数: 名前と型

@item
@c global functions: argument types and number, return types, and function names
@c 
グローバル関数: 引数の型と数，返り値の型，関数名

@item
@c standard input, standard output, standard error, and file formats
@c 
標準入力，標準出力，標準エラー，そしてファイル形式

@item
@c sockets, pipes, and other inter-process communication protocol formats
@c 
ソケット，パイプ，プロセス間通信のプロトコル書式
@end itemize

@c Note that static functions do not count as interfaces, because they are
@c not directly available to the user of the library.
@c 
スタティック関数は，ライブラリのユーザが直接利用不可能なので，インター
フェースに数えられないことに注意してください．

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

@c Libtool has its own formal versioning system.  It is not as flexible as
@c some, but it is definitely the simplest of the more powerful versioning
@c systems.
@c 
libtoolは独自の公式のバージョン管理システムがあります．それは，あまり
柔軟ではありませんが，強力なバージョン管理システムで，確かに最も単純で
す．

@c Think of a library as exporting several sets of interfaces, arbitrarily
@c represented by integers.  When a program is linked against a library, it
@c may use any subset of those interfaces.
@c 
ライブラリとは，整数で任意に表示できるインターフェースのいくつかの組を
エクスポートするものだと考えて下さい．プログラムがライブラリとリンクさ
れるとき，これらのインターフェースのサブセットを利用するかもしれません．

@c Libtool's description of the interfaces that a program uses is simple:
@c it encodes the least and the greatest interface numbers in the resulting
@c binary (@var{first-interface}, @var{last-interface}).
@c 
プログラムが使用するインターフェースのlibtoolの記述は単純です．それは，
結果のバイナリにある最大と最小のインターフェースの番号を符号化します
(@var{first-interface}, @var{last-interface})．

@c The dynamic linker is guaranteed that if a library supports @emph{every}
@c interface number between @var{first-interface} and @var{last-interface},
@c then the program can be relinked against that library.
@c 
ダイナミックリンカは，ライブラリが@var{first-interface}と
@var{last-interface}の間の@emph{すべての}インターフェースの番号をサポー
トする場合，プログラムがライブラリとリンク可能なことを保証します．

@c Note that this can cause problems because libtool's compatibility
@c requirements are actually stricter than is necessary.
@c 
libtoolの移植性の要求が，実際に必要と言うよりは厳密なので，問題を生じ
る可能性があることに注意してください．

@c Say @file{libhello} supports interfaces 5, 16, 17, 18, and 19, and that
@c libtool is used to link @file{test} against @file{libhello}.
@c 
さて，@file{libhello}がインターフェースの5，16，17，18，と19をサポート
し，libtoolは@file{libhello}を@file{test}にリンクするとき使用されると
仮定します．

@c Libtool encodes the numbers 5 and 19 in @file{test}, and the dynamic
@c linker will only link @file{test} against libraries that support
@c @emph{every} interface between 5 and 19.  So, the dynamic linker refuses
@c to link @file{test} against @file{libhello}!
@c 
libtoolは@file{test}に数字5と19を符号化し，ダイナミックリンカは，5と19
の間の@emph{すべての}インターフェースをサポートしているライブラリのみ
と，@file{test}をリンクします．そのため，ダイナミックリンカは
@file{libhello}と@file{test}をリンクすることを拒否するのです！

@c In order to eliminate this problem, libtool only allows libraries to
@c declare consecutive interface numbers.  So, @file{libhello} can declare at
@c most that it supports interfaces 16 through 19.  Then, the dynamic
@c linker will link @file{test} against @file{libhello}.
@c 
この問題を排除するために，libtoolはライブラリは，連続したインターフェー
ス番号を宣言することのみ可能としています．そのため，@file{libhello}は，
16 から19までのインターフェースをサポートすることを宣言するのが精一杯
です．そして，ダイナミックリンカは，@file{libhello}を@file{test}とリン
クします．

@c So, libtool library versions are described by three integers:
@c 
そのため，libtoolライブラリバージョンは，三つの整数で宣言されます．

@table @var
@item current
@c The most recent interface number that this library implements.
@c 
このライブラリで実装されている，最も新しいインターフェース番号．

@item revision
@c The implementation number of the @var{current} interface.
@c 
@var{current}のインターフェースの実装番号．

@item age
@c The difference between the newest and oldest interfaces that this
@c library implements.  In other words, the library implements all the
@c interface numbers in the range from number @code{@var{current} -
@c @var{age}} to @code{@var{current}}.
@c 
このライブラリで実装されている，最新と最古のインターフェースの違い．言
い換えると，ライブラリは，@code{@var{current} - @var{age}}から
@code{@var{current}}までの番号の範囲で，すべてのインターフェース番号を
実装しています．
@end table

@c If two libraries have identical @var{current} and @var{age} numbers,
@c then the dynamic linker chooses the library with the greater
@c @var{revision} number.
@c 
二つのライブラリが，個別の@var{current}と@var{age}を持つ場合，ダイナミッ
クリンカは，より大きい@var{revision}番号を選択します．

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

@c If you want to use libtool's versioning system, then you must specify
@c the version information to libtool using the @samp{-version-info} flag
@c during link mode (@pxref{Link mode}).
@c 
libtoolのバージョン管理システムを使用したい場合，リンクモード
(@pxref{Link mode})で，@samp{-version-info}フラグを使用して，libtool 
にバージョン情報を指定する必要があります．

@c This flag accepts an argument of the form
@c @samp{@var{current}[:@var{revision}[:@var{age}]]}.  So, passing
@c @samp{-version-info 3:12:1} sets @var{current} to 3, @var{revision} to
@c 12, and @var{age} to 1.
@c 
このフラグは，@samp{@var{current}[:@var{revision}[:@var{age}]]}の形式
の引数を受け入れます．そして，@samp{-version-info 3:12:1}を渡すと，
@var{current}を3，@var{revision}を12，そして@var{age}を1に設定します．

@c If either @var{revision} or @var{age} are omitted, they default to 0.
@c Also note that @var{age} must be less than or equal to the @var{current}
@c interface number.
@c 
@var{revision}や@var{age}が省略された場合，デフォルトは0になります．ま
た，@var{age}は@var{current}インターフェース番号以下にする必要があるこ
とに注意してください．

@c Here are a set of rules to help you update your library version
@c information:
@c 
ライブラリバージョン情報を更新する助けとなる規則の集合は，以下のように
なります．

@enumerate 1
@item
@c Start with version information of @samp{0:0:0} for each libtool library.
@c 
バージョン情報は，それぞれのlibtoolライブラリに対し@samp{0:0:0}で始めて
ください．

@item
@c Update the version information only immediately before a public release
@c of your software.  More frequent updates are unnecessary, and only
@c guarantee that the current interface number gets larger faster.
@c 
ソフトウェアの一般へのリリースの直前にのみ，バージョン情報を更新してく
ださい．より頻繁な更新は不要で，現在のインターフェース番号が速くなるこ
とを確実にするだけです．

@item
@c If the library source code has changed at all since the last update,
@c then increment @var{revision} (@samp{@var{c}:@var{r}:@var{a}} becomes
@c @samp{@var{c}:@math{r+1}:@var{a}}).
@c 
前回の更新から，ライブラリソースコードが完全に変更された場合，
@var{revision}を増加してください(@samp{@var{c}:@var{r}:@var{a}}は
@samp{@var{c}:@math{r+1}:@var{a}}となります)．

@item
@c If any interfaces have been added, removed, or changed since the last
@c update, increment @var{current}, and set @var{revision} to 0.
@c 
前回の更新から，インターフェースが加えられた，削除された，または変更さ
れた場合，@var{current}を増加し，@var{revision}を0に設定してください．

@item
@c If any interfaces have been added since the last public release, then
@c increment @var{age}.
@c 
前回の一般へのリリースから，あるインターフェースが削除された場合，
@var{age}を0に設定してください．

@item
@c If any interfaces have been removed since the last public release, then
@c set @var{age} to 0.
@c 
前回の一般へのリリースから，あるインターフェースが削除された場合，
@var{age}を0に設定してください．
@end enumerate

@c @strong{@emph{Never}} try to set the interface numbers so that they
@c correspond to the release number of your package.  This is an abuse that
@c only fosters misunderstanding of the purpose of library versions.
@c Instead, use the @samp{-release} flag (@pxref{Release numbers}), but be
@c warned that every release of your package will not be binary compatible
@c with any other release.
@c 
パッケージのリリース番号に対応するように，インターフェース番号を設定す
る試みは@strong{@emph{決して}}しないでください．これは，ライブラリバー
ジョンの目的の誤解を促進する悪習にすぎません．その代わり，
@samp{-release}フラグ(@pxref{Release numbers})を使用しますが，パッケー
ジが他のリリースとバイナリ互換でないことを警告されます．

@node Release numbers
@c @section Managing release information
@section リリース情報の管理

@c Often, people want to encode the name of the package release into the
@c shared library so that it is obvious to the user which package their
@c programs are linked against.  This convention is used especially on
@c GNU/Linux:
@c 
プログラムをライブラリにリンクしたいユーザに明確になるように，パッケー
ジリリース名を共有ライブラリに符号化したいこともよくあります．この便利
さは，特に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

@c On @samp{trick}, @file{/usr/lib/libbfd.so} is a symbolic link to
@c @file{libbfd.so.2.7.0.2}, which was distributed as a part of
@c @samp{binutils-2.7.0.2}.
@c 
@samp{trick}として，@file{/usr/lib/libbfd.so}は
@file{libbfd.so.2.7.0.2} へのシンボリックリンクで，それは
@samp{binutils-2.7.0.2}の一部として配布されています．

@c Unfortunately, this convention conflicts directly with libtool's idea of
@c library interface versions, because the library interface rarely changes
@c at the same time that the release number does, and the library suffix is
@c never the same across all platforms.
@c 
ライブラリインターフェースは，リリース番号のように，滅多に同時に変更さ
れず，ライブラリ接尾子はすべてのプラットフォームを跨り，すべて同じでは
ないので，残念ながらこの便利さはlibtoolのライブラリバージョンの情報の
考えと直接衝突します．

@c So, in order to accommodate both views, you can use the @samp{-release}
@c flag in order to set release information for libraries which you do not
@c want to use @samp{-version-info}.  For the @file{libbfd} example, the
@c next release which uses libtool should be built with @samp{-release
@c 2.9.0}, which will produce the following files on GNU/Linux:
@c 
そのため，両方の見方に適応するため，@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

@c In this case, @file{/usr/lib/libbfd.so} is a symbolic link to
@c @file{libbfd-2.9.0.so}.  This makes it obvious that the user is dealing
@c with @samp{binutils-2.9.0}, without compromising libtool's idea of
@c interface versions.
@c 
この場合，@file{/usr/lib/libbfd.so}は@file{libbfd-2.9.0.so}へのシンボ
リックリンクです．これは@samp{binutils-2.9.0}を扱っているユーザにとっ
て，バージョン情報のlibtoolの考えに妥協することなく，明白になります．

@c Note that this option causes a modification of the library name, so do
@c not use it unless you want to break binary compatibility with any past
@c library releases.  In general, you should only use @samp{-release} for
@c package-internal libraries or for ones whose interfaces change very
@c frequently.
@c 
このオプションはライブラリ名を編集することに注意し，過去のライブラリリ
リースとのバイナリ互換を壊したくない場合は使用しないでください．一般的
に，パッケージの内部ライブラリや，大変頻繁に変更されるインターフェース
を持つ物に対してのみ@samp{-release}を使用してください．

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

@c Writing a good library interface takes a lot of practice and thorough
@c understanding of the problem that the library is intended to solve.
@c 
良いライブラリインターフェースと書くことは，多くの経験とライブラリが解
決する問題への完全な理解が必要です．

@c If you design a good interface, it won't have to change often, you won't
@c have to keep updating documentation, and users won't have to keep
@c relearning how to use the library.
@c 
良いインターフェースを設計した場合，頻繁に変更する必要がなく，ドキュメ
ントを更新し続ける必要がなく，ユーザはライブラリの使用方法を何度も学習
する必要がありません．

@c Here is a brief list of tips for library interface design, which may
@c help you in your exploits:
@c 
ここにライブラリインターフェースの設計に関するヒントの短いリストがあり，
それは仕事上で役立つでしょう．

@table @asis
@c @item Plan ahead
@item 計画前
@c Try to make every interface truly minimal, so that you won't need to
@c delete entry points very often.
@c 
エントリポイントを頻繁に削除する必要がないように，すべてのインターフェー
スを本当に最小限にするように試みてください．

@c @item Avoid interface changes
@item インターフェースの変更を避ける
@cindex renaming interface functions
@c Some people love redesigning and changing entry points just for the heck
@c of it (note: @emph{renaming} a function is considered changing an entry
@c point).  Don't be one of those people.  If you must redesign an
@c interface, then try to leave compatibility functions behind so that
@c users don't need to rewrite their existing code.
@c 
エントリポイントの再設計と変更を地獄のように繰り返すのが好きな人もいま
す(注意：関数の@emph{名前変更}はエントリポイントの変更と考えられます)．
インターフェースを再設計する必要がある場合，ユーザが既存のコードを書き
換える必要がないように，互換機能を残すことを試みてください．

@c @item Use opaque data types
@item 不透明なデータ型の使用
@cindex opaque data types
@c The fewer data type definitions a library user has access to, the
@c better.  If possible, design your functions to accept a generic pointer
@c (which you can cast to an internal data type), and provide access
@c functions rather than allowing the library user to directly manipulate
@c the data.
@c That way, you have the freedom to change the data structures without
@c changing the interface.
@c 
ライブラリユーザがアクセスするデータ型の定義は，少ないければ少ないほど
良いでしょう．可能な場合，一般的な(内部データにキャスト可能な)ポインタ
を受け入れる関数を設計し，ライブラリユーザが直接データを操作するのを許
可するのではなく，アクセスする関数を提供してください．そうすることで，
インターフェースを変更せずに，データ構造を変更することが自由になります．

@c This is essentially the same thing as using abstract data types and
@c inheritance in an object-oriented system.
@c 
これは，本質的にオブジェクト指向のシステムで抽象的なデータ型と継承を使
用するのと同じです．

@c @item Use header files
@item ヘッダファイルの使用
@cindex header files
@c If you are careful to document each of your library's global functions
@c and variables in header files, and include them in your library source
@c files, then the compiler will let you know if you make any interface
@c changes by accident (@pxref{C header files}).
@c 
ライブラリのグローバル関数と変数のそれぞれのドキュメントをヘッダファイ
ルに注意して書いていて，ライブラリソースファイルに含めている場合，コン
パイラは偶然にインターフェースの変更の有無を知らせるでしょう(@pxref{C
header files})．

@c @item Use the @code{static} keyword (or equivalent) whenever possible
@item 可能な場所での@code{static}キーワード(またはその等価物)の使用
@cindex global functions
@c The fewer global functions your library has, the more flexibility you'll
@c have in changing them.  Static functions and variables may change forms
@c as often as you like@dots{} your users cannot access them, so they
@c aren't interface changes.
@c 
ライブラリが持つグローバル関数は，減らせば減らすほど，より柔軟に変更で
きます．スタティック関数と変数は，形式を変更したいとき変更できます
@dots{}ユーザはそれらにアクセスできず，そのためインターフェースは変更
されません．

@c @item Be careful with array dimensions
@item 配列の次元に対する注意
@c The number of elements in a global array is part of an interface, even
@c if the header just declares @code{extern int foo[];}.  This is because
@c on i386 and some other SVR4/ELF systems, when an application
@c references data in a shared library the size of that data (whatever
@c its type) is included in the application executable.  If you might
@c want to change the size of an array or string then provide a pointer
@c not the actual array.
@c 
大域的な配列の要素数は，たとえヘッダで@code{extern int foo[];}と宣言し
ていたとしても，それはインターフェースの一部です．これはi386とその他の
SVR4/ELFシステムでは，アプリケーションが共有ライブラリのデータを参照す
る時，データのサイズ(と型)はアプリケーションの実行形式に含められます．
配列や文字列の大きさを変更したくなければ，配列ではなくポインタとして提
供してください．
@end table

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

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

@c Writing portable C header files can be difficult, since they may be read
@c by different types of compilers:
@c 
移植性の高いCヘッダファイルを書くことは難しく，それは異なる形式のコン
パイラで読まれる可能性があるためです．

@table @asis
@c @item C++ compilers
@item C++コンパイラ
@c C++ compilers require that functions be declared with full prototypes,
@c since C++ is more strongly typed than C.  C functions and variables also
@c need to be declared with the @code{extern "C"} directive, so that the
@c names aren't mangled.  @xref{C++ libraries}, for other issues relevant
@c to using C++ with libtool.
@c 
C++コンパイラは，Cより強固に形式化されているため，完全なプロトタイプで
宣言された関数を要求します．C関数と変数は，名前がおかしくならないよう
に，@code{extern "C"}ディレクティブで宣言する必要があります．libtool 
でC++の使用に関連したその他の問題は，@xref{C++ libraries}.

@c @item ANSI C compilers
@item ANSI Cコンパイラ
@c ANSI C compilers are not as strict as C++ compilers, but functions
@c should be prototyped to avoid unnecessary warnings when the header file
@c is @code{#include}d.
@c 
ANSI Cコンパイラは，C++コンパイラほど厳密ではありませんが，関数のプロ
トタイプは，ヘッダファイルを@code{#include}したときの不必要な警告を避
けるため，行う方が良いでしょう．

@c @item non-ANSI C compilers
@item 非ANSI Cコンパイラ
@c Non-ANSI compilers will report errors if functions are prototyped.
@c 
Non-ANSIコンパイラは，関数がプロトタイプされている場合，エラーを報告し
ます．
@end table

@c These complications mean that your library interface headers must use
@c some C preprocessor magic in order to be usable by each of the above
@c compilers.
@c 
これらの複雑さは，上記それぞれのコンパイラを利用可能にするため，ライブ
ラリインファーフェースヘッダで，いくつかのCプリプロセッサの魔法を使用
する必要があることを意味します．

@c @file{foo.h} in the @file{demo} subdirectory of the libtool distribution
@c serves as an example for how to write a header file that can be
@c safely installed in a system directory.
@c 
libtool配布物の@file{demo}サブディレクトリの@file{foo.h}は，安全にシス
テムディレクトリにインストール可能な，ヘッダファイルの書き方の例を提供
します．

@c Here are the relevant portions of that file:
@c 
そのファイルの関連する部分は，以下のようになっています．

@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

@c These macros are used in @file{foo.h} as follows:
@c 
これらのマクロは，以下のように@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

@c Note that the @file{#ifndef FOO_H} prevents the body of @file{foo.h}
@c from being read more than once in a given compilation.
@c 
@file{#ifndef FOO_H}が，@file{foo.h}の本体を，与えられたコンパイルで一
回以上読み込むことを避けることに注意してください．

@c Also the only thing that must go outside the
@c @code{BEGIN_C_DECLS}/@code{END_C_DECLS} pair are @code{#include} lines.
@c Strictly speaking it is only C symbol names that need to be protected,
@c but your header files will be more maintainable if you have a single
@c pair of of these macros around the majority of the header contents.
@c 
また，@code{BEGIN_C_DECLS}/@code{END_C_DECLS}の組の外側あるものだけが，
@code{#include}行にあります．厳密にいうと，それは，保護が必要なCのシン
ボル名ですが，ヘッダの内容の中心周辺にこれらのマクロの単一の組がある場
合，ヘッダファイルはより管理しやすくなります．

@c You should use these definitions of @code{PARAMS}, @code{BEGIN_C_DECLS},
@c and @code{END_C_DECLS} into your own headers.  Then, you may use them to
@c create header files that are valid for C++, ANSI, and non-ANSI
@c compilers@footnote{We used to recommend @code{__P},
@c @code{__BEGIN_DECLS} and @code{__END_DECLS}.  This was bad advice since
@c symbols (even preprocessor macro names) that begin with an underscore
@c are reserved for the use of the compiler.}.
@c 
@code{PARAMS}，@code{BEGIN_C_DECLS}，そして@code{END_C_DECLS}のこれら
の定義を独自のヘッダで使用すべきです．そして，C++，ANSI，そして非ANSI
のコンパイラ@footnote{我々は，@code{__P}，@code{__BEGIN_DECLS}そして
@code{__END_DECLS}の使用を推奨していました．アンダースコアで始まるシン
ボル(とプリプロセッサマクロさえも)がコンパイラの使用で予約されているの
で，悪いアドバイスでした．}で有効なヘッダファイルを作成するために，そ
れらを使用することが可能となります．

@c Do not be naive about writing portable code.  Following the tips given
@c above will help you miss the most obvious problems, but there are
@c definitely other subtle portability issues.  You may need to cope with
@c some of the following issues:
@c 
移植可能なコードをネイティブに書かないでください，上記のヒントに続ける
ことで，最も明白な問題を無くすことに役立ちますが，明らかに別の微妙な問
題があります．以下の問題に対処する必要があるかもしれません．

@itemize @bullet
@item
@c Pre-ANSI compilers do not always support the @code{void *} generic
@c pointer type, and so need to use @code{char *} in its place.
@c 
ANSI以前のコンパイラは，一般的なポインタ型@code{void *}を常にサポート
するわけではなく，そこでは@code{char *}を使用する必要があります．

@item
@c The @code{const}, @code{inline} and @code{signed} keywords are not
@c supported by some compilers, especially pre-ANSI compilers.
@c 
@code{const}，@code{signed}そして@code{signed}キーワードは，サポートさ
れていないコンパイラもあり，特にANSI以前のコンパイラがあげられます．

@item
@c The @code{long double} type is not supported by many compilers.
@c 
@code{long double}型は，多くのコンパイラでサポートされていません．
@end itemize

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

@c By definition, every shared library system provides a way for
@c executables to depend on libraries, so that symbol resolution is
@c deferred until runtime.
@c 
定義では，すべての共有ライブラリシステムは，シンボル解決が実行時まで延
期されるように，実行形式をライブラリに依存させる方法を提供します．

@c An @dfn{inter-library dependency} is one in which a library depends on
@c other libraries.  For example, if the libtool library @file{libhello}
@c uses the @code{cos} function, then it has an inter-library dependency
@c on @file{libm}, the math library that implements @code{cos}.
@c 
@dfn{ライブラリ内部の依存性}は，他のライブラリに依存するライブラリにあ
ります．例えば，libtoolライブラリ@file{libhello}が@code{cos}関数を使用
する場合，それは@file{libm}に対するライブラリ内部の依存性があり，数学
ライブラリが@code{cos}を実装しています．

@c Some shared library systems provide this feature in an
@c internally-consistent way: these systems allow chains of dependencies of
@c potentially infinite length.
@c 
共有ライブラリシステムには，内部で一貫した方法で，この機能を提供するも
のもあります．これらのシステムは，潜在的に無限長の依存性の連鎖を認めま
す．

@c However, most shared library systems are restricted in that they only
@c allow a single level of dependencies.  In these systems, programs may
@c depend on shared libraries, but shared libraries may not depend on other
@c shared libraries.
@c 
しかし，ほとんどの共有ライブラリのシステムは，単一レベルの依存のみを認
めるという制限があります．これらのシステムでは，プログラムは共有ライブ
ラリに依存しますが，共有ライブラリは他の共有ライブラリに依存しません．

@c In any event, libtool provides a simple mechanism for you to declare
@c inter-library dependencies: for every library @file{lib@var{name}} that
@c your own library depends on, simply add a corresponding
@c @code{-l@var{name}} option to the link line when you create your
@c library.  To make an example of our
@c @file{libhello} that depends on @file{libm}:
@c 
あらゆる事象で，ライブラリ内部の依存性を宣言するため，libtoolは単純な
メカニズムを提供します．独自のライブラリに依存するすべてのライブラリ
@file{lib@var{name}}に対しライブラリを作成するとき，対応する
@code{-l@var{name}}オプションをリンク行に単純に加えます．@file{libm}に
依存する@file{libhello}の例をビルドしてみます．

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

@c When you link a program against @file{libhello}, you don't need to
@c specify the same @samp{-l} options again: libtool will do that for you,
@c in order to guarantee that all the required libraries are found.  This
@c restriction is only necessary to preserve compatibility with static
@c library systems and simple dynamic library systems.
@c 
プログラムを@file{libhello}に対しリンクするとき，@samp{-l}オプションを
再び指定する必要はありません．必要なライブラリがすべて見つかることを保
証するため，libtoolがそれを行います．この制約は，スタティックライブラ
リシステムと，単純なダイナミックライブラリシステムとの互換性を保つため
に必要です．

@c Some platforms, such as AIX, do not even allow you this
@c flexibility.  In order to build a shared library, it must be entirely
@c self-contained (that is, have references only to symbols that are found
@c in the @samp{.lo} files or the specified @samp{-l} libraries), and you
@c need to specify the @var{-no-undefined} flag.  By default, libtool
@c builds only static libraries on these kinds of platforms.
@c 
AIXのように，この柔軟性さえ許可されないプラットフォームもあります．共
有ライブラリをビルドするため，それは完全に自己内蔵型である必要があり
(すなわち，@samp{.lo}ファイルや@samp{-l}で指定されたライブラリでシンボ
ルが見つかるもののみを参照する)，@var{-no-undefined}フラグを指定する必
要があります．デフォルトで，libtoolはこの種のプラットフォームではスタ
ティックライブラリのみをビルドします．

@c The simple-minded inter-library dependency tracking code of libtool
@c releases prior to 1.2 was disabled because it was not clear when it was
@c possible to link one library with another, and complex failures would
@c occur.  A more complex implementation of this concept was re-introduced
@c before release 1.3, but it has not been ported to all platforms that
@c libtool supports.  The default, conservative behavior is to avoid
@c linking one library with another, introducing their inter-dependencies
@c only when a program is linked with them.
@c 
1.2以前のlibtoolのリリースのコードにおける，単純に考えられたライブラリ
内部の依存性の追跡は，ライブラリを他のライブラリとリンクすることが可能
なときが明白でないため，それが利用ができず，複雑な異常終了が発生します．
この概念のより複雑な実装は，リリース1.3の前に再導入されましたが，
libtoolがサポートするすべてのプラットフォームに移植されませんでした．
デフォルトで，保守的な動作は，ライブラリが他のライブラリとリンクするこ
とを避け，プログラムがリンクされるときのみに，その内部依存性が導入され
ます．

@node Dlopened modules
@c @chapter 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

@c It can sometimes be confusing to discuss @dfn{dynamic linking}, because
@c the term is used to refer to two different concepts:
@c 
@dfn{ダイナミックリンク}の議論では，その用語が二つの異なる概念を述べる
ときに使用されるので，混乱することがあります．

@enumerate 1
@item
@c Compiling and linking a program against a shared library, which is
@c resolved automatically at run time by the dynamic linker.  In this
@c process, dynamic linking is transparent to the application.
@c 
共有ライブラリに対しプログラムをコンパイルとリンクし，それは，ダイナミッ
クリンカにより実行時に自動的に解決される．この処理では，ダイナミックリ
ンクはアプリケーション透過です．

@item
@c The application calling functions such as @code{dlopen},@footnote{HP-UX,
@c to be different, uses a function named @code{shl_load}.} which load
@c arbitrary, user-specified modules at runtime.  This type of dynamic
@c linking is explicitly controlled by the application.
@c 
アプリケーションの，@code{dlopen}@footnote{HP-UXでは異なり，
@code{shl_load}という名の関数が使用されます．}のような関数の呼び出しで，
それは，ユーザが指定したモジュールを実行時に任意にロードします．この形
式のダイナミックリンクは，アプリケーションで明示的に制御されます．
@end enumerate

@c To mitigate confusion, this manual refers to the second type of dynamic
@c linking as @dfn{dlopening} a module.
@c 
混乱を軽減するため，このマニュアルは二番目の形式のダイナミックリンクを
@dfn{dlopen}モジュールとして述べることにします．

@c The main benefit to dlopening object modules is the ability to access
@c compiled object code to extend your program, rather than using an
@c interpreted language.  In fact, dlopen calls are frequently used in
@c language interpreters to provide an efficient way to extend the
@c language.
@c 
dlopenモジュールの主な利点は，プログラムを拡張するために，インタプリタ
言語を使用するのではなく，コンパイルされたオブジェクトコードにアクセス
する能力です．実際，dlopenは，言語を拡張する効果的な方法を提供するため，
インタプリタ言語でよく使用されます．

@c As of version @value{VERSION}, libtool provides support for dlopened
@c modules.  However, you should indicate that your package is willing to
@c use such support, by using the macro @samp{AC_LIBTOOL_DLOPEN} in
@c @file{configure.in}.  If this macro is not used (or it is used
@c @emph{after} @samp{AC_PROG_LIBTOOL}), libtool will assume no dlopening
@c mechanism is available, and will try to simulate it.
@c 
バージョン@value{VERSION}の現在は，libtoolはdlopenされるモジュールのサ
ポートを提供します．しかし，パッケージがそのようなサポートを行うことを，
@file{configure.in}で，マクロ@samp{AC_LIBTOOL_DLOPEN}を使用して指示し
た方が良いでしょう．このマクロが使用されない(または
@samp{AC_PROG_LIBTOOL}の@emph{後で}使用される)場合，libtoolはdlopenメ
カニズムが利用不可能と仮定し，シミュレーションを試みます．

@c This chapter discusses how you as a dlopen application developer might
@c use libtool to generate dlopen-accessible modules.
@c 
この章では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
@c @section Building modules to dlopen
@section dlopenのためのモジュールのビルド

@c On some operating systems, a program symbol must be specially declared
@c in order to be dynamically resolved with the @code{dlsym} (or
@c equivalent) function.
@c 
オペレーティングシステムには，プログラムシンボルを@code{dlsym}(または
その等価)関数を用いてダイナミックに解決するために，特別に宣言する必要
があるものもあります．

@c Libtool provides the @samp{-export-dynamic} and @samp{-module}
@c link flags (@pxref{Link mode}), which do this declaration.
@c You need to use these flags if you are linking an application program that
@c dlopens other modules or a libtool library that will also be dlopened.
@c 
libtoolは，@samp{-export-dynamic}と@samp{-module}リンクフラグを提供し
(@pxref{Link mode})，それはこの宣言を行います．他のモジュールやdlopen
されているlibtoolライブラリをdlopenするアプリケーションプログラムをリ
ンクする場合，これらのフラグを使用する必要があります．

@c For example, if we wanted to build a shared library, @file{libhello},
@c that would later be dlopened by an application, we would add
@c @samp{-module} to the other link flags:
@c 
例えば，後でアプリケーションにdlopenされる共有ライブラリ
@file{libhello}をビルドしたい場合，他のリンクオプションに
@samp{-module}を加えます．

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

@c If symbols from your @emph{executable} are needed to satisfy unresolved
@c references in a library you want to dlopen you will have to use the flag
@c @samp{-export-dynamic}.
@c You should use @samp{-export-dynamic} while linking the executable that calls
@c dlopen:
@c 
@emph{実行形式}からのシンボルが，dlopenしたいライブラリの未解決の参照
を満足させる必要がある場合，フラグ@samp{-export-dynamic}を使用する必要
があります．dlopenを呼び出す実行形式をリンクするとき，
@samp{-export-dynamic} を使用してください．

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

@node Dlpreopening
@c @section Dlpreopening
@section dlopen

@c Libtool provides special support for dlopening libtool object and
@c libtool library files, so that their symbols can be resolved @emph{even
@c on platforms without any @code{dlopen} and @code{dlsym}
@c functions}.
@c 
libtoolは，dlopenするlibtoolオブジェクトとlibtoolライブラリファイルに
対し，@emph{たとえ@code{dlopen}と@code{dlsym}関数が無いプラットフォー
ムでも}，そのシンボルが解決できるように，特別のサポートを提供します．

@c Consider the following alternative ways of loading code into your
@c program, in order of increasing ``laziness'':
@c 
``laziness''の増加順にプログラムにコードをロードする，以下の別の方法を
考慮します．

@enumerate 1
@item
@c Linking against object files that become part of the program executable,
@c whether or not they are referenced.  If an object file cannot be found,
@c then the linker refuses to create the executable.
@c 
参照するしないに関わらない，実行形式の一部となるオブジェクトファイルへ
のリンクです．オブジェクトファイルが見つからない場合，リンカは実行形式
の作成を停止します．

@item
@c Declaring a static library to the linker, so that it is searched at link
@c time in order to satisfy any undefined references in the above object
@c files.  If the static library cannot be found, then the linker refuses
@c to link the executable.
@c 
上記のオブジェクトファイルでの未定義の参照を満足させるように，リンク時
に検索されるようにするための，リンカに対するスタティックライブラリの宣
言です．スタティックライブラリが見つからない場合，リンカは実行形式の作
成を停止します．

@item
@c Declaring a shared library to the runtime linker, so that it is searched
@c at runtime in order to satisfy any undefined references in the above
@c files.  If the shared library cannot be found, then the dynamic linker
@c aborts the program before it runs.
@c 
上記のファイルでの未定義の参照を満足させるために，実行時に検索されるよ
うにするための，実行時リンクの共有ライブラリの宣言です．共有ライブラリ
が見つからない場合，ダイナミックリンカは実行形式の作成を停止します．

@item
@c Dlopening a module, so that the application can resolve its own,
@c dynamically-computed references.  If there is an error opening the
@c module, or the module is not found, then the application can recover
@c without crashing.
@c 
アプリケーション自身が解決することができるように，参照をダイナミックに
解決するdlopenモジュールです．モジュールを開くときエラーが発生したり，
モジュールが見つからない場合，アプリケーションは壊れることなく回復しま
す．
@end enumerate

@c Libtool emulates @samp{-dlopen} on static platforms by linking objects
@c into the program at compile time, and creating data structures that
@c represent the program's symbol table.
@c 
libtoolは，コンパイル時にオブジェクトファイルをプログラムにリンクし，
プログラムのシンボルテーブルを表現するデータ構造を作成することで，スタ
ティックなプラットフォームで@samp{-dlopen}オプションをエミュレートしま
す．

@c In order to use this feature, you must declare the objects you want your
@c application to dlopen by using the @samp{-dlopen} or @samp{-dlpreopen}
@c flags when you link your program (@pxref{Link mode}).
@c 
この特徴を使用するため，プログラムのリンク時(@pxref{Link mode})に
@samp{-dlopen}や@samp{-dlpreopen}フラグを使用することで，アプリケーショ
ンでdlopenしたいオブジェクトを宣言する必要があります．

@deftypefn {Structure} {struct} lt_dlsymlist @{ @w{const char *@var{name};} @w{lt_ptr @var{address};} @}
@c The @var{name} attribute is a null-terminated character string of the
@c symbol name, such as @code{"fprintf"}.  The @var{address} attribute is a
@c generic pointer to the appropriate object, such as @code{&fprintf}.
@c 
@var{name}属性は，@code{"fprintf"}のような，シンボル名のNULL終端されて
いる文字列です．@var{address}属性は，@code{&fprintf}のような対応するオ
ブジェクトへの一般的なポインタです．
@end deftypefn

@deftypevar {const lt_dlsymlist *} lt_preloaded_symbols
@c An array of @var{lt_symbol} structures, representing all the preloaded
@c symbols linked into the program. For each @samp{-dlpreloaded} file
@c there is an element with the @var{name} of the file and a @var{address}
@c of @code{0}, followed by all symbols exported from this file.
@c For the executable itself the special name @@PROGRAM@@ is used.
@c The last element has a @var{name} and @var{address} of @code{0}.
@c 
@var{lt_symbol}構造体の配列で，プログラムにリンクされる，プリロードさ
れているすべてのシンボルを表現します．それぞれの@samp{-dlpreloaded}ファ
イルに対し，ファイルの@var{name}を用いた要素と，@code{0}の
@var{address}があり，このファイルからエクスポートされるすべてのシンボ
ルが続きます．実行形式自身に対し，特別の名前@@PROGRAM@@が使用されます．
最後の要素は，@var{name}と@code{0}の@var{address}を持ちます．
@end deftypevar

@c Some compilers may allow identifiers which are not valid in ANSI C, such
@c as dollar signs.  Libtool only recognizes valid ANSI C symbols (an
@c initial ASCII letter or underscore, followed by zero or more ASCII
@c letters, digits, and underscores), so non-ANSI symbols will not appear
@c in @var{lt_preloaded_symbols}.
@c 
ドル記号のような，ANSI Cでは有効ではない識別子を許可するコンパイラもあ
ります．libtoolはANSI Cで有効なシンボル(最初がASCII文字またはアンダー
スコアで，ゼロ個以上のASCII文字，数字，そしてアンダースコアが続くもの)
のみ認識するので，非ASCIIシンボルは@var{lt_preloaded_symbols}に出現し
ません．

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

@c After a library has been linked with @samp{-module}, it can be dlopened.
@c Unfortunately, because of the variation in library names,
@c your package needs to determine the correct file to dlopen.
@c 
@samp{-module}を用いてライブラリがリンクされた後，dlopen可能になります．
残念ながら ライブラリ名が変更されるため，パッケージでdlopenの正しいファ
イルを決定する必要があります．

@c The most straightforward and flexible implementation is to determine the
@c name at runtime, by finding the installed @samp{.la} file, and searching
@c it for the following lines:
@c 
最も率直で柔軟な実装は，インストールされた@samp{.la}ファイルを探し，以
下の行を検索することで実行時に決定することです．

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

@c If @var{dlname} is empty, then the library cannot be dlopened.
@c Otherwise, it gives the dlname of the library.  So, if the library was
@c installed as @file{/usr/local/lib/libhello.la}, and the @var{dlname} was
@c @file{libhello.so.3}, then @file{/usr/local/lib/libhello.so.3} should be
@c dlopened.
@c 
@var{dlname}が空の場合，ライブラリはdlopenされません．それ以外では，そ
れでライブラリのdlnameを与えます．そのため，ライブラリが
@file{/usr/local/lib/libhello.la}にインストールされていて，
@var{dlname}が@file{libhello.so.3}の場合，
@file{/usr/local/lib/libhello.so.3}がdlopenされます．

@c If your program uses this approach, then it should search the
@c directories listed in the @code{LD_LIBRARY_PATH}@footnote{@code{LIBPATH}
@c on AIX, and @code{SHLIB_PATH} on HP-UX.} environment variable, as well as
@c the directory where libraries will eventually be installed.  Searching
@c this variable (or equivalent) will guarantee that your program can find
@c its dlopened modules, even before installation, provided you have linked
@c them using libtool.
@c 
プログラムがこのアプローチを行っている場合，ライブラリが最終的にインス
トールされるディレクトリと同じように，
@code{LD_LIBRARY_PATH}@footnote{AIXでの@code{LIBPATH}とHP-UXでの
@code{SHLIB_PATH}です．}環境変数でリストアップされているディレクトリで
検索します．この変数(または同等物)を検索することで，インストール前でも，
プログラムがlibtoolを使用してリンクし提供されているdlopenモジュールを
見つけることを保証します．

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

@c The following problems are not solved by using libtool's dlopen support:
@c 
以下の問題は，libtoolのdlopenサポートを使用しても解決しません．

@itemize @bullet
@item
@c Dlopen functions are generally only available on shared library
@c platforms.  If you want your package to be portable to static platforms,
@c you have to use either libltdl (@pxref{Using libltdl}) or develop your
@c own alternatives to dlopening dynamic code.
@c Most reasonable solutions involve writing wrapper functions for the
@c @code{dlopen} family, which do package-specific tricks when dlopening
@c is unsupported or not available on a given platform.
@c 
dlopen関数は一般に，共有ライブラリプラットフォームでのみ利用可能です．
パッケージをスタティックなプラットフォームに移植したい場合，libltdl
(@pxref{Using libltdl})を使用する，または，代わりとなる独自のdlopenダ
イナミックコードを開発する必要があります．最も妥当な解決方法は，
@code{dlopen}ファミリーのラッパー関数を書くことを必要とし，それは，与
えられたプラットフォームでdlopenがサポートされていないまたは利用不可能
なときの，パッケージ特有のトリックです．

@item
@c There are major differences in implementations of the @code{dlopen}
@c family of functions.  Some platforms do not even use the same function
@c names (notably HP-UX, with its @code{shl_load} family).
@c 
関数の@code{dlopen}ファミリーの実装には大きな違いがあります．同じ関数
名を用いないプラットフォーム(特にHP-UXでは@code{shl_load}ファミリーを
用います)さえ存在します．

@item
@c The application developer must write a custom search function in order
@c to discover the correct module filename to supply to @code{dlopen}.
@c 
アプリケーション開発者は，@code{dlopen}に渡す正しいモジュール名を発見
するために，カスタムの検索関数を書く必要があります．
@end itemize

@node Using libltdl
@c @chapter 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

@c Libtool provides a small library, called @file{libltdl}, that aims at
@c hiding the various difficulties of dlopening libraries from programmers.
@c It consists of a header-file and a small C source file that can be
@c distributed with applications that need dlopening functionality.  On
@c some platforms, whose dynamic linkers are too limited for a simple
@c implementation of @file{libltdl} services, it requires GNU DLD, or it
@c will only emulate dynamic linking with libtool's dlpreopening mechanism.
@c 
libtoolは，@file{libltdl}と呼ばれる小さなライブラリを提供し，それは，
dlopenライブラリの様々な困難をプログラマから隠すことを目指します．それ
は，dlopenの機能で必要とされるアプリケーションとともに配布可能な，ヘッ
ダファイルと小さなCソースファイルから成り立ちます．@file{libltdl}サー
ビスの単純な実装に対し，あまりに制限が多いダイナミックリンカをもつプラッ
トフォーム上では，GNU DLDを要求したり，libtoolのdlpreopenメカニズムを
用いてダイナミックリンクをエミュレートするだけのものもあります．

@noindent
@c libltdl supports currently the following dynamic linking mechanisms:
@c 
libltdlは，現在以下のダイナミックリンクメカニズムをサポートします．

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

@noindent
@c libltdl is licensed under the terms of the GNU Library General Public License,
@c with the following exception:
@c 
以下の例外で，libltdlはGNUライブラリ公有使用許諾書の条件下でライセンス
されています．

@quotation
@c As a special exception to the GNU Lesser General Public License,
@c if you distribute this file as part of a program or library that
@c is built using GNU libtool, you may include it under the same
@c distribution terms that you use for the rest of that program.
@c 
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
@c @section How to use libltdl in your programs
@section プログラムでのlibltdlの使用法

@noindent
@c The libltdl API is similar to the dlopen interface of Solaris and Linux,
@c which is very simple but powerful.
@c 
libltdl APIは，強力なSolarisとLinuxのdlopenインターフェースに似ていて，
それは，非常に簡単ですが強力です．

@noindent
@c To use libltdl in your program you have to include the header file @file{ltdl.h}:
@c 
プログラムでlibltdlを使用するために，ヘッダファイル@file{ltdl.h}をイン
クルードする必要があります．

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

@noindent
@c The last release of libltdl used some symbols that violated the
@c @sc{posix} namespace conventions.  These symbols are now deprecated,
@c and have been replaced by those described here.  If you have code that
@c relies on the old deprecated symbol names, defining
@c @samp{LT_NON_POSIX_NAMESPACE} before you include @file{ltdl.h} provides
@c conversion macros.  Whichever set of symbols you use, the new api is
@c not binary compatible with the last, so you will need to recompile
@c your application in order to use this version of libltdl.
@c 
libltdlの前回のリリースでは，@sc{posix}名前空間の慣習に違反していたシ
ンボルをいくつか使用していました．これらのシンボルの使用は，現在では非
難されるので，ここで記述されるように置換されました．古い非難されそうな
シンボル名に依存したコードがある場合，@file{ltdl.h}をインクルードする
前に@samp{LT_NON_POSIX_NAMESPACE}を定義すると，変換されたマクロが提供
されます．使用するシンボルの組が何であっても，新しいAPIは前回のものと
バイナリ互換ではないので，このバージョンのlibltdlを使用するため，アプ
リケーションを再コンパイルする必要があるでしょう．

@noindent
@c Note that libltdl is not threadsafe, i.e. a multithreaded application
@c has to use a mutex for libltdl.  It was reported that GNU/Linux's glibc
@c 2.0's @code{dlopen} with @samp{RTLD_LAZY} (which libltdl uses by
@c default) is not thread-safe, but this problem is supposed to be fixed in
@c glibc 2.1.  On the other hand, @samp{RTLD_NOW} was reported to introduce
@c problems in multi-threaded applications on FreeBSD.  Working around
@c these problems is left as an exercise for the reader; contributions are
@c certainly welcome.
@c 
libltdlがスレッドセーフでない，すなわち，マルチスレッドアプリケーショ
ンは，libtoolに対しミューテックスを使用する必要があることに注意してく
ださい．それは，GNU/Linuxのglibc 2.0の@samp{RTLD_LAZY}を用いた
@code{dlopen}が(デフォルトでlibtoolを使用します)，スレッドセーフではな
いことが報告されていますが，この問題は，glibc 2.1でおそらく修正される
でしょ．一方，@samp{RTLD_NOW}は，FreeBSD上のマルチスレッドアプリケーショ
ンで問題が生じたと報告されています．これらの問題に関する作業は，読者の
演習として残っています．貢献は，きっと歓迎されます．

@noindent
@c The following types are defined in @file{ltdl.h}:
@c 
以下の型は@file{ltdl.h}で定義されています．

@deftp {Type} lt_ptr
@c @code{lt_ptr} is a generic pointer.
@c 
@code{lt_ptr}は，汎用ポインタです．
@end deftp

@deftp {Type} lt_dlhandle
@c @code{lt_dlhandle} is a module "handle".
@c Every lt_dlopened module has a handle associated with it.
@c 
@code{lt_dlhandle}はモジュール"ハンドル"です．すべてのlt_dlopenされる
モジュールはそれに関連付けされたハンドルがあります．
@end deftp

@deftp {Type} lt_dlsymlist
@c @code{lt_dlsymlist} is a symbol list for dlpreopened modules.
@c This structure is described in @pxref{Dlpreopening}.
@c 
@code{lt_dlsymlist}はdlpreopenされるモジュールのシンボルリストです．こ
の構造体は，@pxref{Dlpreopening}で記述されます．
@end deftp

@page
@noindent
@c libltdl provides the following functions:
@c 
libltdlは以下の関数を提供します．

@deftypefun int lt_dlinit (void)
@c Initialize libltdl.
@c This function must be called before using libltdl
@c and may be called several times.
@c Return 0 on success, otherwise the number of errors.
@c 
libltdlを初期化します．この関数は，libltdl使用する前に呼び出す必要があ
り，複数回呼び出すことが可能です．成功したら0，それ以外ではエラーの番
号を返します．
@end deftypefun

@deftypefun int lt_dlexit (void)
@c Shut down libltdl and close all modules.
@c This function will only then shut down libltdl when it was called as
@c many times as @code{lt_dlinit} has been successfully called.
@c Return 0 on success, otherwise the number of errors.
@c 
libltdlを終了し，すべてのモジュールを閉じます．この関数は，
@code{lt_dlinit}が正常に呼び出された回数と同じだけ呼び出されたとき，
libltdlを終了するだけです．成功したら0，それ以外ではエラーの番号を返し
ます．
@end deftypefun

@deftypefun lt_dlhandle lt_dlopen (const char *@var{filename})
@c Open the module with the file name @var{filename} and return a
@c handle for it.  @code{lt_dlopen} is able to open libtool dynamic
@c modules, preloaded static modules, the program itself and
@c native dynamic libraries.
@c 
ファイル名@var{filename}を用いてモジュールを開き，そのハンドルを返しま
す．@code{lt_dlopen}は，libtoolダイナミックモジュール，プリロードされ
たスタティックモジュール，プログラム自身，そしてネイティブなダイナミッ
クライブラリを開くことが可能です．

@c Unresolved symbols in the module are resolved using its dependency
@c libraries (not implemented yet) and previously dlopened modules.  If the
@c executable using this module was linked with the @code{-export-dynamic}
@c flag, then the global symbols in the executable will also be used to
@c resolve references in the module.
@c 
モジュール内の未解決のシンボルは，それが依存する(まだ実装されていない)
ライブラリと，前もってdlopenされたモジュールを用いて解決されます．この
モジュールを使用している実行形式が@code{-export-dynamic}フラグでリンク
されている場合，実行形式の大域的なシンボルもモジュール内の参照の解決に
使用されます．

@c If @var{filename} is @code{NULL} and the program was linked with
@c @code{-export-dynamic} or @code{-dlopen self}, @code{lt_dlopen} will
@c return a handle for the program itself, which can be used to access its
@c symbols.
@c 
@var{filename}が@code{NULL}でプログラムが@code{-export-dynamic}や
@code{-dlopen self}を用いてリンクされている場合，@code{lt_dlopen}はプ
ログラム自身のハンドルを返し，それはそのシンボルのアクセスに使用可能で
す．

@c If libltdl cannot find the library and the file name @var{filename} does
@c not have a directory component it will additionally search in the
@c following search paths for the module (in the order as follows):
@c 
libltdlがライブラリを見つけられず，ファイル名@var{filename}がディレク
トリコンポーネントを持たない場合，それは，以下の検索パスを(以下の順番
で)，さらにモジュールを検索します．

@enumerate 1
@c @item user-defined search path:
@item
ユーザ定義の検索パス：
@c This search path can be changed by the program using the
@c functions @code{lt_dlsetsearchpath}, @code{lt_dladdsearchdir} and
@c @code{lt_dlinsertsearchdir}.
@c 
この検索パスは，関数@code{lt_dlsetsearchpath}，
@code{lt_dladdsearchdir}，そして@code{lt_dlinsertsearchdir}を用いたプ
ログラムで変更可能です．

@c @item libltdl's search path:
@item
libltdlの検索パス：
@c This search path is the value of the environment variable
@c @var{LTDL_LIBRARY_PATH}.
@c 
この検索パスは，環境変数@var{LTDL_LIBRARY_PATH}の値です．

@c @item system library search path:
@item
システムのライブラリ検索パス：
@c The system dependent library search path
@c (e.g. on Linux it is @var{LD_LIBRARY_PATH}).
@c 
システム依存のライブラリ検索パスです(例えば，Linuxでは
@var{LD_LIBRARY_PATH}になります)．
@end enumerate

@c Each search path must be a colon-separated list of absolute directories,
@c for example, @code{"/usr/lib/mypkg:/lib/foo"}.
@c 
それぞれの検索パスは，例えば@code{"/usr/lib/mypkg:/lib/foo"}のように，
コロンで分離された絶対的なディレクトリのリストにする必要があります．

@c If the same module is loaded several times, the same handle is returned.
@c If @code{lt_dlopen} fails for any reason, it returns @code{NULL}.
@c 
同じモジュールが複数回ロードされた場合，同じハンドルが返されます．あら
ゆる原因で@code{lt_dlopen}が失敗した場合，@code{NULL}が返されます．
@end deftypefun

@deftypefun lt_dlhandle lt_dlopenext (const char *@var{filename})
@c The same as @code{lt_dlopen}, except that it tries to append
@c different file name extensions to the file name.
@c If the file with the file name @var{filename} cannot be found
@c libltdl tries to append the following extensions:
@c 
ファイル名に異なるファイル名の拡張子を追加を試みる以外は，
@code{lt_dlopen}と同じです．ファイル名@var{filename}を持つファイルが見
つからない場合，libltdlは，以下の拡張子の追加を試みます．

@enumerate 1
@c @item the libtool archive extension @samp{.la}
@c 
@item
libtoolのアーカイブ拡張子@samp{.la}
@c @item the extension used for native dynamic libraries on the host platform,
@c e.g., @samp{.so}, @samp{.sl}, etc.
@c 
@item
ホストプラットフォームの本来のダイナミックライブラリに使用される拡張子
で，例えば，@samp{.so}，@samp{.sl}等です．
@end enumerate

@c This lookup strategy was designed to allow programs that don't
@c have knowledge about native dynamic libraries naming conventions
@c to be able to @code{dlopen} such libraries as well as libtool modules
@c transparently.
@c 
この探索手法は，本来のダイナミックライブラリの命名規則を知らないプログ
ラムが，そのようなライブラリを，libtoolモジュールと同様に，透過的に
@code{dlopen}することを可能にするために設計されています．
@end deftypefun

@deftypefun int lt_dlclose (lt_dlhandle @var{handle})
@c Decrement the reference count on the module @var{handle}.
@c If it drops to zero and no other module depends on this module,
@c then the module is unloaded.
@c Return 0 on success.
@c 
モジュール@var{handle}の参照カウントを減らします．ゼロになったり，この
モジュールに依存する他のモジュールがない場合，モジュールはアンロードさ
れます．成功時には0を返します．
@end deftypefun

@deftypefun lt_ptr lt_dlsym (lt_dlhandle @var{handle}, const char *@var{name})
@c Return the address in the module @var{handle}, where the symbol given
@c by the null-terminated string @var{name} is loaded.
@c If the symbol cannot be found, @code{NULL} is returned.
@c 
モジュール@var{handle}内のアドレスを返し，そこでは，ヌルで終端された文
字列@var{name}で与えられるシンボルがロードされています．シンボルが見つ
からない場合は@code{NULL}を返します．
@end deftypefun

@deftypefun {const char *} lt_dlerror (void)
@c Return a human readable string describing the most
@c recent error that occurred from any of libltdl's functions.
@c Return @code{NULL} if no errors have occurred since initialization
@c or since it was last called.
@c 
libltdlのあらゆる関数から発生した最も新しいエラーを記述する，可読性の
高い文字列を返します．初期化からまたは最後に呼び出されてからエラーが発
生していない場合，@code{NULL}を返します．
@end deftypefun

@deftypefun int lt_dlpreload (const lt_dlsymlist *@var{preloaded})
@c Register the list of preloaded modules @var{preloaded}.
@c If @var{preloaded} is @code{NULL}, then all previously registered
@c symbol lists, except the list set by @code{lt_dlpreload_default},
@c are deleted. Return 0 on success.
@c 
プリロードされているモジュール@var{preloaded}のリストを登録します．
@var{preloaded}が@code{NULL}の場合，@code{lt_dlpreload_default}で設定
されているリスト以外の，これまで登録されているすべてのシンボルリストが
検出されます．成功時には0を返します．
@end deftypefun

@deftypefun int lt_dlpreload_default (const lt_dlsymlist *@var{preloaded})
@c Set the default list of preloaded modules to @var{preloaded}, which
@c won't be deleted by @code{lt_dlpreload}.  Note that this function does
@c @emph{not} require libltdl to be initialized using @code{lt_dlinit} and
@c can be used in the program to register the default preloaded modules.
@c Instead of calling this function directly, most programs will use the
@c macro @code{LTDL_SET_PRELOADED_SYMBOLS}.
@c 
プリロードされているモジュールリストのデフォルトを@var{preloaded}に設
定し，それは@code{lt_dlpreload}で検出されません．この関数は，
@code{lt_dlinit}を使用して初期化されるためにlibltdlを要求し@emph{ない}
ことと，デフォルトでプリロードされるモジュールを登録するためにプログラ
ムで使用できることに注意してください．この関数を直接呼び出す代わりに，
ほとんどのプログラムはマクロ@code{LTDL_SET_PRELOADED_SYMBOLS}を使用し
ます．

@c Return 0 on success.
@c 
成功時には0を返します．
@end deftypefun

@defmac LTDL_SET_PRELOADED_SYMBOLS
@c Set the default list of preloaded symbols.
@c Should be used in your program to initialize libltdl's
@c list of preloaded modules.
@c 
プリロードされるシンボルのデフォルトリストを設定します．プリロードされ
るlibltdlのモジュールを初期化するために，プログラムで使用した方が良い
でしょう．

@example
#include <ltdl.h>

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

@deftypefun int lt_dladdsearchdir (const char *@var{search_dir})
@c Append the search directory @var{search_dir} to the current user-defined
@c library search path. Return 0 on success.
@c 
検索ディレクトリ@var{search_dir}を現在のユーザ定義のライブラリ検索パス
に後置します．成功時には0を返します．
@end deftypefun

@deftypefun int lt_dlinsertsearchdir (@w{const char *@var{before}}, @w{const char *@var{search_dir}})
@c Insert the search directory @var{search_dir} into the user-defined library
@c search path, immediately before the element starting at address
@c @var{before}.  If @var{before} is @samp{NULL}, then @var{search_dir} is
@c appending as if @code{lt_dladdsearchdir} had been called.  Return 0 on success.
@c 
検索ディレクトリ@var{search_dir}をユーザ定義のライブラリ検索パスを，ア
ドレス@var{before}で始まる項目の直前に挿入します．@var{before}が
@samp{NULL}の場合，@code{lt_dladdsearchdir}が呼び出されたのと同様に後
置します．成功時には0を返します．
@end deftypefun

@deftypefun int lt_dlsetsearchpath (const char *@var{search_path})
@c Replace the current user-defined library search path with
@c @var{search_path}, which must be a colon-separated list of absolute
@c directories.  Return 0 on success.
@c 
現在のユーザ定義のライブラリ検索パスを@var{search_path}で置換し，それ
はコロンで分けられた絶対的なディレクトリのリストにする必要があります．
成功時には0を返します．
@end deftypefun

@deftypefun {const char *}lt_dlgetsearchpath (void)
@c Return the current user-defined library search path.
@c 
現在のユーザ定義のライブラリ検索パスを返します．
@end deftypefun

@deftypefun int lt_dlforeachfile (@w{const char *@var{search_path}}, @w{int (*@var{func}) (const char *@var{filename}, lt_ptr @var{data})}, @w{lt_ptr @var{data}})
@c In some applications you may not want to load individual modules with
@c known names, but rather find all of the modules in a set of
@c directories and load them all during initialisation.  With this function
@c you can have libltdl scan the colon delimited directory list in
@c @var{search_path} for candidates, and pass them, along with @var{data}
@c to your own callback function, @var{func}.  If @var{seach_path} is
@c @samp{NULL}, then search all of the standard locations that
@c @code{lt_dlopen} would examine.  This function will continue to make
@c calls to @var{func} for each file that it discovers in @var{search_path}
@c until one of these calls returns non-zero, or until the files are
@c exhausted.  @samp{lt_dlforeachfile} returns value returned by the last
@c call made to @var{func}.
@c 
アプリケーションによっては，既知の名前でモジュールを個別にロードしたく
なく，むしろディレクトリの組みからすべてのモジュールを見つけたり，初期
化中にすべてロードしたいかもしれません．この関数を用いると，libltdlに
候補となる@var{search_path}内のコロンで分離されたディレクトリリストを
走査させ，それらを独自のコールバック関数@var{func}に渡す@var{data}と併
せて渡すことが可能です．@var{seach_path}が@samp{NULL}の場合，
@code{lt_dlopen}が調査する標準的な場所をすべて検索します．この関数は，
これらの呼び出しの一つでもゼロ以外の値が返されるまで，またはファイルが
亡くなるまで，@var{search_path}で見つかったそれぞれのファイルに対し，
@var{func}を呼び出し続けます．@samp{lt_dlforeachfile}は最後の
@var{func}の呼び出しの返り値を返します．

@c For example you could define @var{func} to build an ordered
@c @dfn{argv}-like vector of files using @var{data} to hold the address of
@c the start of the vector.
@c 
例えば，最初のベクトル(配列)のアドレスを保持している@var{data}を使用し
ているファイルの，順番になっている@dfn{argv}のようなベクトル(配列)を構
築するために，@var{func}を定義することも可能です．
@end deftypefun

@deftypefun int lt_dlmakeresident (lt_dlhandle @var{handle})
@c Mark a module so that it cannot be @samp{lt_dlclose}d.  This can be
@c useful if a module implements some core functionality in your project,
@c which would cause your code to crash if removed.  Return 0 on success.
@c 
モジュールを@samp{lt_dlclose}できないように印を付けます．モジュールが
プロジェクトの中心部の機能を実装している場合，削除されるとコードが壊れ
るので，これは役に立つはずです．成功すると0を返します．

@c If you use @samp{lt_dlopen (NULL)} to get a @var{handle} for the running
@c binary, that handle will always be marked as resident, and consequently
@c cannot be successfully @samp{lt_dlclose}d.
@c 
実行しているバイナリに対する@var{handle}を取得するために
@samp{lt_dlopen (NULL)}を使用する場合，そのハンドルは常駐しているよう
な印が常に付き，したがってうまく@samp{lt_dlclose}することができません．
@end deftypefun

@deftypefun int lt_dlisresident (lt_dlhandle @var{handle})
@c Check whether a particular module has been marked as resident, returning 1
@c if it has or 0 otherwise.  If there is an error while executing this
@c function, return -1 and set an error message for retrieval with
@c @code{lt_dlerror}.
@c 
特定のモジュールが常駐しているように印が付いているかどうか調査し，その
場合は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
@c These variables are set to @code{malloc} and @code{free}, by default,
@c but you can set them to any other functions that provides equivalent
@c functionality.  However, you must not modify their values after calling
@c any libltdl function other than @code{lt_dlpreopen_default} or the macro
@c @code{LTDL_SET_PRELOADED_SYMBOLS}.
@c 
これらの変数は，デフォルトで@code{malloc}と@code{free}に設定されますが，
同等の機能を提供する他の関数に設定可能です．しかし，
@code{lt_dlpreopen_default}やマクロ@code{LTDL_SET_PRELOADED_SYMBOLS}以
外のあらゆるlibltdl関数の呼び出し後に，その値を編集すべきではありませ
ん．
@end deftypevar

@node Modules for libltdl
@c @section Creating modules that can be @code{dlopen}ed
@section @code{dlopen}可能なモジュールの作成

@c Libtool modules are like normal libtool libraries with a few exceptions:
@c 
libtoolモジュールは，いくつかの例外はありますが，通常のlibtoolライブラ
リに似ています．

@c You have to link the module with libtool's @samp{-module} switch,
@c and you should link any program that is intended to dlopen the module with
@c @samp{-dlopen modulename.la} so that libtool can dlpreopen the module
@c on platforms which don't support dlopening.  If the module depends on any
@c other libraries, make sure you specify them either when you link the module
@c or when you link programs that dlopen it.
@c If you want to disable @pxref{Versioning} for a specific module
@c you should link it with the @samp{-avoid-version} switch.
@c Note that libtool modules don't need to have a "lib" prefix.
@c However, automake 1.4 or higher is required to build such modules.
@c 
libtoolの@samp{-module}スイッチを用いて，モジュールとリンクする必要が
あり，そして，dlopenをサポートしていないプラットフォームでlibtoolが
dlpreopenできるよう，@samp{-dlopen modulename.la}を用いてモジュールを
dlopenするために，あらゆるプログラムとリンクすべきです．モジュールが，
あらゆる他のライブラリに依存する場合，モジュールとリンクするときや，そ
れをdlopenするプログラムをリンクするとき，それらを確実に指定してくださ
い．特定のモジュールに対し@pxref{Versioning}を使用禁止にしたい場合，
@samp{-avoid-version}スイッチを用いてリンクすべきです．libtoolモジュー
ルは，"lib"接頭辞が不要なことに注意してください．しかし，automake 1.4
やそれ以降のものは，そのようなモジュールのビルドが必要です．

@c Usually a set of modules provide the same interface, i.e, exports the same
@c symbols, so that a program can dlopen them without having to know more
@c about their internals.
@c In order to avoid symbol conflicts all exported symbols must be prefixed
@c with "modulename_LTX_" (@samp{modulename} is the name of the module).
@c Internal symbols must be named in such a way that they won't conflict
@c with other modules, for example, by prefixing them with "_modulename_".
@c Although some platforms support having the same symbols defined more than
@c once it is generally not portable and it makes it impossible to dlpreopen
@c such modules.  libltdl will automatically cut the prefix off to get
@c the real name of the symbol.  Additionally, it supports modules which
@c don't use a prefix so that you can also dlopen non-libtool modules.
@c 
通常，その内部を知る必要なしにプログラムがdlopenできるよう，一組のモ
ジュールは同じインターフェース提供し，すなわち同じシンボルをエクスポー
トします．すべてのエクスポートされたシンボルで，シンボルの衝突を避ける
ため，"modulename_LTX_"を前置する必要があります(@samp{modulename}はモ
ジュール名です)．内部シンボルは，例えば"_modulename_"を前置するといっ
た，他のモジュールと衝突しないような方法で命名する必要があります．一回
以上宣言された，同じシンボルを持つことをサポートするシステムもあります
がそれは通常移植性がなく，そのようなモジュールをdlpreopenすることを不
可能にします．libltdlは，シンボルの本当の名前を得るとき，自動的に接頭
辞を切り取ります．さらに，非libtoolモジュールもdlopenできるよう，接頭
辞を使用していないモジュールをサポートします．

@c @file{foo1.c} gives an example of a portable libtool module.
@c Exported symbols are prefixed with "foo1_LTX_", internal symbols
@c with "_foo1_". Aliases are defined at the beginning so that the code
@c is more readable.
@c 
@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
@c The @file{Makefile.am} contains the necessary rules to build the
@c module @file{foo1.la}:
@c 
@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
@c @section Using libtldl in a multi threaded environment
@section マルチスレッド環境でのlibtldlの使用

@c Using the @code{lt_dlmutex_register()} function, and by providing some
@c appropriate callback function definitions, libltdl can be used in a
@c multi-threaded environment.
@c 
@code{lt_dlmutex_register()}関数を使用し，適切なコールバック関数の定義
を提供することで，libltdlをマルチスレッド環境で使用することが可能です．

@deftypefn {Type} void lt_dlmutex_lock (void)
@c This is the type of a function pointer holding the address of a function
@c which will be called at the start of parts of the libltdl implementation
@c code which require a mutex lock.
@c 
これは，ミューテックスロックが必要なlibltdlの実装コードの部分の，最初
に呼び出される関数のアドレスを持っている，関数のポインタ型です．

@c Because libltdl is inherantly recursive, it is important that the
@c locking mechanism employed by these callback functions are reentrant, or
@c else strange problems will occur.
@c 
libltdlは本質的に再帰的なので，これらのコールバック関数によって使用さ
れるロックメカニズムが再入可能であることは重要で，そうでなければ，おか
しな問題が発生します．
@end deftypefn

@deftypefn {Type} void lt_dlmutex_unlock (void)
@c The type of a matching unlock function.
@c 
アンロック関数に一致する型です．
@end deftypefn

@deftypefn {Type} void lt_dlmutex_seterror @w{(const char *@var{error});}
@c Many of the functions in the libltdl @sc{api} have a special return
@c value to indicate to the client that an error has occured.  Normally (in
@c single threaded applications) a string describing that error can be
@c retrieved from internal storage with @code{lt_dlerror()}.
@c 
libltdl @sc{api}の関数の多くは，エラーを発生したクライアントを示す，特
殊な返り値をとります．通常(シングルスレッドアプリケーションでは)，内部
から回収することができるエラーを記述する文字列は，@code{lt_dlerror()} 
に保存されます．

@c A function of this type must be registered with the library in order for
@c it to work in a multi-threaded context.  The function should store any
@c error message passed in thread local storage.
@c 
この形式の関数は，それがマルチスレッドのコンテクストで動作するように，
ライブラリに登録される必要があります．関数は，スレッドローカルストレー
ジに渡されるあらゆるエラーメッセージを保存すべきです．
@end deftypefn

@deftypefn {Type} {const char *} lt_dlmutex_geterror (void)
@c The type of a matching callback function to retrieve the last stored
@c error message from thread local storage.
@c 
スレッドローカルのストレージに，最後にエラーメッセージを保存したものに
関連するコールバック関数に一致する型です．

@c When regeistered correctly this function will be used by
@c @code{lt_dlerror())} from all threads to retrieve error messages for the
@c client.
@c 
正しく登録されたとき，クライアントに対するエラーメッセージを回収するた
めに，全てのスレッドから@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})}
@c Use this function to register one of each of function ttypes described
@c above in preparation for multi-threaded use of libltdl.  All arguments
@c must be valid non-@code{NULL} function addresses, or else all
@c @code{NULL} to return to single threaded operation.
@c 
libltdlのマルチスレッドの準備で，上記のそれぞれの関数の型を登録するた
めに，この関数を使用してください．全ての引数は，有効な@code{NULL}でな
い関数アドレスにする必要があり，また，そうでない場合は，シングルスレッ
ドオペレーションへの返り値として，全て@code{NULL}にする必要があります．
@end deftypefn


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

@c Some of the internal information about each loaded module that is
@c maintained by libltdl is available to the user, in the form of this
@c structure:
@c 
libltdlが管理している，それぞれのロードされたモジュールに関する内部情
報には，ユーザが利用可能なものもあり，それは以下のような構造体の形式で
す．

@deftypefn {Type} {struct} lt_dlinfo @{ @w{char *@var{filename};} @w{char *@var{name};} @w{int @var{ref_count};} @}
@c @code{lt_dlinfo} is used to store information about a module.
@c The @var{filename} attribute is a null-terminated character string of
@c the real module file name.  If the module is a libtool module then
@c @var{name} is its module name (e.g. @code{"libfoo"} for
@c @code{"dir/libfoo.la"}), otherwise it is set to @code{NULL}.  The
@c @var{ref_count} attribute is a reference counter that describes how
@c often the same module is currently loaded.
@c 
@code{lt_dlinfo}は，モジュールの情報を保存するために使用されます．
@var{filename}属性は，@code{NULL}で終端された，実際のモジュールファイ
ル名の文字列です．モジュールがlibtoolモジュールの場合，@var{name}はそ
のモジュール名(例えば，@code{"dir/libfoo.la"}に対する@code{"libfoo"})
で，それ以外では@code{NULL}に設定されます．@var{ref_count}属性は，現在
ロードされている同じモジュールの回数を記述する参照カウンタです．
@end deftypefn

@c The following function will return a pointer to libltdl's internal copy
@c of this structure for the given @var{handle}:
@c 
以下の関数は，与えられた@var{handle}に対するこの構造体のlibltdlの内部
のコピーへのポインタを返します．

@deftypefun {const lt_dlinfo *} lt_dlgetinfo (@w{lt_dlhandle @var{handle}})
@c Return a pointer to a struct that contains some information about
@c the module @var{handle}.  The contents of the struct must not be modified.
@c Return @code{NULL} on failure.
@c 
モジュール@var{handle}に関するいくつかの情報を含む構造体の，ポインタを
返します．構造体の内容は編集してはなりません．失敗時には@code{NULL}が
返ります．
@end deftypefun

@c Furthermore, in order to save you from having to keep a list of the
@c handles of all the modules you have loaded, these functions allow you to
@c iterate over libltdl's list of loaded modules:
@c 
さらに，ロードした全てのモジュールのハンドルリストを保持する手助けをす
るために，これらの関数で，ロードされているモジュールのlibltdlのリスト
全体を繰り返すことが可能となります．

@deftypefun int lt_dlforeach (@w{int (*@var{func}) (lt_dlhandle @var{handle}, lt_ptr @var{data})}, @w{lt_ptr @var{data}})
@c For each loaded module call the function @var{func}.  The argument
@c @var{handle} is the handle of one of the loaded modules, @var{data} is
@c the @var{data} argument passed to @code{lt_dlforeach}.
@c As soon as @var{func} returns a non-zero value for one of the handles,
@c @code{lt_dlforeach} will stop calling @var{func} and immediately return 1.
@c Otherwise 0 is returned.
@c 
ロードされているそれぞれのモジュールに対し関数@var{func}を呼び出します．
引数の@var{handle}は，ロードされているモジュールのハンドルの一つで，
@var{data}は，@code{lt_dlforeach}に渡す@var{data}引数です．@var{func}
がハンドルの一つに対し，ゼロでない値を返すとすぐに，
@code{lt_dlforeach}は@var{func}の呼び出しを停止し，直ちに1を返します．
それ以外は0が返ります．
@end deftypefun

@deftypefun lt_dlhandle lt_dlhandle_next (@w{lt_dlhandle place})
@c Iterate over the loaded module handles, returning the first handle in the
@c list if @var{place} is @code{NULL}, and the next one on subsequent calls.
@c If @var{place} is the last element in the list of loaded modules, this
@c function returns @code{NULL}.
@c 
@var{place}が@code{NULL}の場合は，リスト内の最初のハンドルを返し，そし
て順番に次ものを呼び出すことで，ロードされているモジュール全体を繰り返
します．@var{place}が，ロードされているモジュールリスト内の最後の要素
の場合，この関数は@code{NULL}を返します．
@end deftypefun

@c Of course, you would still need to maintain your own list of loaded
@c module handles to parallel the list maintained by libltdl if there are
@c any other data that you need to associate with each handle for the
@c purposes of your application.  However, if you use the following
@c @sc{api} calls to associate your application data with individual module
@c handles as they are loaded there is actually no need to do that.  You
@c must first obtain a unique caller id from libltdl which you subsequently
@c use to retrieve the data you stored earlier.  This allows for different
@c libraries that each wish to store their own data against loaded modules
@c to do so without interfering with one another's data.
@c 
もちろん，アプリケーションの目的のために，それぞれのハンドルに関連付け
する必要があるデータがある場合，libltdlで管理されるリストと平行して，
ロードされたモジュールハンドルの独自のリストの管理が必要になります．し
かし，個別のモジュールハンドルを用いたアプリケーションデータに，ロード
されたものとして関連付けさせるために，以下の@sc{api}の呼び出しを使用す
る場合には，実際にはそうする必要はありません．前もって保存したデータを
回収するために後で利用するlibltdlからのユニークな呼び出しidを，最初に
取得する必要があります．これで，ロードされているモジュールに対する独自
のデータを個別に保存したい異なるライブラリが，もう一つの(ライブラリ)の
データへのインターフェースなしでそれを行うことが可能となります．

@deftp {Type} lt_dlcaller_id
@c The opaque type used to hold individual data set keys.
@c 
個別のデータセットのキーを保つ，透過でない型です．
@end deftp

@deftypefun lt_dlcaller_id lt_dlcaller_register (void)
@c Use this to obtain a unique key to store and retrieve individual sets of
@c per module data.
@c 
モジュールデータごとに個別のセットを，保存し回収するためのユニークなキー
を取得するために，これを使用してください．
@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}})
@c Set @var{data} as the set of data uniquely associated with @var{key} and
@c @var{handle} for later retrieval.  This function returns the @var{data}
@c previously associated with @var{key} and @var{handle} if any.  A result of
@c 0, may indicate that a diagnostic for the last error (if any) is available
@c from @code{lt_dlerror()}.
@c 
後で回収するために，@var{key}と@var{handle}にユニークに関連付けされた
データのセットとして，@var{data}を設定します．この関数は，以前に関連付
けされた@var{key}と@var{handle}がある場合は，その@var{data}を返します．
0の結果は，前回のエラー(が存在する場合)に対する診断結果が，
@code{lt_dlerror()} で利用可能であることを示している可能性があります．

@c For example, to correctly remove some associated data:
@c 
例えば，いくつかの関連データを正しく削除するために，以下のようにします．

@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}})
@c Return the address of the data associated with @var{key} and
@c @var{handle}, or else @code{NULL} if there is none.
@c 
@var{key}と@var{handle}に関連付けされている@var{data}のアドレス，また
は，無い場合は@code{NULL}を返します．
@end deftypefun

@c The preceding functions can be combined with @code{lt_dlforeach} to
@c implement search and apply operations without the need for your
@c application to track the modules that have been loaded and unloaded:
@c 
ここまでの関数は，アプリケーションにロードされたりアンロードされたりし
たモジュールを追跡させる必要なく，オペレーションの検索と適用を実装する
ために，@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
@c @section How to create and register new module loaders
@section 新しいモジュールローダの作成方法と登録方法

@c Sometimes libltdl's many ways of gaining access to modules are not
@c sufficient for the purposes of a project.  You can write your own
@c loader, and register it with libltdl so that @code{lt_dlopen} will be
@c able to use it.
@c 
モジュールにアクセスするためのlibltdlの方法は多いけれど，プロジェクト
の目的に十分でないときもあります．独自のローダを書き，@code{lt_dlopen}
が利用できるように，libltdlでそれを登録することが可能です．

@c Writing a loader involves writing at least three functions which can be
@c called  by @code{lt_dlopen}, @code{lt_dlsym} and @code{lt_dlclose}.
@c Optionally, you can provide a finalisation function to perform any
@c cleanup operations when @code{lt_dlexit} executes, and a symbol prefix
@c string which will be prepended to any symbols passed to @code{lt_dlsym}.
@c These functions must match the function pointer types below, after
@c which they can be allocated to an instance of @code{lt_user_dlloader}
@c and registered.
@c 
ローダを書くことは，@code{lt_dlopen}，@code{lt_dlsym}そして
@code{lt_dlclose}で呼び出し可能な，少なくとも三つの関数を書くことを必
要とします．オプションで，@code{lt_dlexit}が実行されるときクリーンアッ
プ処理を実行する終了関数と，@code{lt_dlsym}に渡されるあらゆるシンボル
に前置されるシンボルの前置文字を提供することも可能です．これらの関数は，
以下の関数のポインタ型に一致する必要があり，その後，それらを
@code{lt_user_dlloader}の代わりに関連付けし，登録することが可能です．

@c Registering the loader requires that you choose a name for it, so that it
@c can be recognised by @code{lt_dlloader_find} and removed with
@c @code{lt_dlloader_remove}.  The name you choose must be unique, and not
@c already in use by libltdl's builtin loaders:
@c 
ローダの登録には，@code{lt_dlloader_find}が認識でき，
@code{lt_dlloader_remove}で削除できるように，それに対する名前を選択す
ることが必要です．選択した名前はユニークである必要があり，libltdlの組
み込みローダで既に使用しているものはいけません．

@table @asis
@item "dlopen"
@c The system dynamic library loader, if one exists.
@c 
存在する場合は，システムのダイナミックローダ．
@item "dld"
@c The @sc{gnu} dld loader, if @file{libdld} was installed when libltdl was
@c built.
@c 
libltdlがビルドされたときに@file{libdld}がインストールされている場合は，
@sc{gnu} dldローダ．
@item "dlpreload"
@c The loader for @code{lt_dlopen}ing of preloaded static modules.
@c 
プリロードされているスタティックモジュールの@code{lt_dlopen}のためのロー
ダ．
@end table

@c The prefix "dl" is reserved for loaders supplied with future versions of
@c libltdl, so you should not use that for your own loader names.
@c 
前置される"dl"は，libltdlの将来のバージョンで提供されるローダとして予
約されているので，独自のローダ名に使用すべきではありません．

@noindent
@c The following types are defined in @file{ltdl.h}:
@c 
以下の型は，@file{ltdl.h}で定義されています．

@deftp {Type} lt_module
@c @code{lt_module} is a dlloader dependent module.
@c The dynamic module loader extensions communicate using these low
@c level types.
@c 
@code{lt_module}はモジュール依存のdlloaderです．ダイナミックモジュール
ローダの拡張は，これらの低レベルの型を使用して通信を行ないます．
@end deftp

@deftp {Type} lt_dlloader
@c @code{lt_dlloader} is a handle for module loader types.
@c 
@code{lt_dlloader}はモジュールローダの型に対するハンドルです．
@end deftp

@deftp {Type} lt_user_data
@c @code{lt_user_data} is used for specifying loader instance data.
@c 
@code{lt_user_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};} @}
@c If you want to define a new way to open dynamic modules, and have the
@c @code{lt_dlopen} @sc{api} use it, you need to instantiate one of these
@c structures and pass it to @code{lt_dlloader_add}.  You can pass whatever
@c you like in the @var{dlloader_data} field, and it will be passed back as
@c the value of the first parameter to each of the functions specified in
@c the function pointer fields.
@c 
ダイナミックモジュールを開くために新しい方法を定義したくて，それを使用
した@code{lt_dlopen} @sc{api}がある場合，これらの構造体のインスタンス
を作成し，それを@code{lt_dlloader_add}に渡す必要があります．好みの
@var{dlloader_data}フィールドで渡すことが可能で，それは，関数ポインタ
フィールドで指定されている，それぞれの関数への最初のパラメータの値とし
て返されます．
@end deftypefn

@deftypefn {Type} lt_module lt_module_open (@w{const char *@var{filename}})
@c The type of the loader function for an @code{lt_dlloader} module
@c loader.  The value set in the dlloader_data field of the @code{struct
@c lt_user_dlloader} structure will be passed into this function in the
@c @var{loader_data} parameter.  Implementation of such a function should
@c attempt to load the named module, and return an @code{lt_module}
@c suitable for passing in to the associated @code{lt_module_close} and
@c @code{lt_sym_find} function pointers.  If the function fails it should
@c return @code{NULL}, and set the error message with @code{lt_dlseterror}.
@c 
@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_user_data @var{loader_data},} @w{lt_module @var{module}})
@c The type of the unloader function for a user defined module loader.
@c Implementatation of such a function should attempt to release
@c any resources tied up by the @var{module} module, and then unload it
@c from memory.  If the function fails for some reason, set the error
@c message with @code{lt_dlseterror} and return non-zero.
@c 
ユーザが定義したモジュールローダに対するアンローダの型です．そのような
関数の実装は，@var{module}モジュールに結び付けられたあらゆるリソースの
解放を試み，その後でメモリからアンロードすべきです．理由があって関数が
失敗した場合，@code{lt_dlseterror}を用いてエラーメッセージを設定し，ゼ
ロ以外を返すべきです．
@end deftypefn

@deftypefn {Type} lt_ptr lt_find_sym (@w{lt_module @var{module},} @w{const char *@var{symbol}})
@c The type of the symbol lookup function for a user defined module loader.
@c Implementation of such a function should return the address of the named
@c @var{symbol} in the module @var{module}, or else set the error message
@c with @code{lt_dlseterror} and return @code{NULL} if lookup fails.
@c 
ユーザが定義したモジュールローダに対する，シンボルルックアップ関数の型
です．そのような関数の実装は，モジュール@var{module}内の指名された
@var{symbol}のアドレスを返す，もしくは，検査が失敗した場合は，エラーメッ
セージを@code{lt_dlseterror}で設定し，@code{NULL}を返すべきです．
@end deftypefn

@deftypefn {Type} int lt_dlloader_exit (@w{lt_user_data @var{loader_data}})
@c The type of the finalisation function for a user defined module loader.
@c Implementation of such a function should free any resources associated
@c with the loader, including any user specified data in the
@c @code{dlloader_data} field of the @code{lt_user_dlloader}.  If non-@code{NULL},
@c the function will be called by @code{lt_dlexit}, and
@c @code{lt_dlloader_remove}.
@c 
ユーザが定義したモジュールローダに対する，終了関数の型です．そのような
関数の実装は，ローダに関連するあらゆるリソースを解放すべきで，それには
@code{lt_user_dlloader}の@code{dlloader_data}フィールド内部にあるユー
ザが指定したあらゆるデータを含みます．@code{NULL}でない場合は，関数は
@code{lt_dlexit}と@code{lt_dlloader_remove}から呼び出されます．
@end deftypefn

@c For example:
@c 
例えば，以下のようにします．

@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

@c Note that if there is any initialisation required for the loader,
@c it must be performed manually before the loader is registered --
@c libltdl doesn't handle user loader initialisation.
@c 
ローダに対する必要な初期化がある場合は，ローダが登録される前に手動で実
行する必要があることに注意してください -- libltdlはユーザローダの初期
化を扱いません．

@c Finalisation @emph{is} handled by libltdl however, and it is important
@c to ensure the @code{dlloader_exit} callback releases any resources claimed
@c during the initialisation phase.
@c 
終了はlibltdlで扱われ@emph{ます}が，@code{dlloader_exit}のコールバック
が初期化フェーズの間に要求された，あらゆるリソースを解放することを確か
めることは重要です．

@page
@noindent
@c libltdl provides the following functions for writing your own module
@c loaders:
@c 
libltdlは，独自のモジュールローダを書くために，以下の関数を提供します．

@deftypefun int lt_dlloader_add (@w{lt_dlloader *@var{place},} @w{lt_user_dlloader *@var{dlloader},} @w{const char *@var{loader_name}})
@c Add a new module loader to the list of all loaders, either as the
@c last loader (if @var{place} is @code{NULL}), else immediately before the
@c loader passed as @var{place}.  @var{loader_name} will be returned by
@c @code{lt_dlloader_name} if it is subsequently passed a newly
@c registered loader.  These @var{loader_name}s must be unique, or
@c @code{lt_dlloader_remove} and @code{lt_dlloader_find} cannot
@c work. Returns 0 for success.
@c 
新しいモジュールローダを全てのローダリストに加え，それは，(@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}})
@c Remove the loader identified by the unique name, @var{loader_name}.
@c Before this can succeed, all modules opened by the named loader must
@c have been closed.  Returns 0 for success, otherwise an error message can
@c be obtained from @code{lt_dlerror}.
@c 
ユニークな名前@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}})
@c Iterate over the module loaders, returning the first loader if @var{place} is
@c @code{NULL}, and the next one on subsequent calls. The handle is for use with
@c @code{lt_dlloader_add}.
@c 
ローダモジュール全体を繰り返し，それは，@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}})
@c Return the first loader with a matching @var{loader_name} identifier, or else
@c @code{NULL}, if the identifier is not found.
@c 
@var{loader_name}識別子に一致する最初のローダを返し，識別子が見つから
ない場合は@code{NULL}を返します．

@c The identifiers which may be used by libltdl itself, if the host
@c architecture supports them are @dfn{dlopen}@footnote{This is used for
@c the host dependent module loading @sc{api} -- @code{shl_load} and
@c @code{LoadLibrary} for example}, @dfn{dld} and @dfn{dlpreload}.
@c 
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}})
@c Return the identifying name of @var{PLACE}, as obtained from
@c @code{lt_dlloader_next} or @code{lt_dlloader_find}.  If this function fails,
@c it will return @code{NULL} and set an error for retrieval with
@c @code{lt_dlerror}.
@c 
@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}})
@c Return the address of the @code{dlloader_data} of @var{PLACE}, as
@c obtained from @code{lt_dlloader_next} or @code{lt_dlloader_find}.  If
@c this function fails, it will return @code{NULL} and set an error for
@c retrieval with @code{lt_dlerror}.
@c 
@code{lt_dlloader_next}や@code{lt_dlloader_find}で取得される，
@var{PLACE}のアドレスを返します．この関数が失敗する場合，@code{NULL}を
返し，@code{lt_dlerror}で回収するためのエラーを設定します．
@end deftypefun

@c @subsection Error handling within user module loaders
@subsection ユーザモジュールローダでのエラー処理

@deftypefun int lt_dladderror (@w{const char *@var{diagnostic}})
@c This function allows you to integrate your own error messages into
@c @code{lt_dlerror}.  Pass in a suitable diagnostic message for return by
@c @code{lt_dlerror}, and an error identifier for use with
@c @code{lt_dlseterror} is returned.
@c 
この関数で，独自のエラーメッセージを@code{lt_dlerror}に組み込むことが
可能となります．@code{lt_dlerror}で返すための適切な診断メッセージに渡
すものと，@code{lt_dlseterror}で使用されるエラー識別子が返されます．

@c If the allocation of an identifier fails, this function returns -1.
@c 
識別子の割り当てが失敗した場合，この関数は-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}})
@c When writing your own module loaders, you should use this function to
@c raise errors so that they are propogated through the @code{lt_dlerror}
@c interface. All of the standard errors used by libltdl are declared in
@c @file{ltdl.h}, or you can add more of your own with
@c @code{lt_dladderror}.  This function returns 0 on success.
@c 
独自のモジュールローダを書くとき，@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
@c @section How to distribute libltdl with your package
@section パッケージとともにlibltdlを配布する方法

@c Even though libltdl is installed together with libtool, you may wish to
@c include libltdl in the distribution of your package, for the convenience
@c of users of your package that don't have libtool or libltdl installed.
@c In this case, you must decide whether to manually add the @code{ltdl}
@c objects to your package, or else which flavor of libltdl you want to use:
@c a convenience library or an installable libtool library.
@c 
libltdlはlibtoolとともにインストールされるのですが，libtoolやlibltdlを
インストールしていないパッケージユーザの利便性のため，パッケージの配布
物にlibltdlを含めたいと思うかもしれません．この場合，手動でパッケージ
に加える@code{ltdl}オブジェクト，または，使用したいlibltdlの特色を決定
する必要があります．それは，コンビニエンスライブラリやインストール可能
なlibtoolライブラリです．

@c The most simplistic way to add @code{libltdl} to your package is to copy
@c the source files, @file{ltdl.c} and @file{ltdl.h}, to a source directory
@c withing your package and to build and link them along with the rest of
@c your sources.  To help you do this, the m4 macros for autoconf are
@c available in @file{ltdl.m4}.  You must ensure that they are available in
@c @file{aclocal.m4} before you run autoconf -- by appending the contents
@c of @file{ltdl.m4} to @file{acinclude.m4}, if you are using automake, or
@c to @file{aclocal.m4} if you are not.  Having made the macros available,
@c you must add a call to the @samp{AC_LIB_LTDL} macro to your package's
@c @file{configure.in} to perform the configure time checks required to
@c build @file{ltdl.o} correctly.  This method has problems if you then try
@c to link the package binaries with an installed libltdl, or a library
@c which depends on libltdl: you may have problems with duplicate symbol
@c definitions.
@c 
@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に依存しているライブラリと，パケー
ジのバイナリをリンクしようとする場合，この手法には問題があります．シン
ボルの二重定義の問題があるかもしれません．

@c One advantage of the convenience library is that it is not installed, so
@c the fact that you use libltdl will not be apparent to the user, and it
@c will not overwrite a pre-installed version of libltdl a user might have.
@c On the other hand, if you want to upgrade libltdl for any reason
@c (e.g. a bugfix) you'll have to recompile your package instead of just
@c replacing an installed version of libltdl.
@c However, if your programs or libraries are linked with other libraries
@c that use such a pre-installed version of libltdl, you may get linker
@c errors or run-time crashes.  Another problem is that you cannot link the
@c convenience library into more than one libtool library, then link a
@c single program with these libraries, because you may get duplicate
@c symbols. In general you can safely use the convenience library in programs
@c which don't depend on other libraries that might use libltdl too.
@c In order to enable this flavor of libltdl, you should add the
@c line @samp{AC_LIBLTDL_CONVENIENCE} to your @file{configure.in},
@c @emph{before} @samp{AC_PROG_LIBTOOL}.
@c 
コンビニエンスライブラリの利点の一つは，インストールされていないという
ことなので，libtoolを使用するという事実はユーザにとって明白ではなく，
ユーザが以前にインストールしているlibtoolのバージョンを上書きしません．
一方，(例えば，バグフィックスといった)理由があって，libltdlをアップグ
レードしたい場合，インストールされているバージョンのlibtoolを置き換え
る代わりに，パッケージを再コンパイルする必要があります．しかし，プログ
ラムやライブラリが以前にインストールされているバージョンのlibltdlを使
用しているライブラリとリンクする場合，リンカエラーが発生し実行時にクラッ
シュするかもしれません．もう一つの問題は，一つ以上のlibtoolライブラリ
へコンビニエンスライブラリをリンクできないことで，複製されたシンボルを
得る可能性があるので，そのときは，これらのライブラリを用いた単一のプロ
グラムとリンクしてください．一般的に，libtoolを使用している他のライブ
ラリに依存しないプログラムでは，コンビニエンスライブラリを問題なく使用
可能です．libltdlのこの特徴を利用可能にするため，
@samp{AC_LIBLTDL_CONVENIENCE}行を@file{configure.in}に，
@samp{AC_PROG_LIBTOOL}の@emph{前に}加えた方が良いでしょう．

@c In order to select the installable version of libltdl, you should add a
@c call of the macro @samp{AC_LIBLTDL_INSTALLABLE} to your
@c @file{configure.in} @emph{before} @samp{AC_PROG_LIBTOOL}.  This macro
@c will check whether libltdl is already installed and, if not, request the
@c libltdl embedded in your package to be built and installed.  Note,
@c however, that no version checking is performed.  The user may override
@c the test and determine that the libltdl embedded must be installed,
@c regardless of the existence of another version, using the configure
@c switch @samp{--enable-ltdl-install}.
@c 
インストール可能なバージョンのlibltdlを選択するために，マクロ
@samp{AC_LIBLTDL_INSTALLABLE}の呼び出しを@file{configure.in}に，
@samp{AC_PROG_LIBTOOL}の@emph{前に}加えた方が良いでしょう．このマクロ
は，libltdlが既にインストールされているかどうか調査し，そうでない場合，
ビルドしインストールされるパッケージlibltdlを埋め込むことを要求します．
しかし，バージョン調査は実行されないことに注意してください．ユーザは，
コンフィグレーションスイッチ@samp{--enable-ltdl-install}を使用すること
で，他のバージョンの存在に関係なく，テストを優先し，埋め込まれた
libtoolをインストールする必要があるか決定することができます．

@c In order to embed libltdl into your package, just add @samp{--ltdl} to
@c the @code{libtoolize} command line. It will copy the libltdl sources
@c to a subdirectory @samp{libltdl} in your package.
@c Both macros accept an optional argument to specify the location
@c of the @samp{libltdl} directory. By the default both macros assume that it
@c is @samp{$@{top_srcdir@}/libltdl}.
@c 
libtoolをパッケージに埋め込むため，@code{libtoolize}コマンドラインに
@samp{--ltdl}のみ加えてください．それで，パッケージのサブディレクトリ
@samp{libltdl}にlibtoolのソースをコピーします．どちらのマクロも，
@samp{libltdl}ディレクトリの位置を指定する追加の引数を受け入れます．デ
フォルトで，どちらのマクロも@samp{$@{top_srcdir@}/libltdl}を仮定します．

@c Whatever macro you use, it is up to you to ensure that your
@c @file{configure.in} will configure libltdl, using
@c @samp{AC_CONFIG_SUBDIRS}, and that your @file{Makefile}s will start
@c sub-makes within libltdl's directory, using automake's @var{SUBDIRS},
@c for example.  Both macros define the shell variables @var{LIBLTDL}, to
@c the link flag that you should use to link with libltdl, and
@c @var{LTDLINCL}, to the preprocessor flag that you should use to compile
@c with programs that include @file{ltdl.h}.  It is up to you to use
@c @samp{AC_SUBST} to ensure that this variable will be available in
@c @file{Makefile}s, or add them to variables that are @samp{AC_SUBST}ed by
@c default, such as @var{LIBS} and @var{CPPFLAGS}.
@c 
どのマクロを使用しても，@file{configure.in}は@samp{AC_CONFIG_SUBDIRS} 
を使用して，libltdlをコンフィグレーションし，@file{Makefile}が，例えば，
automakeの@var{SUBDIRS}を使用して，libtoolのディレクトリでサブmakeを開
始することを確実にするのはあなたです．どちらのマクロも，libltdlでリン
クするために使用するリンクフラグのシェル変数@var{LIBLTDL}と，
@file{ltdl.h}をインクルードするプログラムをコンパイルするために使用す
るプリプロセッサフラグ@var{LTDLINCL}を定義します．この変数が
@file{Makefile}で利用可能にすることを確実にするため@samp{AC_SUBST}を使
用したり，デフォルトで@samp{AC_SUBST}される，@var{LIBS}と
@var{CPPFLAGS}のような変数に加えるのはあなた次第です．

@c If you're using the convenience libltdl, @var{LIBLTDL} will be the
@c pathname for the convenience version of libltdl and @var{LTDLINCL} will be
@c @samp{-I} followed by the directory that contains libltdl, both starting
@c with @samp{$@{top_builddir@}/} or @samp{$@{top_srcdir@}/}, respectively.
@c 
コンビニエンスlibltdlを使用している場合，@var{LIBLTDL}はコンビニエンス
libltdlのバージョンに対するパス名で，@var{LTDLINCL}はlibltdlを含むディ
レクトリが続く@samp{-I}になり，どちらも@samp{$@{top_builddir@}/}，また
は，@samp{$@{top_srcdir@}/}で，それぞれ始まります．

@c If you request an installed version of libltdl and one is
@c found@footnote{Even if libltdl is installed,
@c @samp{AC_LIBLTDL_INSTALLABLE} may fail to detect it, if libltdl depends
@c on symbols provided by libraries other than the C library.  In this
@c case, it will needlessly build and install libltdl.}, @var{LIBLTDL} will
@c be set to @samp{-lltdl} and @var{LTDLINCL} will be empty (which is just a
@c blind assumption that @file{ltdl.h} is somewhere in the include path if
@c libltdl is in the library path).  If an installable version of libltdl
@c must be built, its pathname, starting with @samp{$@{top_builddir@}/},
@c will be stored in @var{LIBLTDL}, and @var{LTDLINCL} will be set just like
@c in the case of convenience library.
@c 
インストールされているlibltdlのバージョンを要求し，それが見つかった場
合@footnote{たとえ，libltdlがインストールされていても，libltdlがCライ
ブラリ以外のライブラリが提供するシンボルに依存する場合，
@samp{AC_LIBLTDL_INSTALLABLE}は検出に失敗する可能性があります．この場
合，libltdlのビルドとインストールは不必要です．}，@var{LIBLTDL}は
@samp{-lltdl}に，@var{LTDLINCL}は空に設定されます(それは，libltdlがラ
イブラリパスにある場合，@file{ltdl.h}がインクルードパスのどこかにある
という，暗黙の仮定です)．インストール可能なlibltdlのバージョンをビルド
する必要がある場合，@samp{$@{top_builddir@}/}で始まるそのパス名は，
@var{LIBLTDL}に保存され，@var{LTDLINCL}はコンビニエンスライブラリの場
合と同様に設定されます．

@c So, when you want to link a program with libltdl, be it a convenience,
@c installed or installable library, just compile with @samp{$(LTDLINCL)}
@c and link it with @samp{$(LIBLTDL)}, using libtool.
@c 
そのため，libltdlとプログラムをリンクしたいときは，それをインストール
された，またはインストール可能なコンビニエンスライブラリにし，すなわち，
libtoolを使用して，@var{LTDLINCL}を用いてコンパイルし，
@samp{$(LIBLTDL)}を用いてリンクしてください．

@c You should probably also add @samp{AC_LIBTOOL_DLOPEN} to your
@c @file{configure.in} @emph{before} @samp{AC_PROG_LIBTOOL}, otherwise
@c libtool will assume no dlopening mechanism is supported, and revert to
@c dlpreopening, which is probably not what you want.
@c 
おそらく@samp{AC_LIBTOOL_DLOPEN}も@file{configure.in}に，
@samp{AC_PROG_LIBTOOL}の@emph{前に}加えた方が良く，そうしない場合は，
libtoolはdlopenメカニズムがサポートされていないと仮定し，おそらく希望
していないdlpreopenに逆戻りします．

@c Avoid using the @code{-static} or @code{-all-static} switches when
@c linking programs with libltdl.  This will not work on all platforms,
@c because the dlopening functions may not be available for static linking.
@c 
libltdlとプログラムをリンクするとき，@code{-static}や
@code{-all-static}スイッチの使用を避けてください．dlopen関数はスタティッ
クリンクに対して利用可能でない可能性があるので，これはすべてのプラット
フォームで動作するわけではありません．

@c The following example shows you how to embed the convenience libltdl in
@c your package.  In order to use the installable variant just replace
@c @samp{AC_LIBLTDL_CONVENIENCE} with @samp{AC_LIBLTDL_INSTALLABLE}.  We
@c assume that libltdl was embedded using @samp{libtoolize --ltdl}.
@c 
以下の例は，パッケージにコンビニエンスlibltdlを埋め込む方法を示します．
インストール可能な形態を使用するために，@samp{AC_LIBLTDL_CONVENIENCE}
を@samp{AC_LIBLTDL_INSTALLABLE}で置換してください．我々は，libltdlが
@samp{libtoolize --ltdl}を使用して埋め込まれていると仮定しています．

@c configure.in:
@c 
configure.inは以下のようになります．
@example
...
dnl Enable building of the convenience library
dnl and set LIBLTDL accordingly
AC_LIBLTDL_CONVENIENCE
dnl Substitute LTDLINCL and LIBLTDL in the Makefiles
AC_SUBST(LTDLINCL)
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

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

INCLUDES = $(LTDLINCL)

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
@c @chapter Using libtool with other languages
@chapter 他の言語でlibtoolを使用する
@cindex C, not using
@cindex languages, non-C
@cindex C++, using

@c Libtool was first implemented in order to add support for writing shared
@c libraries in the C language.  However, over time, libtool is being
@c integrated with other languages, so that programmers are free to reap
@c the benefits of shared libraries in their favorite programming language.
@c 
libtoolは最初に，C言語での共有ライブラリを書くことに対するサポートを加
えるために実装されました．しかし，時間が経ち，プログラマが好みのプログ
ラム言語での共有ライブラリの便利さを自由に得られるように，libtoolは他
の言語と統合されています．

@c This chapter describes how libtool interacts with other languages,
@c and what special considerations you need to make if you do not use C.
@c 
この章は，libtoolが他の言語と相互作用する方法と，Cを用いない場合に必要
とされる特記事項を記述します．

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

@node C++ libraries
@c @section Writing libraries for C++
@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 Creating libraries of C++ code should be a fairly straightforward
@c process, because its object files differ from C ones in only three ways:
@c 
C++コードのライブラリを作成することは，そのオブジェクトファイルがCのも
のと三つの点で異なっているだけので，かなり簡単な処理になります．

@enumerate 1
@item
@c Because of name mangling, C++ libraries are only usable by the C++
@c compiler that created them.  This decision was made by the designers of
@c C++ in order to protect users from conflicting implementations of
@c features such as constructors, exception handling, and RTTI.
@c 
名前をmangleするため，C++ライブラリはC++コンパイラで作成されたものだけ
利用可能です．この決定は，コンストラクタ，例外処理，そしてRTTIのような
機能の実装との衝突からユーザを守るため，C++の設計者によってなされまし
た．

@item
@c On some systems, the C++ compiler must take special actions for the
@c dynamic linker to run dynamic (i.e., run-time) initializers.  This means
@c that we should not call @file{ld} directly to link such libraries, and
@c we should use the C++ compiler instead.
@c 
システムによっては，ダイナミックリンカがダイナミック(すなわち実行時)に
初期化の実行するため，C++コンパイラは特別な動作を行なう必要があります．
これは，そのようなライブラリとリンクするため，@file{ld}を直接呼び出す
べきではなく，その代わりにC++コンパイラを使用するべきだということを意
味します．

@item
@c C++ compilers will link some Standard C++ library in by default, but
@c libtool does not know which are these libraries, so it cannot even run
@c the inter-library dependence analyzer to check how to link it in.
@c Therefore, running @file{ld} to link a C++ program or library is deemed
@c to fail.
@c 
C++コンパイラは，いくつかの標準C++ライブラリとデフォルトでリンクします
が，libtoolは，これらのライブラリがどれかを知らないため，それに対して
リンクする方法を調査するため，ライブラリ内部の依存の解析さえ実行できま
せん．それゆえ，C++プログラムやライブラリとリンクするため@file{ld}を実
行すると失敗すると思われます．
@end enumerate

@c Because of these three issues, Libtool has been designed to always use
@c the C++ compiler to compile and link C++ programs and libraries.  In
@c some instances the @code{main()} function of a program must also be
@c compiled with the C++ compiler for static C++ objects to be properly
@c initialized.
@c 
これらの問題のため，C++プログラムとライブラリをコンパイルしリンクする
ために，常にC++コンパイラを使用するように設計されています．プログラム
の@code{main()}関数のインスタンスによっては，スタティックなC++オブジェ
クトを適切に初期化するため，C++コンパイラでコンパイルする必要があるも
のもあります．

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

@c Libtool is under constant development, changing to remain up-to-date
@c with modern operating systems.  If libtool doesn't work the way you
@c think it should on your platform, you should read this chapter to help
@c determine what the problem is, and how to resolve it.
@c 
libtoolは，現在のオペレーティングシステムで最新を保つよう変更しながら，
コンスタントに開発されていています．libtoolがプラットフォーム上で思っ
たように動作しない場合，問題点と解決方法を決定する助けとなる，この章を
読んだ方が良いでしょう．

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

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

@c Libtool comes with its own set of programs that test its capabilities,
@c and report obvious bugs in the libtool program.  These tests, too, are
@c constantly evolving, based on past problems with libtool, and known
@c deficiencies in other operating systems.
@c 
libtoolは，その能力をテストし，libtoolプログラムの明らかなバグを報告す
る，プログラムの独自のセットとともにあります．これらのテストは，
libtoolの過去の問題と他のオペレーティングシステム内の既知の欠陥を基に
して，絶えず進化もしています．

@c As described in the @file{INSTALL} file, you may run @kbd{make check}
@c after you have built libtool (possibly before you install it) in order
@c to make sure that it meets basic functional requirements.
@c 
@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
@c @subsection Description of test suite
@subsection テストスイートの記述

@c Here is a list of the current programs in the test suite, and what they
@c test for:
@c 
テストスイートの現在のプログラムと，それらがテストするもののリストは以
下のようになっています．

@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
@c These programs check to see that the @file{cdemo} subdirectory of the
@c libtool distribution can be configured and built correctly.
@c 
これらのプログラムは，libtool配布物の@file{cdemo}サブディレクトリが，
正しくコンフィグレーションされ，ビルドされることを知るための調査を行な
います．

@c The @file{cdemo} subdirectory contains a demonstration of libtool
@c convenience libraries, a mechanism that allows build-time static
@c libraries to be created, in a way that their components can be later
@c linked into programs or other libraries, even shared ones.
@c 
@file{cdemo}サブディレクトリは，libtoolのコンビニエンスライブラリのデ
モンストレーションと，ビルド時にスタティックライブラリの作成を可能とす
るメカニズムを含んでいて，コンポーネントが共有ライブラリであったとして
も，プログラムや他のライブラリと後でリンクされることを可能とする方法で
す．

@c The tests @file{cdemo-make.test} and @file{cdemo-exec.test} are executed
@c three times, under three different libtool configurations:
@c @file{cdemo-conf.test} configures @file{cdemo/libtool} to build both
@c static and shared libraries (the default for platforms that support
@c both), @file{cdemo-static.test} builds only static libraries
@c (@samp{--disable-shared}), and @file{cdemo-shared.test} builds only
@c shared libraries (@samp{--disable-static}).
@c 
@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
@c These programs check to see that the @file{demo} subdirectory of the
@c libtool distribution can be configured, built, installed, and
@c uninstalled correctly.
@c 
これらのプログラムは，libtool配布物の@file{demo}サブディレクトリが，コ
ンフィグレーション，ビルド，インストール，そしてアンインストールが正し
くできることを知るために調査します．

@c The @file{demo} subdirectory contains a demonstration of a trivial
@c package that uses libtool.  The tests @file{demo-make.test},
@c @file{demo-exec.test}, @file{demo-inst.test} and
@c @file{demo-unst.test} are executed four times, under four different
@c libtool configurations: @file{demo-conf.test} configures
@c @file{demo/libtool} to build both static and shared libraries,
@c @file{demo-static.test} builds only static libraries
@c (@samp{--disable-shared}), and @file{demo-shared.test} builds only
@c shared libraries (@samp{--disable-static}).
@c @file{demo-nofast.test} configures @file{demo/libtool} to
@c disable the fast-install mode (@samp{--enable-fast-install=no}).
@c @file{demo-pic.test} configures @file{demo/libtool} to
@c prefer building PIC code (@samp{--with-pic}), @file{demo-nopic.test}
@c to prefer non-PIC code (@samp{--without-pic}).
@c 
@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
@c Many systems cannot link static libraries into shared libraries.
@c libtool uses a @code{deplibs_check_method} to prevent such cases.
@c This tests checks whether libtool's @code{deplibs_check_method}
@c works properly.
@c 
スタティックライブラリを共有ライブラリにリンク不可能なシステムもたくさ
んあります．そのような場合を避けるため，libtoolは
@code{deplibs_check_method}を使用します．このテストは，libtoolの
@code{deplibs_check_method}が正しく動作するかどうか調査します．

@item hardcode.test
@pindex hardcode.test
@c On all systems with shared libraries, the location of the library can be
@c encoded in executables that are linked against it @pxref{Linking
@c executables}.  This test checks the conditions under which your system
@c linker hardcodes the library location, and guarantees that they
@c correspond to libtool's own notion of how your linker behaves.
@c 
共有ライブラリを持つすべてのシステムで，実行形式に対しリンクされるライ
ブラリの位置が実行形式の内部に符号化されるはずです@pxref{Linking
executables}．このテストは，システムリンカがライブラリの位置をハードコー
ドし，libtool自身のリンカの動作方法の概念と一致することを保証する条件
を調査します．

@item build-relink.test
@pindex build-relink.test
@c Checks whether variable @var{shlibpath_overrides_runpath} is properly
@c set.  If the test fails and @var{VERBOSE} is set, it will indicate what
@c the variable should have been set to.
@c 
変数@var{shlibpath_overrides_runpath}が正しく設定されているかどうか調
査します．テストが失敗し，@var{VERBOSE}が設定されている場合，それは変
数を設定する必要がないことを示します．

@item noinst-link.test
@pindex noinst-link.test
@c Checks whether libtool will not try to link with a previously installed
@c version of a library when it should be linking with a just-built one.
@c 
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
@c These programs check to see that the @file{depdemo} subdirectory of the
@c libtool distribution can be configured, built, installed, and
@c uninstalled correctly.
@c 
これらのプログラムは，libtool配布物の@file{depdemo}サブディレクトリの，
コンフィグレーション，ビルド，インストール，そしてアンインストールを，
正しく行えることを判定するための調査を行います．

@c The @file{depdemo} subdirectory contains a demonstration of inter-library
@c dependencies with libtool.  The test programs link some interdependent
@c libraries.
@c 
@file{depdemo}サブディレクトリは，libtoolに依存する内部ライブラリのデ
モンストレーションを含みます．このテストプログラムは，いくつかの交互依
存しているライブラリをリンクします．

@c The tests @file{depdemo-make.test}, @file{depdemo-exec.test},
@c @file{depdemo-inst.test} and @file{depdemo-unst.test} are executed
@c four times, under four different libtool configurations:
@c @file{depdemo-conf.test} configures @file{depdemo/libtool} to build both
@c static and shared libraries, @file{depdemo-static.test} builds only static
@c libraries (@samp{--disable-shared}), and @file{depdemo-shared.test} builds
@c only shared libraries (@samp{--disable-static}).
@c @file{depdemo-nofast.test} configures @file{depdemo/libtool} to
@c disable the fast-install mode (@samp{--enable-fast-install=no}.
@c 
テストの，@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
@c These programs check to see that the @file{mdemo} subdirectory of the
@c libtool distribution can be configured, built, installed, and
@c uninstalled correctly.
@c 
これらのプログラムは，libtool配布物の@file{mdemo}サブディレクトリが，
コンフィグレーション，ビルド，インストール，そしてアンインストールが正
しくできることを知るために調査します．

@c The @file{mdemo} subdirectory contains a demonstration of a package that
@c uses libtool and the system independent dlopen wrapper @file{libltdl} to
@c load modules.  The library @file{libltdl} provides a dlopen wrapper for
@c various platforms (Linux, Solaris, HP/UX etc.) including support for
@c dlpreopened modules (@pxref{Dlpreopening}).
@c 
@file{mdemo}サブディレクトリは，libtoolと，システム非依存のモジュール
ロードのための，dlopenラッパー@file{libltdl}を使用するパッケージのデモ
ンストレーションを含みます．ライブラリ@file{libltdl}は，様々なプラット
フォーム(Linux，Solaris，HP/UX等)に対する，dlpreopenモジュールに対する
サポートを含む(@pxref{Dlpreopening})dlopenラッパーを提供します．

@c The tests @file{mdemo-make.test}, @file{mdemo-exec.test},
@c @file{mdemo-inst.test} and @file{mdemo-unst.test} are executed
@c three times, under three different libtool configurations:
@c @file{mdemo-conf.test} configures @file{mdemo/libtool} to build both
@c static and shared libraries, @file{mdemo-static.test} builds only static
@c libraries (@samp{--disable-shared}), and @file{mdemo-shared.test} builds
@c only shared libraries (@samp{--disable-static}).
@c 
テストの@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
@c This test checks whether libtool's @code{--dry-run} mode works properly.
@c 
このテストは，libtoolの@code{--dry-run}モードが正しく動作するかどうか
を調査します．

@item assign.test
@pindex assign.test
@c Checks whether we don't put break or continue on the same
@c line as an assignment in the libtool script.
@c 
libtoolスクリプト内の割り当てられている同じ行で，停止したり，続けたり
しないかどうか調査します．

@item link.test
@pindex link.test
@c This test guarantees that linking directly against a non-libtool static
@c library works properly.
@c 
このテストは，libtoolでないスタティックライブラリに対する直接的なリン
クが正しく動作することを保証します．

@item link-2.test
@pindex link-2.test
@c This test makes sure that files ending in @samp{.lo} are never linked
@c directly into a program file.
@c 
このテストは，@samp{.lo}で終わるファイルがプログラムファイルに直接リン
クされないことを確かめます．

@item nomode.test
@pindex nomode.test
@c Check whether we can actually get help for libtool.
@c 
実際にlibtoolの助けが可能かどうか調査します．

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

@item sh.test
@pindex sh.test
@c Checks whether a `test' command was forgotten in libtool.
@c 
`test'コマンドがlibtoolで忘れられていないか調査します．

@item suffix.test
@pindex suffix.test
@c When other programming languages are used with libtool (@pxref{Other
@c languages}), the source files may end in suffixes other than @samp{.c}.
@c This test validates that libtool can handle suffixes for all the file
@c types that it supports, and that it fails when the suffix is invalid.
@c 
他のプログラミング言語がlibtoolで使用されるとき(@pxref{Other
languages})，ソースファイルは@samp{.c}以外の接尾子で終わるかもしれませ
ん．このテストは，サポートするすべてのファイル形式に対する接尾子を扱う
こと可能で，接尾子が不当なときは失敗することを確認します．

@end table

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

@c Each of the above tests are designed to produce no output when they are
@c run via @kbd{make check}.  The exit status of each program tells the
@c @file{Makefile} whether or not the test succeeded.
@c 
上記のそれぞれのテストは，@kbd{make check}を実行するとき出力を生成しな
いように設計されています．それぞれのプログラムの終了ステータスで，テス
トが成功しなかったかどうかを@file{Makefile}に伝えます．

@c If a test fails, it means that there is either a programming error in
@c libtool, or in the test program itself.
@c 
テストが失敗した場合，それはlibtool内のプログラムエラー，またはプログ
ラム自身のエラーのどちらかが存在することを意味します．

@c To investigate a particular test, you may run it directly, as you would
@c a normal program.  When the test is invoked in this way, it produces
@c output which may be useful in determining what the problem is.
@c 
特定のテストを調査するために，通常のプログラムで行うように，直接実行す
ることが可能です．テストがこの方法で呼び出されたとき，それは，問題を決
定するのに役に立ちそうな出力を生成します．

@c Another way to have the test programs produce output is to set the
@c @var{VERBOSE} environment variable to @samp{yes} before running them.
@c For example, @kbd{env VERBOSE=yes make check} runs all the tests, and
@c has each of them display debugging information.
@c 
テストプログラムに出力を生成させるもうひとつの方法は，実行前に
@var{VERBOSE}環境変数を@samp{yes}に設定することです．例えば，@kbd{env
VERBOSE=yes make check}ですべてのテストが実行され，それぞれについてデ
バッグ情報の表示が得られます．

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

@c If you think you have discovered a bug in libtool, you should think
@c twice: the libtool maintainer is notorious for passing the buck (or
@c maybe that should be ``passing the bug'').  Libtool was invented to fix
@c known deficiencies in shared library implementations, so, in a way, most
@c of the bugs in libtool are actually bugs in other operating systems.
@c However, the libtool maintainer would definitely be happy to add support
@c for somebody else's buggy operating system.  [I wish there was a good
@c way to do winking smiley-faces in Texinfo.]
@c 
libtoolにバグを発見したと考えた場合，もう一度考えた直したほうが良いで
しょう．libtool管理者は，責任転嫁(または``バグを通過させる''かもしれま
せん)で有名です@footnote{訳注：原文では，passing the buck(責任転嫁)と
passing the bug(バグを通過させる)をかけています}．libtoolは，共有ライ
ブラリの実装で既知の欠陥を修正するために開発されたので，libtoolのバグ
のほとんどは，ある程度は，他のオペレーティングシステムのバグになります．
しかし，libtool の管理者は，他人のバギーなオペレーティングシステムに対
するサポートを加えることを，確かに楽しんでいます．[Texinfoでウインクし
ている笑顔を表示する，いい方法があれば良いのですが．]

@c Genuine bugs in libtool include problems with shell script portability,
@c documentation errors, and failures in the test suite (@pxref{Libtool
@c test suite}).
@c 
libtoolの純粋なバグは，シェルスクリプトの移植性の問題，ドキュメントの
エラー，そしてテストスイートの失敗(@pxref{Libtool test suite})を含みま
す．

@c First, check the documentation and help screens to make sure that the
@c behaviour you think is a problem is not already mentioned as a feature.
@c 
最初に，問題と考えられる動作が，既に特徴として言及されていないことを確
かめるために，ドキュメントとへルプ画面を調査してください．

@c Then, you should read the Emacs guide to reporting bugs (@pxref{Bugs, ,
@c Reporting Bugs, emacs, The Emacs Manual}).  Some of the details
@c listed there are specific to Emacs, but the principle behind them is a
@c general one.
@c 
そして，バグを報告することに関するEmacsガイド(@pxref{Bugs, , Reporting
Bugs, emacs, The Emacs Manual})を読んでください．リストアップされてい
る詳細は，Emacs特有のものもありますが，基本的な原則は一般的なものです．

@c Finally, send a bug report to @value{BUGADDR} with any appropriate
@c @emph{facts}, such as test suite output (@pxref{When tests fail}), all
@c the details needed to reproduce the bug, and a brief description of why
@c you think the behaviour is a bug.  Be sure to include the word
@c ``libtool'' in the subject line, as well as the version number you are
@c using (which can be found by typing @kbd{libtool --version}).
@c 
最後に，テストスイートの出力(@pxref{When tests fail})，バグを再生成す
るのに必要なすべての詳細，そして，動作がバグだと考えられる理由の概要の
ような適切なあらゆる@emph{事実}とともに，@value{BUGADDR}にバグの報告を
送ってください．サブジェクト行に，単語``libtool''と，同様に使用してい
るバージョンナンバー(それは，@kbd{ltconfig --version}の入力で分かりま
す)が含まれていることを確認してください．

@node Maintaining
@c @chapter Maintenance notes for libtool
@chapter libtoolの管理用メモ

@c This chapter contains information that the libtool maintainer finds
@c important.  It will be of no use to you unless you are considering
@c porting libtool to new systems, or writing your own libtool.
@c 
この章は，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
@c @section Porting libtool to new systems
@section 新しいシステムへのlibtoolの移植

@c Before you embark on porting libtool to an unsupported system, it is
@c worthwhile to send e-mail to @value{MAILLIST}, to make sure that you are
@c not duplicating existing work.
@c 
サポートされていないシステムへのlibtoolの移植に乗り出す前に，既存の仕
事と重複していないことを確認するために，@value{MAILLIST}に電子メールを
送る価値はあります．

@c If you find that any porting documentation is missing, please complain!
@c Complaints with patches and improvements to the documentation, or to
@c libtool itself, are more than welcome.
@c 
移植の文章が見つからない場合，文句を言ってください！パッチを用いた苦情
と，ドキュメントやlibtool自身の改良は十分に歓迎されます．

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

@node Information sources
@c @subsection Information sources
@subsection 情報源

@c Once it is clear that a new port is necessary, you'll generally need the
@c following information:
@c 
新たな移植の必要性が明らかになると，通常，以下の情報が必要となります．

@table @asis
@c @item canonical system name
@item 標準的なシステム名
@c You need the output of @code{config.guess} for this system, so that you
@c can make changes to the libtool configuration process without affecting
@c other systems.
@c 
他のシステムに影響しないようにlibtoolのコンフィグレーション処理を変更
可能にするため，このシステムに対する@code{config.guess}の出力が必要で
す．

@c @item man pages for @code{ld} and @code{cc}
@item @code{ld}と@code{cc}に対するmanページ
@c These generally describe what flags are used to generate PIC, to create
@c shared libraries, and to link against only static libraries.  You may
@c need to follow some cross references to find the information that is
@c required.
@c 
共有ライブラリを作成するため，共有ライブラリのみにリンクするため，そし
て，PICを生成するために使用するフラグを，通常これらは記述しています．
必要な情報を見つけるため，以下の相互参照が必要かもしれません．

@c @item man pages for @code{ld.so}, @code{rtld}, or equivalent
@item @code{ld.so}，@code{rtld}，または，その同等物のmanページ
@c These are a valuable resource for understanding how shared libraries are
@c loaded on the system.
@c 
これらは，システムで共有ライブラリがロードされる仕組みを理解するための，
有益な情報源です．

@c @item man page for @code{ldconfig}, or equivalent
@item @code{ldconfig}やその同等物のmanページ
@c This page usually describes how to install shared libraries.
@c 
このページは，通常，共有ライブラリをインストールする方法を記述していま
す．

@c @item output from @kbd{ls -l /lib /usr/lib}
@item @kbd{ls -l /lib /usr/lib}の出力
@c This shows the naming convention for shared libraries on the system,
@c including which names should be symbolic links.
@c 
これは，システムの共有ライブラリの命名規則を表示し，それは，シンボリッ
クリンクの名前も含んでいます．

@c @item any additional documentation
@item あらゆる追加の文章
@c Some systems have special documentation on how to build and install
@c shared libraries.
@c 
共有ライブラリのビルドとインストール方法の特別な文章があるシステムもあ
ります．
@end table

@c If you know how to program the Bourne shell, then you can complete the
@c port yourself; otherwise, you'll have to find somebody with the relevant
@c skills who will do the work.  People on the libtool mailing list are
@c usually willing to volunteer to help you with new ports, so you can send
@c the information to them.
@c 
Bourneシェルプログラムの方法を知っている場合，完全に自分で移植すること
が可能です．それ以外の場合，関連する作業を行う腕のある人を探す必要があ
ります．libtoolメーリングリストの人々は，新たな移植への援助を志願する
意思があるので，彼らに情報を送ることができます．

@c To do the port yourself, you'll definitely need to modify the
@c @code{libtool.m4} macros in order to make platform-specific changes to
@c the configuration process.  You should search that file for the
@c @code{PORTME} keyword, which will give you some hints on what you'll
@c need to change.  In general, all that is involved is modifying the
@c appropriate configuration variables (@pxref{libtool script contents}).
@c 
独自に移植するためには，プラットフォーム特有のコンフィグレーションプロ
セスの変更を行うため，@code{libtool.m4}マクロを明確に修正する必要があ
ります．@code{PORTME}キーワードに対するファイルを検索する必要があり，
それで，変更に必要なヒントを得られるでしょう．一般的に，呼び出されるも
のは，適切なコンフィグレーション変数の編集です(@pxref{libtool script
contents})．

@c Your best bet is to find an already-supported system that is similar to
@c yours, and make your changes based on that.  In some cases, however,
@c your system will differ significantly from every other supported system,
@c and it may be necessary to add new configuration variables, and modify
@c the @code{ltmain.in} script accordingly.  Be sure to write to the
@c mailing list before you make changes to @code{ltmain.in}, since they may
@c have advice on the most effective way of accomplishing what you want.
@c 
最善策は，既にサポートされている良く似たシステムを見つけ，変更の基本と
することです．しかし，システムが他のサポートされているシステムと，大き
く異なる場合や，新しいコンフィグレーション変数を加え，それに応じて
@code{ltmain.in}スクリプトを変更する必要がある場合もあります．欲しいも
のを達成するための，最も効果的な方法の助言がある可能性があるので，
@code{ltmain.in}を変更する前に，メーリングリストに書いて確認してくださ
い．

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

@c Since version 1.2c, libtool has re-introduced the ability to do
@c inter-library dependency on some platforms, thanks to a patch by Toshio
@c Kuratomi @email{badger@@prtr-13.ucsc.edu}.  Here's a shortened version
@c of the message that contained his patch:
@c 
バージョン1.2c以降，libtoolは，Toshio Kuratomi
@email{badger@@prtr-13.ucsc.edu}のパッチのおかげで，ライブラリ内部の依
存性を可能とする機能が再導入されてるプラットフォームもあります．パッチ
に含まれるメッセージの短いバージョンは以下のようになります．

@c The basic architecture is this: in @file{libtool.m4}, the person who
@c writes libtool makes sure @samp{$deplibs} is included in
@c @samp{$archive_cmds} somewhere and also sets the variable
@c @samp{$deplibs_check_method}, and maybe @samp{$file_magic_cmd} when
@c @samp{deplibs_check_method} is file_magic.
@c 
基本的な体系はこのようになります．@file{libtool.m4}で，libtoolを書いて
いる人は，@samp{$deplibs}が@samp{$archive_cmds}のどこかに含まれている
こと，また，変数@samp{$deplibs_check_method}と，
@samp{deplibs_check_method}がファイルマジックの場合は
@samp{$file_magic_cmd}が設定されていることを確認します．

@c @samp{deplibs_check_method} can be one of five things:
@c 
@samp{deplibs_check_method}は，以下の五つの内の一つのはずです．
@table @samp
@item file_magic [@var{regex}]
@vindex file_magic
@vindex file_magic_cmd
@vindex file_magic_test_file
@c looks in the library link path for libraries that have the right
@c libname.  Then it runs @samp{$file_magic_cmd} on the library and checks
@c for a match against the extended regular expression @var{regex}.  When
@c @var{file_magic_test_file} is set by @file{libtool.m4}, it is used as an
@c argument to @samp{$file_magic_cmd} in order to verify whether the
@c regular expression matches its output, and warn the user otherwise.
@c 
ライブラリリンクパスで正しいlibnameを持つライブラリを探します．そして，
ライブラリで@samp{$file_magic_cmd}を実行し，正規表現@var{regex}に一致
することを調査します．@var{file_magic_test_file}が@file{libtool.m4}に
よって設定されているとき，正規表現がその出力と一致するかどうかを検証し，
それ以外ではユーザが警告を受けるようにするため，それは
@samp{$file_magic_cmd}への引数として使用されます．

@item test_compile
@vindex test_compile
@c just checks whether it is possible to link a program out of a list of
@c libraries, and checks which of those are listed in the output of
@c @code{ldd}.  It is currently unused, and will probably be dropped in the
@c future.
@c 
ライブラリリストの出力以外とプログラムがリンク可能かどうかのみを調査し，
それらが@code{ldd}の出力でリストアップされていることを調査します．それ
は現在，使用されていないので，将来は打ち切る可能性があります．

@item pass_all
@vindex pass_all
@c will pass everything without any checking.  This may work on platforms
@c in which code is position-independent by default and inter-library
@c dependencies are properly supported by the dynamic linker, for example,
@c on DEC OSF/1 3 and 4.
@c 
調査せず，すべて通過します．例えばDEC OSF/1 3 と 4のような，デフォルト
で，コードが位置に依存せず，ライブラリ内部の依存性がダイナミックリンカ
で適切にサポートされているプラットフォームで，これは動作するでしょう．

@item none
@vindex none
@c It causes deplibs to be reassigned deplibs="".  That way
@c @samp{archive_cmds} can contain deplibs on all platforms, but not have
@c deplibs used unless needed.
@c 
deplibsをdeplibs=""に再設定します．そうすれば，@samp{archive_cmds}は，
すべてのプラットフォームでdeplibsを含むはずですが，deplibは必要がなけ
れば使用されません．

@item unknown
@vindex unknown
@c is the default for all systems unless overridden in @file{libtool.m4}.
@c It is the same as @samp{none}, but it documents that we really don't
@c know what the correct value should be, and we welcome patches that
@c improve it.
@c 
@file{libtool.m4}で優先されない場合，すべてのシステムでデフォルトです．
それは@samp{none}と同じですが，正しい値が何か，我々が本当に知らないこ
とを文章化していて，我々はそれを改善するパッチを歓迎します．
@end table

@c Then in @file{ltmain.in} we have the real workhorse: a little
@c initialization and postprocessing (to setup/release variables for use
@c with eval echo libname_spec etc.) and a case statement that decides
@c which method is being used.  This is the real code... I wish I could
@c condense it a little more, but I don't think I can without function
@c calls.  I've mostly optimized it (moved things out of loops, etc) but
@c there is probably some fat left.  I thought I should stop while I was
@c ahead, work on whatever bugs you discover, etc before thinking about
@c more than obvious optimizations.
@c 
@file{ltmain.in}で，我々は本当に一生懸命作業しました．それは，
(libname_spec等の評価を使用するための変数を設定/リリース行う)小さな初
期化と移植，そして使用するメソッドを決定するケース文です．これは，実際
にはコードです...  もう少し凝縮できれば良かったのですが，関数呼び出し
を用いずにできるとは思えませんでした．私はほとんどの(ループの外に出す
等の)最適化を行いましたが，余分なものがあるかもしれません．明確な最適
化を考える前に，前進を止め，発見されたバグに対して作業すべきだと考えま
した．

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

@c This table describes when libtool was last known to be tested on
@c platforms where it claims to support shared libraries:
@c 
以下の表は，共有ライブラリのサポートを謡っているプラットフォームで，
libtoolがテストされたことが分かっている最後の時期を記述しています．

@example
@include PLATFORMS-ja
@end example

@c Note: The vendor-distributed HP-UX @code{sed}(1) programs are horribly
@c broken, and cannot handle libtool's requirements, so users may report
@c unusual problems.  There is no workaround except to install a working
@c @code{sed} (such as GNU @code{sed}) on these systems.
@c 
注：ベンダー配布されているHP-UXの@code{sed}(1)プログラムは，ひどく壊れ
ていて，libtoolの要求を処理することができないため，ユーザは異常の問題
を報告する可能性があります．これらのシステムで動作する(GNU @code{sed})
のような@code{sed}をインストールする以外に，回避方法はありません．

@c Note: The vendor-distributed NCR MP-RAS @code{cc} programs emits
@c copyright on standard error that confuse tests on size of
@c @file{conftest.err}.  The workaround is to specify @code{CC}
@c when run @code{configure} with @kbd{CC='cc -Hnocopyr'}.
@c 
注：ベンダー配布されているNCR MP-RAS @code{cc}プログラムは，標準エラー
に著作権を出力し，@file{conftest.err}の大きさのテストで混乱します．回
避方法は，@code{configure}を実行するとき，@kbd{CC='cc -Hnocopyr'}を用
いて@code{CC}を指定します．

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

@c This section is dedicated to the sanity of the libtool maintainers.  It
@c describes the programs that libtool uses, how they vary from system to
@c system, and how to test for them.
@c 
このセクションは，libtoolの管理者の健康に捧げます．それは，libtoolが使
用するプログラム，システムごとの違い，そしてテストの方法を記述します．

@c Because libtool is a shell script, it can be difficult to understand
@c just by reading it from top to bottom.  This section helps show why
@c libtool does things a certain way.  Combined with the scripts
@c themselves, you should have a better sense of how to improve libtool, or
@c write your own.
@c 
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 dependent libraries.
* Archivers::                   Programs that create static archives.
@end menu

@node References
@c @subsection References
@subsection リファレンス

@c The following is a list of valuable documentation references:
@c 
以下は，価値のある文章の参照リストです．

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

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

@item
@c Compaq's Tru64 UNIX online documentation is at
@c (@url{http://tru64unix.compaq.com/faqs/publications/pub_page/doc_list.html})
@c with C++ documentation at
@c (@url{http://tru64unix.compaq.com/cplus/docs/index.htm}).
@c 
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
@c Hewlett-Packard has online documentation at
@c (@url{http://docs.hp.com/index.html}).
@c 
Hewlett-Packardは(@url{http://docs.hp.com/index.html})にオンラインドキュ
メントがあります．

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

@node Compilers
@c @subsection Compilers
@subsection コンパイラ

@c The only compiler characteristics that affect libtool are the flags
@c needed (if any) to generate PIC objects.  In general, if a C compiler
@c supports certain PIC flags, then any derivative compilers support the
@c same flags.  Until there are some noteworthy exceptions to this rule,
@c this section will document only C compilers.
@c 
libtoolに影響するコンパイラの特徴は，PICオブジェクトを生成するための
(存在する場合は)必要なフラグのみです．一般的に，Cコンパイラが特定のPIC
フラグをサポートする場合，あらゆる派生的なコンパイラは同じフラグをサポー
トします．この規則に対し，注目すべき若干の例外があるまでは，このセクショ
ンではCコンパイラのみを説明します．

@c The following C compilers have standard command line options, regardless
@c of the platform:
@c 
プラットフォームに関係なく，以下のCコンパイラは，標準のコマンドライオ
プションがあります．

@table @code
@item gcc
@c This is the GNU C compiler, which is also the system compiler for many
@c free operating systems (FreeBSD, GNU/Hurd, GNU/Linux, Lites, NetBSD, and
@c OpenBSD, to name a few).
@c 
これはGNU Cコンパイラで，多くのフリーオペレーティングシステム(少し例を
あげると，FreeBSD，GNU/Hurd，GNU/Linux，Lites，NetBSD，そしてOpenBSDで
す) に対する，システムコンパイラでもあります．

@c The @samp{-fpic} or @samp{-fPIC} flags can be used to generate
@c position-independent code.  @samp{-fPIC} is guaranteed to generate
@c working code, but the code is slower on m68k, m88k, and Sparc chips.
@c However, using @samp{-fpic} on those chips imposes arbitrary size limits
@c on the shared libraries.
@c 
@samp{-fpic}や@samp{-fPIC}フラグは，位置に依存しないコードを生成するた
めに使用可能です．@samp{-fPIC}は動作するコードを生成することを保証しま
すが，m68k，m88k，そしてSparcチップ上ではコードは遅くなります．しかし，
これらのチップで@samp{-fpic}を使用すると，共有ライブラリでの自由なサイ
ズが強制的に制限されます．
@end table

@c The rest of this subsection lists compilers by the operating system that
@c they are bundled with:
@c 
このサブセクションの残りは，バンドルされているオペレーティングシステム
のコンパイラをリストアップします．

@c FIXME these should all be better-documented

@table @code
@item aix3*
@itemx aix4*
@c Most AIX compilers have no PIC flags, since AIX (with the exception of
@c AIX for IA-64) runs on PowerPC and RS/6000 chips. @footnote{All code compiled
@c for the PowerPC and RS/6000 chips (@code{powerpc-*-*}, @code{powerpcle-*-*},
@c and @code{rs6000-*-*}) is position-independent, regardless of the operating
@c system or compiler suite.  So, ``regular objects'' can be used to build
@c shared libraries on these systems and no special PIC compiler flags are
@c required.}
@c 
(IA-64のAIX以外)AIXはPowerPCとRS/6000チップに移植されているので，ほと
んどのAIXコンパイラにはPICフラグがありません．@footnote{PowerPCと
RS/6000チップ(@code{powerpc-*-*}，@code{powerpcle-*-*}，そして
@code{rs6000-*-*})に対しコンパイルされているすべてのコードは，オペレー
ティングシステムやコンパイラスイートに関係なく，位置に依存しません．そ
のため，``標準オブジェクト''はこれらのシステム上で共有ライブラリのビル
ドで使用され，特別なPICコンパイラフラグは要求されません．}

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

@item osf3*
@c Digital/UNIX 3.x does not have PIC flags, at least not on the PowerPC
@c platform.
@c 
Digital/UNIX 3.xは，少なくともPowerPCプラットフォームでなければ，PICフ
ラグはありません．

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

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

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

@c On all known systems, a reloadable object can be created by running
@c @kbd{ld -r -o @var{output}.o @var{input1}.o @var{input2}.o}.  This
@c reloadable object may be treated as exactly equivalent to other
@c objects.
@c 
すべての既知のシステム上で，リロード可能なオブジェクトは@kbd{ld -r -o
@var{output}.o @var{input1}.o @var{input2}.o}を実行することで生成可能
です．このリロード可能なオブジェクトは，他のオブジェクトと完全な同義語
として扱うことが可能です．

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

@c On most modern platforms the order that dependent libraries are listed
@c has no effect on object generation.  In theory, there are platforms
@c which require libraries which provide missing symbols to other libraries
@c to listed after those libraries whose symbols they provide.
@c 
ほとんどの近代的なプラットフォームでは，依存するライブラリがリストアッ
プされる順序はオブジェクトの生成で影響がありません．理論上，シンボルを
提供しているライブラリの後に，リストアップされている他のライブラリに足
りないシンボルを提供するライブラリを要求するプラットフォームがあります．

@c Particularly, if a pair of static archives each resolve some of the
@c other's symbols, it might be necessary to list one of those archives
@c both before and after the other one.  Libtool does not currently cope
@c with this situation well, since dupicate libraries are removed from
@c the link line by default.  Libtool provides the command line option
@c @samp{--preserve-dup-deps} to preserve all duplicate dependencies
@c in cases where it is necessary.
@c 
特に，一組のスタティックアーカイブのそれぞれが，他のシンボルのいくつか
を解決する場合，それらのアーカイブの前後両方に他のものをリストアップす
ることが必要かもしれません．重複したライブラリはリンク行からデフォルト
で削除されるので，libtoolは，現在この状況に十分に対処していません．こ
れが必要な状況では，すべての重複する依存性を避けるため、libtoolはコマ
ンドラインオプション@samp{--preserve-dup-deps}を提供しています．

@node Archivers
@c @subsection Archivers
@subsection アーカイバ

@c On all known systems, building a static library can be accomplished by
@c running @kbd{ar cru lib@var{name}.a @var{obj1}.o @var{obj2}.o @dots{}},
@c where the @samp{.a} file is the output library, and each @samp{.o} file is an
@c object file.
@c 
すべての既知のシステム上で，スタティックライブラリのビルドは，@kbd{ar
cru lib@var{name}.a @var{obj1}.o @var{obj2}.o @dots{}}の実行で完成する
はずで，そこでは，@samp{.a}ファイルは出力ライブラリで，それぞれの
@samp{.o} ファイルはオブジェクトファイルです．

@c On all known systems, if there is a program named @code{ranlib}, then it
@c must be used to ``bless'' the created library before linking against it,
@c with the @kbd{ranlib lib@var{name}.a} command.  Some systems, like Irix,
@c use the @code{ar ts} command, instead.
@c 
すべての既知のシステム上で，@code{ranlib}という名のプログラムがある場
合，リンクする前に@kbd{ranlib lib@var{name}.a}コマンドを用いて，作成さ
れるライブラリを``祝福''するために使用する必要があります．Irixのように，
代わりに@code{ar ts}を使用するシステムもあります．

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

@c Since version 1.4, the @code{libtool} script is generated by
@c @code{configure} (@pxref{Configuring}).  In earlier versions,
@c @code{configure} achieved this by calling a helper script called
@c @file{ltconfig}.  From libtool version 0.7 to 1.0, this script
@c simply set shell variables, then sourced the libtool backend,
@c @code{ltmain.sh}.  @code{ltconfig} from libtool version 1.1 through 1.3
@c inlined the contents of @code{ltmain.sh} into the generated
@c @code{libtool}, which improved performance on many systems.  The tests
@c that @file{ltconfig} used to perform are now kept in @file{libtool.m4}
@c where thay can be written using Autoconf.  This has the runtime
@c performance benefits of inlined @code{ltmain.sh}, @emph{and} improves
@c the build time a little while considerably easing the amount of raw
@c shell code that used to need maintaining.
@c 
バージョン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{そして}，管理が必要な生のシェルコードの量をかなり取
り除くことで，ビルド時間を短くする改善を行いました．

@c The convention used for naming variables which hold shell commands for
@c delayed evaluation, is to use the suffix @code{_cmd} where a single
@c line of valid shell script is needed, and the suffix @code{_cmds} where
@c multiple lines of shell script @strong{may} be delayed for later
@c evaluation.  By convention, @code{_cmds} variables delimit the
@c evaluation units with the @code{~} character where necessary.
@c 
後で評価するもの対するシェルコマンドを保持する変数の命名に使用される規
則は，有効な単一行のシェルスクリプトが必要とされるところで接尾子
@code{_cmd}，複数行のシェルスクリプトが後で評価することが@strong{可能
な}ところで接尾子@code{_cmds}を使用することです．規則では，
@code{_cmds}変数は，必要なところで，@code{~}文字で評価ユニットを区切り
ます．

@c Here is a listing of each of the configuration variables, and how they
@c are used within @code{ltmain.sh} (@pxref{Configuring}):
@c 
それぞれのコンフィグレーション変数と，@code{ltmain.sh}で使用する方法の
リストは，以下のようになります(@pxref{Configuring})．

@defvar AR
@c The name of the system library archiver.
@c 
システムライブラリアーカイバの名前です．
@end defvar

@defvar CC
@c The name of the C compiler used to configure libtool.
@c 
ibtoolをコンフィグレーションするために使用するCコンパイラの名前です．
@end defvar

@defvar LD
@c The name of the linker that libtool should use internally for reloadable
@c linking and possibly shared libraries.
@c 
リロード可能にするリンクとおそらく共有ライブラリに対し，libtoolが内部
で使用するリンカの名前です．
@end defvar

@defvar NM
@c The name of a BSD-compatible @code{nm} program, which produces listings
@c of global symbols in one the following formats:
@c 
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
@c Set to the name of the ranlib program, if any.
@c 
存在する場合，ranlibプログラムの名前を設定します．
@end defvar

@defvar allow_undefined_flag
@c The flag that is used by @samp{archive_cmds} in order to declare that
@c there will be unresolved symbols in the resulting shared library.
@c Empty, if no such flag is required.  Set to @samp{unsupported} if there
@c is no way to generate a shared library with references to symbols that
@c aren't defined in that library.
@c 
結果として生じる共有ライブラリに，未解決のシンボルがあることを宣言する
ために，@samp{archive_cmds}で使用されるフラグです．そのようなフラグが
不要な場合は空です．ライブラリで定義されていないシンボルを参照して，共
有ライブラリを生成する方法がない場合，@samp{unsupported}を設定します．
@end defvar

@defvar always_export_symbols
@c Whether libtool should automatically generate a list of exported symbols
@c using @var{export_symbols_cmds} before linking an archive.
@c Set to @samp{yes} or @samp{no}.  Default is @samp{no}.
@c 
アーカイブとリンクする前に，@var{export_symbols_cmds}を使用してエクス
ポートされるシンボルのリストを，libtoolが自動的に生成するかどうかです．
@samp{yes}または@samp{no}に設定します．デフォルトは@samp{no}です．
@end defvar

@defvar archive_cmds
@defvarx archive_expsym_cmds
@defvarx old_archive_cmds
@c Commands used to create shared libraries, shared libraries with
@c @samp{-export-symbols} and static libraries, respectively.
@c 
それぞれ，共有ライブラリ，@samp{-export-symbols}を用いた共有ライブラリ，
そしてスタティックライブラリを生成するために使用するコマンドです．
@end defvar

@defvar old_archive_from_new_cmds
@c If the shared library depends on a static library,
@c @samp{old_archive_from_new_cmds} contains the commands used to create that
@c static library.  If this variable is not empty, @samp{old_archive_cmds} is
@c not used.
@c 
共有ライブラリがスタティックライブラリに依存する場合，
@samp{old_archive_from_new_cmds}はスタティックライブラリを生成するため
に使用するコマンドを含みます．この変数が空の場合，
@samp{old_archive_cmds}は使用されません．
@end defvar

@defvar old_archive_from_expsyms_cmds
@c If a static library must be created from the export symbol list in order to
@c correctly link with a shared library, @samp{old_archive_from_expsyms_cmds}
@c contains the commands needed to create that static library.  When these
@c commands are executed, the variable @var{soname} contains the name of the
@c shared library in question, and the @var{$objdir/$newlib} contains the
@c path of the static library these commands should build.  After executing
@c these commands, libtool will proceed to link against @var{$objdir/$newlib}
@c instead of @var{soname}.
@c 
スタティックライブラリが，共有ライブラリで正しくリンクするために，エク
スポートシンボルリストから作成される必要がある場合，
@samp{old_archive_from_expsyms_cmds}は，そのスタティックライブラリを作
成するために必要なコマンドを含みます．これらのコマンドが実行されるとき，
変数@var{soname}は，共有ライブラリの名前を疑問符の中に含み，
@var{$objdir/$newlib}は，これらのコマンドがビルドするスタティックライ
ブラリのパスを含みます．これらのコマンドを実行した後，libtoolは，
@var{soname}の代わりに@var{$objdir/$newlib}に対してリンクするための処
理を行います．
@end defvar

@defvar build_libtool_libs
@c Whether libtool should build shared libraries on this system.  Set to
@c @samp{yes} or @samp{no}.
@c 
このシステムで，libtoolが共有ライブラリをビルドできるかどうかです．
@samp{yes}または@samp{no}に設定します．
@end defvar

@defvar build_old_libs
@c Whether libtool should build static libraries on this system.  Set to
@c @samp{yes} or @samp{no}.
@c 
このシステムで，libtoolがスタティックライブラリをビルドできるかどうか
です．@samp{yes}または@samp{no}に設定します．
@end defvar

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

@defvar compiler_o_lo
@c Whether the compiler supports compiling directly to a ".lo" file,
@c i.e whether object files do not have to have the suffix ".o".
@c Set to @samp{yes} or @samp{no}.
@c 
コンパイラが，直接".lo"ファイルへのコンパイルをサポートするかどうかで，
例えば，オブジェクトファイルが，接尾子".o"を持つ必要があるかどうかです．
@samp{yes}または@samp{no}に設定します．
@end defvar

@defvar dlopen_support
@c Whether @code{dlopen} is supported on the platform.
@c Set to @samp{yes} or @samp{no}.
@c 
プラットフォームで，@code{dlopen}をサポートするかどうかです．
@samp{yes}または@samp{no}に設定します．
@end defvar

@defvar dlopen_self
@c Whether it is possible to @code{dlopen} the executable itself.
@c Set to @samp{yes} or @samp{no}.
@c 
実行形式自身が@code{dlopen}可能かどうかです．@samp{yes}または@samp{no} 
に設定します．
@end defvar

@defvar dlopen_self_static
@c Whether it is possible to @code{dlopen} the executable itself, when it
@c is linked statically (@samp{-all-static}).  Set to @samp{yes} or
@c @samp{no}.
@c 
スタティックにリンクされているとき(@samp{-all-static})，実行形式自身が
@code{dlopen}可能かどうかです．@samp{yes}または@samp{no}に設定します．
@end defvar

@defvar echo
@c An @code{echo} program which does not interpret backslashes as an
@c escape character.
@c 
バックスラッシュをエスケープ文字と解釈しない@code{echo}プログラムです．
@end defvar

@defvar exclude_expsyms
@c List of symbols that should not be listed in the preloaded symbols.
@c 
プリリードされているシンボルにリストアップされないシンボルのリストです．
@end defvar

@defvar export_dynamic_flag_spec
@c Compiler link flag that allows a dlopened shared library to reference
@c symbols that are defined in the program.
@c 
dlopenされる共有ライブラリが，プログラムで定義されているシンボルへの参
照を可能にするコンパイラリンクフラグです．
@end defvar

@defvar export_symbols_cmds
@c Commands to extract exported symbols from @var{libobjs} to the
@c file @var{export_symbols}.
@c 
@var{libobjs}からファイル@var{export_symbols}へエクスポートされたシン
ボルを抽出するコマンドです．
@end defvar

@defvar extract_expsyms_cmds
@c Commands to extract the exported symbols list from a shared library.
@c These commands are executed if there is no file @var{$objdir/$soname-def},
@c and should write the names of the exported symbols to that file, for
@c the use of @samp{old_archive_from_expsyms_cmds}.
@c 
共有ライブラリからエクスポートされたシンボルリストを抽出するコマンドで
す．これらのコマンドは，ファイル@var{$objdir/$soname-def}が無い場合に
実行され，@samp{old_archive_from_expsyms_cmds}が使用するため，エクスポー
トされたシンボル名をそのファイルに書き出します．
@end defvar

@defvar fast_install
@c Determines whether libtool will privilege the installer or the
@c developer.  The assumption is that installers will seldom run programs
@c in the build tree, and the developer will seldom install.  This is only
@c meaningful on platforms in which @var{shlibpath_overrides_runpath} is
@c not @samp{yes}, so @var{fast_install} will be set to @samp{needless} in
@c this case.  If @var{fast_install} set to @samp{yes}, libtool will create
@c programs that search for installed libraries, and, if a program is run
@c in the build tree, a new copy will be linked on-demand to use the
@c yet-to-be-installed libraries.  If set to @samp{no}, libtool will create
@c programs that use the yet-to-be-installed libraries, and will link
@c a new copy of the program at install time.  The default value is
@c @samp{yes} or @samp{needless}, depending on platform and configuration
@c flags, and it can be turned from @samp{yes} to @samp{no} with the
@c configure flag @samp{--disable-fast-install}.
@c 
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
@c Commands to tell the dynamic linker how to find shared libraries in a
@c specific directory.
@c 
指定されたディレクトリで共有ライブラリを見つける方法を，ダイナミックリ
ンカに伝えるコマンドです．
@end defvar

@defvar finish_eval
@c Same as @var{finish_cmds}, except the commands are not displayed.
@c 
コマンドが表示されない以外，@var{finish_cmds}と同じです．
@end defvar

@defvar fix_srcfile_path
@c Expression to fix the shell variable $srcfile for the compiler.
@c 
コンパイラに対するシェル変数@var{$srcfile}を修正する式です．
@end defvar

@defvar global_symbol_pipe
@c A pipeline that takes the output of @var{NM}, and produces a listing of
@c raw symbols followed by their C names.  For example:
@c 
@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

@c The first column contains the symbol type (used to tell data from code
@c on some platforms), but its meaning is system dependent.
@c 
最初の列は，(いくつかのプラットフォーム上でコードからデータを伝えるた
めに使用される)シンボル形式を含みますが，その意味はシステムに依存しま
す．
@end defvar

@defvar global_symbol_to_cdecl
@c A pipeline that translates the output of @var{global_symbol_pipe} into
@c proper C declarations.  On platforms whose linkers differentiate code
@c from data, such as HP/UX, data symbols will be declared as such, and
@c code symbols will be declared as functions.  On platforms that don't
@c care, everything is assumed to be data.
@c 
@var{global_symbol_pipe}の出力を厳密なC宣言に変換するパイプラインです．
HP/UXのような，リンカがコードとデータを区別するプラットフォームでは，
データシンボルはそのように宣言され，コードシンボルは関数として宣言され
ます．気にしないプラットフォームではすべてがデータと仮定されます．
@end defvar

@defvar hardcode_action
@c Either @samp{immediate} or @samp{relink}, depending on whether shared
@c library paths can be hardcoded into executables before they are installed,
@c or if they need to be relinked.
@c 
@samp{immediate}または@samp{relink}のいずれかで，共有ライブラリパスが
インストールされる前に実行形式にハードコードされるか，または，再リンク
する必要があるかに依存します．
@end defvar

@defvar hardcode_direct
@c Set to @samp{yes} or @samp{no}, depending on whether the linker
@c hardcodes directories if a library is directly specified on the command
@c line (such as @samp{@var{dir}/lib@var{name}.a}) when
@c @var{hardcode_libdir_flag_spec} is specified.
@c 
@var{hardcode_libdir_flag_spec}が指定されたとき，
(@samp{@var{dir}/lib@var{name}.a}のような)コマンド行でライブラリが直接
していされる場合，リンカがディレクトリをハードコードするかどうかに依存
し，@samp{yes}または@samp{no}に設定します．
@end defvar

@defvar hardcode_into_libs
@c Whether the platform supports hardcoding of run-paths into libraries.
@c If enabled, linking of programs will be much simpler but libraries will
@c need to be relinked during installation.   Set to @samp{yes} or @samp{no}.
@c 
ライブラリ内の実行パスのハードコードをプラットフォームがサポートするか
どうかです．可能な場合，プログラムのリンクはより単純になりますが，ライ
ブラリはインストール時に再リンクが必要です．@samp{yes}または@samp{no}
に設定します．
@end defvar

@defvar hardcode_libdir_flag_spec
@c Flag to hardcode a @var{libdir} variable into a binary, so that the
@c dynamic linker searches @var{libdir} for shared libraries at runtime.
@c If it is empty, libtool will try to use some other hardcoding mechanism.
@c 
実行時に，共有ライブラリに対しダイナミックリンカが@var{libdir}を検索す
るために，バイナリに@var{libdir}変数をハードコードするためのフラグです．
空の場合，libtoolは他のハードコーディングメカニズムの使用を試みます．
@end defvar

@defvar hardcode_libdir_separator
@c If the compiler only accepts a single @var{hardcode_libdir_flag}, then
@c this variable contains the string that should separate multiple
@c arguments to that flag.
@c 
コンパイラが単一の@var{hardcode_libdir_flag}のみ受け入れる場合，この変
数はそのフラグに対する複数の引数を分ける文字列を含みます．
@end defvar

@defvar hardcode_minus_L
@c Set to @samp{yes} or @samp{no}, depending on whether the linker
@c hardcodes directories specified by @samp{-L} flags into the resulting
@c executable when @var{hardcode_libdir_flag_spec} is specified.
@c 
@var{hardcode_libdir_flag_spec}が指定されたとき，結果として生じる実行
形式に@samp{-L}フラグで指定されるディレクトリを，リンカがハードコード
するかどうかに依存し，@samp{yes}または@samp{no}に設定します．
@end defvar

@defvar hardcode_shlibpath_var
@c Set to @samp{yes} or @samp{no}, depending on whether the linker
@c hardcodes directories by writing the contents of @samp{$shlibpath_var}
@c into the resulting executable when @var{hardcode_libdir_flag_spec} is
@c specified.  Set to @samp{unsupported} if directories specified by
@c @samp{$shlibpath_var} are searched at run time, but not at link time.
@c 
@var{hardcode_libdir_flag_spec}が指定されたとき，結果として生じる実行
形式に@samp{$shlibpath_var}の内容を書き込むことで，リンカがディレクト
リをハードコードするかどうかに依存し，@samp{yes}または@samp{no}に設定
します．@samp{$shlibpath_var}で指定されたディレクトリが，リンク時では
なく実行時に検索される場合，@samp{unsupported}に設定します．
@end defvar

@defvar host
@defvarx host_alias
@c For information purposes, set to the specified and canonical names of
@c the system that libtool was configured for.
@c 
情報を目的として，libtoolがコンフィグレーションされたシステムの指定さ
れた標準名に設定します．
@end defvar

@defvar include_expsyms
@c List of symbols that must always be exported when using @var{export_symbols}.
@c 
@var{export_symbols}の使用時に，常にエクスポートされる必要があるシンボ
ルのリストです．
@end defvar

@defvar libext
@c The standard old archive suffix (normally "a").
@c 
標準的な，古いアーカイブの接尾子(通常は"a")です．
@end defvar

@defvar libname_spec
@c The format of a library name prefix.  On all Unix systems, static
@c libraries are called @samp{lib@var{name}.a}, but on some systems (such
@c as OS/2 or MS-DOS), the library is just called @samp{@var{name}.a}.
@c 
ライブラリ名の接頭辞の書式です．Unixシステムでは，スタティックライブラ
リは@samp{lib@var{name}.a}と命名されますが，(OS/2やMS-DOSのような)シス
テムでは，ライブラリは@samp{@var{name}.a}のみで命名されることもありま
す．
@end defvar

@defvar library_names_spec
@c A list of shared library names.  The first is the name of the file,
@c the rest are symbolic links to the file.  The name in the list is
@c the file name that the linker finds when given @samp{-l@var{name}}.
@c 
共有ライブラリ名のリストです．最初はファイル名で，残りはファイルへのシ
ンボリックリンクです．リスト内の名前は，@samp{-l@var{name}}で与えられ
たときリンカが見つけるファイル名です．
@end defvar

@defvar link_all_deplibs
@c Whether libtool must link a program against all its dependency libraries.
@c Set to @samp{yes} or @samp{no}.  Default is @samp{unknown}, which is
@c a synonym for @samp{yes}.
@c 
libtoolが，全ての依存するプログラムに対しプログラムをリンクする必要が
あるかどうかです．@samp{yes}または@samp{no}に設定します．デフォルトは
@samp{unknown}で，それは@samp{yes}と同じです．
@end defvar

@defvar link_static_flag
@c Linker flag (passed through the C compiler) used to prevent dynamic
@c linking.
@c 
ダイナミックリンクを避けるために使用する(Cコンパイラに渡す)リンカフラ
グです．
@end defvar

@defvar need_lib_prefix
@c Whether libtool should automatically prefix module names with 'lib'.
@c Set to @samp{yes} or @samp{no}.  By default, it is @samp{unknown}, which
@c means the same as @samp{yes}, but documents that we are not really sure
@c about it.
@c @samp{yes} means that it is possible both to @code{dlopen} and to
@c link against a library without 'lib' prefix,
@c i.e. it requires @var{hardcode_direct} to be @samp{yes}.
@c 
自動的にモジュール名に'lib'接頭辞を付けるかどうかです．@samp{yes}また
は@samp{no}に設定します．デフォルトで，それは@samp{unknown}になり，そ
れは@samp{yes}と同じ意味ですが，本当に確かめたわけではないことを告げて
います．@samp{yes}は@code{dlopen}と'lib'接頭辞がないライブラリにリンク
可能なことを意味し，すなわち，それは@var{hardcode_direct}を@samp{yes} 
にすることを要求します．
@end defvar

@defvar need_version
@c Whether versioning is required for libraries, i.e. whether the
@c dynamic linker requires a version suffix for all libraries.
@c Set to @samp{yes} or @samp{no}.  By default, it is @samp{unknown}, which
@c means the same as @samp{yes}, but documents that we are not really sure
@c about it.
@c 
バージョン管理がライブラリに必要とされるかどうかで，すなわち，ダイナミッ
クリンカが，すべてのライブラリに対しバージョンの接尾子を必要とするかど
うかです．@samp{yes}または@samp{no}に設定します．デフォルトで，それは
@samp{unknown}で，それは@samp{yes}と同じ意味を持ちますが，それを実際に
は確かめていないことを告げています．
@end defvar

@defvar need_locks
@c Whether files must be locked to prevent conflicts when compiling
@c simultaneously. Set to @samp{yes} or @samp{no}.
@c 
同時にコンパイルするとき，衝突を避けるためにファイルをロックする必要が
あるかどうかです．@samp{yes}または@samp{no}に設定します．
@end defvar

@defvar no_builtin_flag
@c Compiler flag to disable builtin functions that conflict with declaring
@c external global symbols as @code{char}.
@c 
@code{char}として外部グローバルシンボルを宣言することと衝突する組み込
み関数を，利用不可能にするコンパイラフラグです．
@end defvar

@defvar no_undefined_flag
@c The flag that is used by @samp{archive_cmds} in order to declare that
@c there will be no unresolved symbols in the resulting shared library.
@c Empty, if no such flag is required.
@c 
結果として生じる共有ライブラリに，未解決のシンボルがないことを宣言する
ための，@samp{archive_cmds}で使用されるフラグです．
@end defvar

@defvar objdir
@c The name of the directory that contains temporary libtool files.
@c 
一時的なlibtoolファイルが含まれるディレクトリ名です．
@end defvar

@defvar objext
@c The standard object file suffix (normally "o").
@c 
標準的なオブジェクトファイルの接尾子(通常は"o")です．
@end defvar

@defvar pic_flag
@c Any additional compiler flags for building library object files.
@c 
ライブラリオブジェクトファイルをビルドするための，あらゆる追加のコンパ
イルフラグです．
@end defvar

@defvar postinstall_cmds
@defvarx old_postinstall_cmds
@c Commands run after installing a shared or static library, respectively.
@c 
それぞれ，共有またはスタティックライブラリをインストールした後に実行す
るコマンドです．
@end defvar

@defvar postuninstall_cmds
@defvarx old_postuninstall_cmds
@c Commands run after uninstalling a shared or static library, respectively.
@c 
それぞれ，共有またはスタティックライブラリをアンインストールした後に実
行するコマンドです．
@end defvar

@defvar reload_cmds
@defvarx reload_flag
@c Commands to create a reloadable object.
@c 
リロード可能なオブジェクトを作成するコマンドです．
@end defvar

@defvar runpath_var
@c The environment variable that tells the linker which directories to
@c hardcode in the resulting executable.
@c 
結果として生じる実行形式内にハードコードするディレクトリをリンカに伝え
る環境変数です．
@end defvar

@defvar shlibpath_overrides_runpath
@c Indicates whether it is possible to override the hard-coded library
@c search path of a program with an environment variable.  If this is set
@c to no, libtool may have to create two copies of a program in the build
@c tree, one to be installed and one to be run in the build tree only.
@c When each of these copies is created depends on the value of
@c @code{fast_install}.  The default value is @samp{unknown}, which is
@c equivalent to @samp{no}.
@c 
環境変数でプログラムのハードコードされたライブラリ検索パスを優先可能か
どうかを示します．これが@samp{no}に設定されている場合，libtoolはビルド
ツリーにプログラムのコピーを二つ作成する必要がある可能性があり，一つは
インストールされ，もう一つはビルドツリーのみで実行されます．これらのコ
ピーのどちらかが作成されるとき，@code{fast_install}の値に依存します．
デフォルト値は@samp{unknown}で，それは@samp{no}と同じです．
@end defvar

@defvar shlibpath_var
@c The environment variable that tells the dynamic linker where to find
@c shared libraries.
@c 
ダイナミックリンカに共有ライブラリを探す場所を伝える環境変数です．
@end defvar

@defvar soname_spec
@c The name coded into shared libraries, if different from the real name of
@c the file.
@c 
共有ライブラリがファイルの本当の名前と異なる場合，その中に符号化された
コードされた名前です．
@end defvar

@defvar striplib
@defvarx old_striplib
@c Command to strip a shared (@code{striplib}) or static (@code{old_striplib})
@c library, respectively.  If these variables are empty, the strip flag
@c in the install mode will be ignored for libraries (@pxref{Install mode}).
@c 
共有(@code{striplib})やスタティック(@code{old_striplib})のライブラリを
stripするコマンドです．これらの変数が空の場合，インストールモードの
stripフラグは，ライブラリに対し無視されます(@pxref{Install mode})．
@end defvar

@defvar sys_lib_dlsearch_path_spec
@c Expression to get the run-time system library search path.  Directories
@c that appear in this list are never hard-coded into executables.
@c 
実行時にライブラリの検索パスを取得する式です．このリストに現れるディレ
クトリが実行形式にハードコードされることは決してありません．
@end defvar

@defvar sys_lib_search_path_spec
@c Expression to get the compile-time system library search path.  This
@c variable is used by libtool when it has to test whether a certain
@c library is shared or static.  The directories listed in
@c @var{shlibpath_var} are automatically appended to this list, every time
@c libtool runs (i.e., not at configuration time), because some linkers use
@c this variable to extend the library search path.  Linker switches such
@c as @code{-L} also augment the search path.
@c 
コンパイル時にライブラリの検索パスを取得する式です．この変数は，特定の
ライブラリが共有かスタティックかをテストする必要があるとき，libtoolが
使用します．@var{shlibpath_var}でリストアップされるディレクトリは，こ
のリストに自動的に現れ，ライブラリ検索パスを拡張するためにこの変数を使
用するリンカもあるので，毎回(すなわち，コンフィグレーション時以外)
libtoolは実行します．リンカは@code{-L}のような検索パス引数も切り替えま
す．
@end defvar

@defvar thread_safe_flag_spec
@c Linker flag (passed through the C compiler) used to generate thread-safe
@c libraries.
@c 
スレッドセーフなライブラリを生成するために使用する(Cコンパイラに渡す)
リンカフラグです．
@end defvar

@defvar version_type
@c The library version numbering type.  One of @samp{libtool},
@c @samp{freebsd-aout}, @samp{freebsd-elf}, @samp{irix}, @samp{linux},
@c @samp{osf}, @samp{sunos}, @samp{windows}, or @samp{none}.
@c 
ライブラリバージョンナンバーの形式です．@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
@c Compiler flag to generate shared objects from convenience archives.
@c 
コンビニエンスアーカイバから共有ライブラリを生成するコンパイラフラグで
す．
@end defvar

@defvar wl
@c The C compiler flag that allows libtool to pass a flag directly to the
@c linker.  Used as: @code{$@{wl@}@var{some-flag}}.
@c 
libtoolが直接リンカにフラグを渡すことを可能とするCコンパイラフラグです．
@code{$@{wl@}@var{some-flag}}として使用されます．
@end defvar

@c Variables ending in @samp{_cmds} or @samp{_eval} contain a
@c @samp{~}-separated list of commands that are @code{eval}ed one after
@c another.  If any of the commands return a nonzero exit status, libtool
@c generally exits with an error message.
@c 
@samp{_cmds}や@samp{_eval}で終わる変数は，@samp{~}で分けられた，順番に
@code{eval}されるコマンドのリストを含みます．ゼロ以外の終了ステータス
を返すコマンドがある場合，libtoolは一般的にエラーメッセージとともに終
了します．

@c Variables ending in @samp{_spec} are @code{eval}ed before being used by
@c libtool.
@c 
@samp{_spec}で終わる変数は，libtoolで使用される前に@code{eval}されます．

@node Cheap tricks
@c @section Cheap tricks
@section 安っぽい手段

@c Here are a few tricks that you can use in order to make maintainership
@c easier:
@c 
より簡単にメンテナーシップを作成するために使用することが可能な手段は以
下のようになっています．

@itemize @bullet
@item
@c When people report bugs, ask them to use the @samp{--config},
@c @samp{--debug}, or @samp{--features} flags, if you think they will help
@c you.  These flags are there to help you get information directly, rather
@c than having to trust second-hand observation.
@c 
人々がバグを報告したとき，彼らを助けたいと思う場合は，@samp{--config}，
@samp{--debug}，または@samp{--features}フラグを使用したかどうかを尋ね
てください．これらのフラグは，中古の調査を信頼しなければならない代わり
に，情報を直接得る手助けとなるものです．

@item
@c Rather than reconfiguring libtool every time I make a change to
@c @code{ltmain.in}, I keep a permanent @code{libtool} script in my
@c @var{PATH}, which sources @code{ltmain.in} directly.
@c 
@code{ltmain.in}を変更するたびごとに再コンフィグレーションする代わりに，
@var{PATH}に永久的な@code{libtool}スクリプトを保持し，それは直接
@code{ltmain.in}の元となるものです．

@c The following steps describe how to create such a script, where
@c @code{/home/src/libtool} is the directory containing the libtool source
@c tree, @code{/home/src/libtool/libtool} is a libtool script that has been
@c configured for your platform, and @code{~/bin} is a directory in your
@c @var{PATH}:
@c 
以下のステップは，そのようなスクリプトを作成する方法を記述し，そこでは
@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

@c The output of the final @samp{libtool --version} command shows that the
@c @code{ltmain.in} script is being used directly.  Now, modify
@c @code{~/bin/libtool} or @code{/home/src/libtool/ltmain.in} directly in
@c order to test new changes without having to rerun @code{configure}.
@c 
@samp{libtool --version}コマンドの最終的な出力は，@code{ltmain.in}スク
リプトが直接使用されていることを示します．@code{configure}を再実行する
必要なく新しい変更をテストするため，すぐに，@code{~/bin/libtool}や
@code{/home/src/libtool/ltmain.in}を編集してください．

@include fdl.texi

@page
@node Index
@c @unnumbered Index
@unnumbered 索引

@printindex cp

@c summarycontents
@contents
@bye
