File:  [Local Repository] / gnujdoc / libtool-1.4.2 / libtool-ja.texi
Revision 1.2: download - view: text, annotated - select for diffs
Sat Jun 11 07:02:50 2005 UTC (15 years, 4 months ago) by futoshi
Branches: MAIN
CVS tags: HEAD
Format html with makeinfo.
Some "@ininfo"s (for @menu and @top) replace to "@ifnottex"s.

    1: \input texinfo   @c -*-texinfo-*-
    2: @c %**start of header
    3: @setfilename libtool-ja.info
    4: @settitle Libtool
    5: @c For double-sided printing, uncomment:
    6: @c @setchapternewpage odd
    7: @c %**end of header
    8: 
    9: @c @documentlanguage ja
   10: 
   11: @include libtool-v.texi
   12: @set BUGADDR the libtool bug reporting address @email{bug-libtool@@gnu.org}
   13: @set MAILLIST the libtool mailing list @email{libtool@@gnu.org}
   14: @set objdir .libs
   15: 
   16: @dircategory GNU programming tools
   17: @direntry
   18: * Libtool(ja): (libtool-ja).           Generic shared library support script.
   19: @end direntry
   20: 
   21: @dircategory Individual utilities
   22: @direntry
   23: * libtoolize(ja): (libtool-ja)Invoking libtoolize.     Adding libtool support.
   24: @end direntry
   25: 
   26: @ifinfo
   27: This file documents GNU Libtool @value{VERSION}
   28: 
   29: このファイルは,GNU Libtool @value{VERSION}を説明します.
   30: 
   31: Copyright (C) 1996-2000 Free Software Foundation, Inc.
   32: 
   33: Permission is granted to copy, distribute and/or modify this document
   34: under the terms of the GNU Free Documentation License, Version 1.1
   35: or any later version published by the Free Software Foundation;
   36: with the no Invariant Sections, with no Front-Cover Texts,
   37: and with no Back-Cover Texts.  A copy of the license is included in
   38: the section entitled "GNU Free Documentation License".
   39: 
   40: @ignore
   41: Permission is granted to process this file through TeX and print the
   42: results, provided the printed document carries copying permission notice
   43: identical to this one except for the removal of this paragraph
   44: 
   45: @end ignore
   46: @end ifinfo
   47: 
   48: @titlepage
   49: @title GNU Libtool
   50: @subtitle For version @value{VERSION}, @value{UPDATED}
   51: @author Gordon Matzigkeit
   52: @author Alexandre Oliva
   53: @author Thomas Tanner
   54: @author Gary V. Vaughan
   55: @c 翻訳:西尾 太
   56: 
   57: @page
   58: @vskip 0pt plus 1filll
   59: Copyright @copyright{} 1996-2000 Free Software Foundation, Inc.
   60: 
   61: Permission is granted to copy, distribute and/or modify this document
   62: under the terms of the GNU Free Documentation License, Version 1.1
   63: or any later version published by the Free Software Foundation;
   64: with the no Invariant Sections, with no Front-Cover Texts,
   65: and with no Back-Cover Texts.  A copy of the license is included in
   66: the section entitled "GNU Free Documentation License".
   67: 
   68: @end titlepage
   69: 
   70: @c Put everything in one index (arbitrarily chosen to be the concept index).
   71: @syncodeindex vr cp
   72: @syncodeindex fn cp
   73: @syncodeindex tp cp
   74: @synindex pg cp
   75: 
   76: @ifnottex
   77: @node Top, Introduction, (dir), (dir)
   78: @comment  node-name,  next,  previous,  up
   79: @top Shared library support for GNU
   80: 
   81: このファイルはGNU Libtoolの説明で,それは,パッケージ開発者が一般的な共
   82: 有ライブラリを提供することを可能にするスクリプトです.このエディションは
   83: バージョン@value{VERSION}を説明します.
   84: 
   85: libtoolを用いたときの問題の報告方法の情報は,@xref{Reporting bugs}.
   86: 
   87: @menu
   88: * Introduction::                What the heck is libtool?
   89: * Libtool paradigm::            How libtool's view of libraries is different.
   90: * Using libtool::               Example of using libtool to build libraries.
   91: * Invoking libtool::            Running the @code{libtool} script.
   92: * Integrating libtool::         Using libtool in your own packages.
   93: * Versioning::                  Using library interface versions.
   94: * Library tips::                Tips for library interface design.
   95: * Inter-library dependencies::  Libraries that depend on other libraries.
   96: * Dlopened modules::            @code{dlopen}ing libtool-created libraries.
   97: * Using libltdl::               Libtool's portable @code{dlopen} wrapper library.
   98: * Other languages::             Using libtool without a C compiler.
   99: * Troubleshooting::             When libtool doesn't work as advertised.
  100: * Maintaining::                 Information used by the libtool maintainer.
  101: * GNU Free Documentation License:: License for this manual.
  102: * Index::                       Full index.
  103: 
  104: @detailmenu
  105:  ---詳細なノードリスト---
  106: 
  107: はじめに
  108: 
  109: * Motivation::                  Why does GNU need a libtool?
  110: * Issues::                      The problems that need to be addressed.
  111: * Other implementations::       How other people have solved these issues.
  112: * Postmortem::                  Learning from past difficulties.
  113: 
  114: libtoolを使用する
  115: 
  116: * Creating object files::       Compiling object files for libraries.
  117: * Linking libraries::           Creating libraries from object files.
  118: * Linking executables::         Linking object files against libtool libraries.
  119: * Debugging executables::       Running GDB on libtool-generated programs.
  120: * Installing libraries::        Making libraries available to users.
  121: * Installing executables::      Making programs available to users.
  122: * Static libraries::            When shared libraries are not wanted.
  123: 
  124: @code{libtool}の呼び出し
  125: 
  126: * Compile mode::                Creating library object files.
  127: * Link mode::                   Generating executables and libraries.
  128: * Execute mode::                Debugging libtool-generated programs.
  129: * Install mode::                Making libraries and executables public.
  130: * Finish mode::                 Completing a library installation.
  131: * Uninstall mode::              Removing installed executables and libraries.
  132: * Clean mode::                  Removing uninstalled executables and libraries.
  133: 
  134: パッケージとlibtoolの統合
  135: 
  136: * Makefile rules::              Writing @file{Makefile} rules for libtool.
  137: * Using Automake::              Automatically supporting libtool.
  138: * Configuring::                 Configuring libtool for a host system.
  139: * Distributing::                What files to distribute with your package.
  140: * Static-only libraries::       Sometimes shared libraries are just a pain.
  141: 
  142: libtoolのコンフィグレーション
  143: 
  144: * AC_PROG_LIBTOOL::             Configuring @code{libtool} in @file{configure.in}.
  145: 
  146: パッケージにlibtoolを含める
  147: 
  148: * Invoking libtoolize::         @code{libtoolize} command line options.
  149: * Autoconf .o macros::          Autoconf macros that set object file names.
  150: 
  151: ライブラリインターフェースのバージョン
  152: 
  153: * Interfaces::                  What are library interfaces?
  154: * Libtool versioning::          Libtool's versioning system.
  155: * Updating version info::       Changing version information before releases.
  156: * Release numbers::             Breaking binary compatibility for aesthetics.
  157: 
  158: インターフェースデザインへの助言
  159: 
  160: * C header files::              How to write portable include files.
  161: 
  162: dlopenモジュール
  163: 
  164: * Building modules::            Creating dlopenable objects and libraries.
  165: * Dlpreopening::                Dlopening that works on static platforms.
  166: * Finding the dlname::          Choosing the right file to @code{dlopen}.
  167: * Dlopen issues::               Unresolved problems that need your attention.
  168: 
  169: libltdlを使用する
  170: 
  171: * Libltdl interface::           How to use libltdl in your programs.
  172: * Modules for libltdl::         Creating modules that can be @code{dlopen}ed.
  173: * Thread Saftey in libltdl::	Registering callbacks for multi-thread safety.
  174: * User defined module data::    Associating data with loaded modules.
  175: * Module loaders for libltdl::  Creating user defined module loaders.
  176: * Distributing libltdl::        How to distribute libltdl with your package.
  177: 
  178: 他の言語でlibtoolを使用する
  179: 
  180: * C++ libraries::
  181: 
  182: トラブルシューティング
  183: 
  184: * Libtool test suite::          Libtool's self-tests.
  185: * Reporting bugs::              How to report problems with libtool.
  186: 
  187: libtoolのテストスイート
  188: 
  189: * Test descriptions::           The contents of the test suite.
  190: * When tests fail::             What to do when a test fails.
  191: 
  192: libtoolのための管理メモ
  193: 
  194: * New ports::                   How to port libtool to new systems.
  195: * Tested platforms::            When libtool was last tested.
  196: * Platform quirks::             Information about different library systems.
  197: * libtool script contents::     Configuration information that libtool uses.
  198: * Cheap tricks::                Making libtool maintainership easier.
  199: 
  200: 新しいシステムへlibtoolを移植する
  201: 
  202: * Information sources::         Where to find relevant documentation
  203: * Porting inter-library dependencies::  Implementation details explained
  204: 
  205: プラットフォームの癖
  206: 
  207: * References::                  Finding more information.
  208: * Compilers::                   Creating object files from source files.
  209: * Reloadable objects::          Binding object files together.
  210: * Multiple dependencies::	Removing duplicate dependant libraries.
  211: * Archivers::                   Programs that create static archives.
  212: 
  213: @end detailmenu
  214: @end menu
  215: 
  216: @end ifnottex
  217: 
  218: @node Introduction
  219: @chapter はじめに
  220: 
  221: これまで,ソースコードパッケージの開発者が共有ライブラリの能力を利用した
  222: い場合,パッケージを実行するそれぞれのプラットフォームに対し,カスタムサ
  223: ポートコードを書く必要がありました.パッケージインストーラがビルドされる
  224: ライブラリの種類を選択できるように,コンフィグレーションインターフェース
  225: を設計する必要もありました.
  226: 
  227: GNU Libtoolは,一つのスクリプトでプラットフォーム特有の依存性とユーザイ
  228: ンターフェースの両方をカプセル化することで,開発者の仕事を単純にします.
  229: GNU Libtoolは,それぞれのホストの形式の完全な機能を,一般的なインタフェー
  230: スを通して利用できるが,やっかいな癖はプログラマから隠されるように設計さ
  231: れています.
  232: 
  233: GNU Libtoolの一貫したインターフェースは再保証されます@dots{} ユーザは好
  234: みのソースコードパッケージを共有ライブラリにビルドするため,不明瞭なドキュ
  235: メントを読む必要がありません.パッケージの@code{configure}スクリプト(ま
  236: たはその同等品)を実行するだけで,libtoolがいやな仕事をすべて行ってくれま
  237: す.
  238: 
  239: このドキュメント全体にいくつかの例があります.すべて同じ環境を仮定してい
  240: ます.我々は,ライブラリ@file{libhello}を一般的な方法でビルドしたいと思っ
  241: ています.
  242: 
  243: @file{libhello}は,共有ライブラリ,スタティックライブラリ,または,その
  244: 両方になります@dots{} libtoolで移植できるホストシステムで利用可能なすべ
  245: てのものです.
  246: 
  247: この章では,libtoolの最初の設計思想を説明します.歴史に興味がなかったり,
  248: 堅実な方法で拡張されているlibtoolのコードを書きたい場合,自由に飛ばして
  249: 次の章へ行ってください.
  250: 
  251: @menu
  252: * Motivation::                  Why does GNU need a libtool?
  253: * Issues::                      The problems that need to be addressed.
  254: * Other implementations::       How other people have solved these issues.
  255: * Postmortem::                  Learning from past difficulties.
  256: @end menu
  257: 
  258: @node Motivation
  259: @section libtoolを書いた動機
  260: 
  261: @cindex motivation for writing libtool
  262: @cindex design philosophy
  263: 1995年初頭から,数人のGNU開発者はそれぞれ,パッケージに対する共有ライブ
  264: ラリのサポートの重要性を認識していました.そのように変更する主な動機は,
  265: GNUプログラムでのコードのモジュール化と再利用を(概念的,物理的の両方で) 
  266: 促進するためです.
  267: 
  268: そのような要求は,パッケージのインストーラが要求するあらゆるライブラリの
  269: 形式が可能になるように,GNUパッケージにライブラリを組み込む方法を一般的
  270: なものにする必要があることを意味します.問題は,異なるプラットフォームで
  271: 共有ライブラリを作成する標準手続きが無いことです.
  272: 
  273: 以下のセクションで,GNUでの共有ライブラリのサポートが直面している重大な
  274: 問題と,共有ライブラリのサポートをlibtoolで標準化した方法を概説します.
  275: 
  276: @cindex specifications for libtool
  277: @cindex libtool specifications
  278: 以下の仕様書が,このシステムの開発と評価で使用されました.
  279: 
  280: @enumerate
  281: @item
  282: システムはできる限り簡潔である必要があります.
  283: 
  284: @item
  285: システムは,GNU管理者がより簡単に使用できるように,GNU Autoconfと
  286: Automakeユーティリティと完全に統合する必要があります.しかし,GNUパッケー
  287: ジ以外でも使用できるように,これらのツールを要求してはなりません.
  288: 
  289: @item
  290: 他の(GNUでない)アーキテクチャとツールへの移植が望まれます.
  291: @end enumerate
  292: 
  293: 
  294: @node Issues
  295: @section 問題の実装
  296: 
  297: @cindex tricky design issues
  298: @cindex design issues
  299: 以下の問題は,再利用可能なあらゆる共有ライブラリシステム,特にlibtoolで
  300: 扱う必要があります.
  301: 
  302: @enumerate
  303: @item
  304: パッケージのインストーラで,ビルドされるライブラリの種類を制御可能にすべ
  305: きです.
  306: 
  307: @item
  308: インストールされていないライブラリと動的にリンクされるプログラムの実行を
  309: 巧妙に行うことを可能にします.@code{LD_LIBRARY_PATH}が(サポートしている
  310: 場合は)正しく設定されている必要があり,そうでなければプログラムの実行に
  311: 失敗するでしょう.
  312: 
  313: @item
  314: システムは,共有ライブラリをサポートしていないホストでさえ,堅実に処理す
  315: る必要があります.
  316: 
  317: @item
  318: 共有ライブラリをビルドするときに必要なコマンドは,ホスト毎に大きく異なる
  319: 可能性があります.これらは,コンフィグレーション時に一定の方法で決定する
  320: 必要があります.
  321: 
  322: @item
  323: インストールされる共有ライブラリの接尾子が常に明確なわけではありません.
  324: 通常,ファイル名はホスト毎に同じだということを仮定されるので,
  325: @file{Makefile}規則が難しくなります.
  326: 
  327: @item
  328: 共有ライブラリをその場でアップグレード可能なように,システムは,単純なラ
  329: イブラリバージョンナンバーの抽象化が必要です.バイナリ互換を最大にするた
  330: め,ライブラリへのインターフェースの設計方法を,プログラマに伝えるべきで
  331: す.
  332: 
  333: @item
  334: インストールする@file{Makefile}ターゲットは,パッケージインストーラに
  335: 特定の環境変数(@code{LD_LIBRARY_PATH}または同等のもの)を設定したり,
  336: @code{ldconfig}を実行するよう,警告する必要があります.
  337: @end enumerate
  338: 
  339: @node Other implementations
  340: @section その他の実装
  341: 
  342: libtoolが開発されるまで,多くのフリーソフトウエアパッケージは,独自の共
  343: 有ライブラリをビルドしインストールしていました.既存の機能の再発明を避け
  344: るために,これらのパッケージを最初に調査しました.
  345: 
  346: さて,これらのパッケージに,libtoolが必要としている共有ライブラリシステ
  347: ムの詳細な文章が無いのは明らかです.そのため,それ以外のパッケージは影響
  348: するので多少断念されました.
  349: 
  350: 
  351: @node Postmortem
  352: @section その他の実装の近代的な解析
  353: 
  354: @cindex other implementations, flaws in
  355: @cindex reusability of library systems
  356: 調査されたそれぞれの実装は,多くの異なるホストシステムに対して,予定して
  357: いた仕事をすべて公平に行いました.しかし,再利用できるコンポーネントとし
  358: て一般的に機能するものは,これらの解決法にはないようでした.
  359: 
  360: @cindex complexity of library systems
  361: ほとんどのものは,実装で行なわれていることを正確に理解すること無く使用す
  362: る(まして,変更する)には複雑すぎ,それらは通常,文章化されていませんでし
  363: た.
  364: 
  365: 異なるベンダーはライブラリについて異なる見解を持つこと,そして,当然
  366: @emph{動作する}という単一のパラダイムを自信を持って定めているものが調査
  367: したパッケージには無かったことが主な難点です.
  368: 
  369: 理想としては,拡張シリーズとして,そして既存のシステムが絶えず動作するよ
  370: うは変更物として実装されている標準物に,libtoolがなることです.しかし,
  371: オペレーティングシステム開発者に悪い方法を修正させることは簡単な仕事では
  372: なく,バグが多く,壊れていて,混乱したオペレーティングシステム上でさえ,
  373: 今すぐに共有ライブラリをビルドしたいと,人々は思っていました.
  374: 
  375: このため,libtoolは独立したシェルスクリプトとして設計されました.それは,
  376: 異なるプラットフォーム上のコンパイラスイートを,堅実で強力なインターフェー
  377: スを用いて包み隠すことで,@file{Makefile}の書き手を悩ませるライブラリ構
  378: 築での問題と矛盾から隔離しています.
  379: 
  380: 運が良ければ,libtoolは役に立ち,GNUコミュニティで使用され,そして,それ
  381: を書くとき学んだ教訓は,将来のライブラリシステムの設計に採用されるでしょ
  382: う.
  383: 
  384: 
  385: @node Libtool paradigm
  386: @chapter libtoolのパラダイム
  387: 
  388: 最初は,ライブラリのオブジェクト形式の不特定多数をサポートするように
  389: libtoolは設計されました.その後,libtoolはより多くのプラットフォームに移
  390: 植され,ライブラリとプログラムの間の関係を記述するため,新しいパラダイム
  391: が徐々に開発されました.
  392: 
  393: @cindex definition of libraries
  394: @cindex libraries, definition of
  395: 要約すると,``ライブラリは複数のエントリポイントと,より正式に定義された
  396: インターフェースがあるプログラムである.''ということです.
  397: 
  398: libtoolのバージョン0.7は,この新しいパラダイムを反映するため,完全に再設
  399: 計され書き換えられました.今のところ成功しているようです.libtoolは,以
  400: 前よりより単純になり,より役に立ちます.
  401: 
  402: libtoolパラダイムを導入する最善の方法は,それぞれの例を用いて,既存のラ
  403: イブラリシステムのパラダイムと比較することです.それは新しい考え方なので
  404: 吸収するまで少し時間がかかるかもしれませんが,理解したとき世界がより単純
  405: 化されるでしょう.
  406: 
  407: 
  408: @node Using libtool
  409: @chapter libtoolを使用する
  410: 
  411: @cindex examples of using libtool
  412: @cindex libtool examples
  413: libtoolが人生をより単純にする方法が分かるまで,独自のパッケージでlibtool 
  414: を使用することを話す意味はありません.この章の例は,標準的なライブラリの
  415: ビルド処理と,libtoolの処理を,2つの異なるプラットフォームで比較すること
  416: で,主な特徴を紹介します.
  417: 
  418: @table @samp
  419: @item a23
  420: スタティックライブラリのみのUltrix 4.2プラットフォーム.
  421: 
  422: @item burger
  423: 共有ライブラリを持つ,NetBSD/i386 1.2プラットフォーム.
  424: @end table
  425: 
  426: 独自のプラットフォームの例をこれに続けることが可能で,それは,libtoolで
  427: インストールされた,前もってコンフィグレーションされたlibtoolスクリプト
  428: を使用します(@pxref{Configuring}).
  429: 
  430: 以下の例のソースファイルは,libtool配布物の@file{demo}サブディレクトリか
  431: ら持ってきています.ファイル@file{foo.c}と@file{hello.c}からライブラリ
  432: @file{libhello}をビルドしていると仮定してください.
  433: 
  434: @file{foo.c}ソースファイルが@code{cos}数学ライブラリ関数を使用していて,
  435: それは通常,Cライブラリではなく単独の数学ライブラリで見つかることに注意
  436: してください(@pxref{Trig Functions, , Trigonometric Functions, libc, The
  437: GNU C Library Reference Manual}).そのため,@file{foo.o}や@file{foo.lo} 
  438: を実行形式やライブラリにリンクするときは,常にリンク行の最後に@kbd{-lm} 
  439: を加える必要があります(@pxref{Inter-library dependencies}).
  440: 
  441: 同じ規則は,標準Cライブラリに無い関数を使用するとき,常に当てはまります
  442: @dots{} これらのオブジェクトに対しリンクするときは,適切な
  443: @kbd{-l@var{name}}フラグをリンク行の終りに加える必要があります.
  444: 
  445: ライブラリをビルドした後,@file{libhello}に対して@file{main.o}をリンクす
  446: ることでプログラムを作成したいと思います.
  447: 
  448: @menu
  449: * Creating object files::       Compiling object files for libraries.
  450: * Linking libraries::           Creating libraries from object files.
  451: * Linking executables::         Linking object files against libtool libraries.
  452: * Debugging executables::       Running GDB on libtool-generated programs.
  453: * Installing libraries::        Making libraries available to users.
  454: * Installing executables::      Making programs available to users.
  455: * Static libraries::            When shared libraries are not wanted.
  456: @end menu
  457: 
  458: @node Creating object files
  459: @section オブジェクトファイルの作成
  460: 
  461: @cindex compiling object files
  462: @cindex object files, compiling
  463: ソースファイルからオブジェクトファイルを作成するため,コンパイラは`-c'フ
  464: ラグ(とその他の必要なあらゆるフラグ)とともに呼び出されます.
  465: 
  466: @example
  467: burger$ @kbd{gcc -g -O -c main.c}
  468: burger$
  469: @end example
  470: 
  471: 上記のコンパイラコマンドは,ソースファイル@file{main.c}からオブジェクト
  472: ファイル@file{main.o}を生成します.
  473: 
  474: ほとんどのライブラリシステムでは,スタティックライブラリの一部となるオブ
  475: ジェクトファイルを作成することは,実行可能な形式にリンクされるオブジェク
  476: トファイルを作成することと同じくらい単純です.
  477: 
  478: @example
  479: burger$ @kbd{gcc -g -O -c foo.c}
  480: burger$ @kbd{gcc -g -O -c hello.c}
  481: burger$
  482: @end example
  483: 
  484: @cindex position-independent code
  485: @cindex PIC (position-independent code)
  486: しかし,共有ライブラリは@dfn{position-independent code} (PIC)のみからビ
  487: ルドされます.そのため,標準のposition-dependent codeではなくPICを生成す
  488: るようコンパイラに伝えるため,特定のフラグを渡す必要があります.
  489: 
  490: @cindex library object file
  491: @cindex @samp{.lo} files
  492: @cindex object files, library
  493: これがライブラリ実装の詳細なので,libtoolは個別の(@samp{.o}の代わりに
  494: @samp{.lo}で終わる)ライブラリオブジェクトファイルを用いて,複雑なPICコン
  495: パイラフラグを隠蔽します.共有ライブラリが無い(または,特定のPICフラグが
  496: 無い)システムでは,これらのライブラリオブジェクトファイルは``標準の''オ
  497: ブジェクトファイルと同じです.
  498: 
  499: @file{foo.c}と@file{hello.c}に対するライブラリオブジェクトファイルを作成
  500: するため,単純に標準のコンパイルコマンドを引数として,libtoolを呼び出し
  501: てください(@pxref{Compile mode}).
  502: 
  503: @example
  504: a23$ @kbd{libtool gcc -g -O -c foo.c}
  505: gcc -g -O -c foo.c
  506: echo timestamp > foo.lo
  507: a23$ @kbd{libtool gcc -g -O -c hello.c}
  508: gcc -g -O -c hello.c
  509: echo timestamp > hello.lo
  510: a23$
  511: @end example
  512: 
  513: それぞれの呼び出しで,libtoolが2つのファイルを作成することに注意してく
  514: ださい.@samp{.lo}ファイルはライブラリオブジェクトで,それは共有ライブラ
  515: リにビルドされ,@samp{.o}ファイルは標準的なオブジェクトファイルです.
  516: @samp{a23}では,スタティックライブラリのみサポートされているので,ライブ
  517: ラリオブジェクトはタイムスタンプのみです.
  518: 
  519: 共有ライブラリのあるシステムでは,ライブラリオブジェクトと標準オブジェク
  520: トが異なるように,libtoolはPIC生成フラグをコンパイルコマンドに自動的に挿
  521: 入します.
  522: 
  523: @example
  524: burger$ @kbd{libtool gcc -g -O -c foo.c}
  525: gcc -g -O -c -fPIC -DPIC foo.c
  526: mv -f foo.o foo.lo
  527: gcc -g -O -c foo.c >/dev/null 2>&1
  528: burger$ @kbd{libtool gcc -g -O -c hello.c}
  529: gcc -g -O -c -fPIC -DPIC hello.c
  530: mv -f hello.o hello.lo
  531: gcc -g -O -c hello.c >/dev/null 2>&1
  532: burger$
  533: @end example
  534: 
  535: 2番目に実行されるGCCがその出力を破棄していることに注意してください.こ
  536: れは,コンパイラの警告がうるさく重複しないために行われます.
  537: 
  538: 
  539: @node Linking libraries
  540: @section ライブラリのリンク
  541: 
  542: @pindex ar
  543: libtoolを用いない場合,スタティックライブラリを作成するため,プログラマ
  544: は@code{ar}コマンドを呼び出していました.
  545: 
  546: @example
  547: burger$ @kbd{ar cru libhello.a hello.o foo.o}
  548: burger$
  549: @end example
  550: 
  551: @pindex ranlib
  552: しかしもちろん,それだけではあまりに単純すぎて,多くのシステムでは(それ
  553: 以上のカルマや何かを与えるため)結果として生成されたライブラリ上で,
  554: @code{ranlib}コマンドを実行する必要があります.
  555: 
  556: @example
  557: burger$ @kbd{ranlib libhello.a}
  558: burger$
  559: @end example
  560: 
  561: libtoolの``ライブラリはプログラム''というアプローチで与えられるこの作業
  562: に対して,Cコンパイラを使用することは,より自然に感じられます.そのため,
  563: 共有ライブラリが無いプラットフォームでは,libtoolは単純にシステムの
  564: @code{ar}(そして可能なら@code{ranlib})コマンドのラッパーとして動作します.
  565: 
  566: @cindex libtool libraries
  567: @cindex @samp{.la} files
  568: また,libtoolのライブラリ名は,標準の名前(@samp{.a}接尾子の代わりに
  569: @samp{.la} 接尾子を持ちます)と異なります.libtoolの引数は,コンパイラで
  570: @file{libhello.la}という名の実行形式を生成するために使用したのと同じもの
  571: です(@pxref{Link mode}).
  572: 
  573: @example
  574: a23$ @kbd{libtool gcc -g -O -o libhello.la foo.o hello.o}
  575: libtool: cannot build libtool library `libhello.la' from non-libtool \
  576:                 objects
  577: a23$
  578: @end example
  579: 
  580: あぁ!libtoolは通常のエラーを得てしまった@dots{} ライブラリオブジェクト
  581: の代わりに,標準のオブジェクトからライブラリをビルドしています.これはス
  582: タティックライブラリでは問題ありませんが,共有ライブラリシステムでは非常
  583: に重要です.
  584: 
  585: そのため,今回はライブラリオブジェクトファイルを用いて,もう一度試してみ
  586: ましょう.@file{foo.c}が@code{cos}数学ライブラリを使用しているので,コマ
  587: ンドラインに@kbd{-lm}を加える必要があることも忘れないでください
  588: (@pxref{Using libtool}).
  589: 
  590: 共有ライブラリをビルドするその他の複雑なことは,(最終的に)インストールさ
  591: れるディレクトリパス(この場合は,@file{/usr/local/lib})
  592: @footnote{@code{rpath}を指定しない場合,libtoolは便利なアーカイブをビル
  593: ドしますが,それは共有ライブラリではありません(@pxref{Static libraries}).} 
  594: を指定する必要があることです.
  595: 
  596: @example
  597: a23$ @kbd{libtool gcc -g -O -o libhello.la foo.lo hello.lo \
  598:                 -rpath /usr/local/lib -lm}
  599: mkdir @value{objdir}
  600: ar cru @value{objdir}/libhello.a foo.o hello.o
  601: ranlib @value{objdir}/libhello.a
  602: creating libhello.la
  603: a23$
  604: @end example
  605: 
  606: さて,共有ライブラリのプラットフォーム上で同じトリックを試してみましょう.
  607: 
  608: @example
  609: burger$ @kbd{libtool gcc -g -O -o libhello.la foo.lo hello.lo \
  610:                 -rpath /usr/local/lib -lm}
  611: mkdir @value{objdir}
  612: ld -Bshareable -o @value{objdir}/libhello.so.0.0 foo.lo hello.lo -lm
  613: ar cru @value{objdir}/libhello.a foo.o hello.o
  614: ranlib @value{objdir}/libhello.a
  615: creating libhello.la
  616: burger$
  617: @end example
  618: 
  619: さてそれはかなり賢いです@dots{} libtoolは共有ライブラリを作成するため,
  620: スタティックライブラリと同様に,曖昧な@code{ld}コマンドを実行しただけで
  621: す.
  622: 
  623: @cindex @file{@value{objdir}} subdirectory
  624: libtoolが,現在のディレクトリではなく,@file{@value{objdir}}サブディレク
  625: トリに余分なファイルを作成することに注意してください.この機能は,ビルド
  626: ディレクトリをきれいにするのをより簡単にするためと,たまたまlibtoolの使
  627: 用を忘れていて他のプログラムを実行するとき,確実に手ひどく失敗するので役
  628: に立ちます.
  629: 
  630: 
  631: @node Linking executables
  632: @section 実行形式のリンク
  633: 
  634: @cindex linking against installed libraries
  635: ライブラリを実行形式とリンクする前に,@dfn{インストール}する(永久に位置
  636: する場所にそれを配置する)場所を選択した場合,リンクするためにlibtoolを使
  637: 用する必要はありません.ライブラリの位置を指定するため,単純に適切な
  638: @samp{-L}と@samp{-l}フラグを使用してください.
  639: 
  640: @cindex buggy system linkers
  641: システムのリンカによっては,結果として生じる実行形式に,共有ライブラリの
  642: 完全なディレクトリ名の符号化を強要するものもあります.libtoolは,永久に
  643: 配置されるディレクトリ名のみをインストールされた実行形式に書き込むことを
  644: 確実にするため,特別な魔法でこの設計ミスに関して動作する必要があります.
  645: 
  646: @cindex security problems with buggy linkers
  647: @cindex bugs, subtle ones caused by buggy linkers
  648: このバグの重要性は見落としてはなりません.それによるプログラムの暴走は明
  649: 白ではありません.それはセキュリティホールを作成し,さらに悪いことには,
  650: パッケージのインストール後にライブラリソースコードを編集した場合,インス
  651: トールされたプログラムの動作を変更してしまうでしょう!
  652: 
  653: そのため,インストールする前にライブラリとプログラムをリンクさせたい場合,
  654: リンクするためにlibtoolを使用する必要があります.
  655: 
  656: @cindex linking against uninstalled libraries
  657: インストールされていないライブラリとリンクする古い方法は,以下のようにな
  658: ります.
  659: 
  660: 
  661: @example
  662: burger$ @kbd{gcc -g -O -o hell.old main.o libhello.a -lm}
  663: burger$
  664: @end example
  665: 
  666: libtoolの方法は,ほとんど同じです@footnote{しかし,インストールされてい
  667: ないlibtoolライブラリにリンクするために,@samp{-L}や@samp{-l}フラグの使
  668: 用は避けたほうがいいでしょう.@samp{.la}ファイルに対する,
  669: @file{../intl/libintl.la}のような相対パスのみを指定してください.これは,
  670: インストールされていない共有ライブラリに対しリンクするとき,あらゆる曖昧
  671: さを取り除くため決定された設計です.}(@pxref{Link mode}).
  672: 
  673: @example
  674: a23$ @kbd{libtool gcc -g -O -o hell main.o libhello.la -lm}
  675: gcc -g -O -o hell main.o ./@value{objdir}/libhello.a -lm
  676: a23$
  677: @end example
  678: 
  679: 真実としてはあまりに単純に見えます.libtoolが行うことは,
  680: @file{libhello.la}を@file{./@value{objdir}/libhello.a}に変換することがす
  681: べてですが,@samp{a23}は共有ライブラリがないことを忘れないでください.
  682: 
  683: @samp{burger}では,状況が異なります.
  684: 
  685: @example
  686: burger$ @kbd{libtool gcc -g -O -o hell main.o libhello.la -lm}
  687: gcc -g -O -o @value{objdir}/hell main.o -L./@value{objdir} -R/usr/local/lib -lhello -lm
  688: creating hell
  689: burger$
  690: @end example
  691: 
  692: @cindex linking with installed libtool libraries
  693: 
  694: さて,@file{libhello.la}が既にインストールされていると仮定し,新しいプロ
  695: グラムをそれとリンクしたいとします.自分でそれがある場所を探し,以下を実
  696: 行します.
  697: 
  698: @example
  699: burger$ @kbd{gcc -g -O -o test test.o -L/usr/local/lib -lhello}
  700: @end example
  701: 
  702: しかし,@file{/usr/local/lib}が標準のライブラリ検索パスに無い場合,
  703: @code{test}を実行することはできません.しかし,既にインストールされてい
  704: るlibtoolライブラリとリンクするためlibtoolを使用する場合,それは The
  705: Right Thing (TM)となります.
  706: 
  707: @example
  708: burger$ @kbd{libtool gcc -g -O -o test test.o /usr/local/lib/libhello.la}
  709: gcc -g -O -o @value{objdir}/test test.o -Wl,--rpath
  710: -Wl,/usr/local/lib /usr/local/lib/libhello.a -lm
  711: creating test
  712: burger$
  713: @end example
  714: 
  715: libtoolが,ライブラリlibhello.laが依存している@samp{-lm}同様,必要なラン
  716: タイムパスフラグを追加していることに注意してください.いいですね,ふっふ?
  717: 
  718: libtoolがラッパースクリプトを作成したので,インストールとデバッグにも
  719: libtoolを使用したほうがいいでしょう.しかし,プログラムはインストールさ
  720: れていないlibtoolライブラリには全く依存しないので,ラッパースクリプトを
  721: 用いない場合でもおそらく有用でしょう.この場合は,ラッパースクリプトの作
  722: 成を避けるため,おそらくより賢くlibtoolを作成できたでしょうが,これは読
  723: 者の演習として残しておきます.
  724: 
  725: 
  726: @cindex wrapper scripts for programs
  727: @cindex program wrapper scripts
  728: 実行形式@code{hell}は,実際には@file{@value{objdir}}サブディレクトリに作
  729: 成されることに注意してください.そして,ラッパースクリプトは現在のディレ
  730: クトリに作成されます.
  731: 
  732: NetBSD 1.2では,libtoolは@samp{-R/usr/local/lib}コンパイラフラグを使用し
  733: て,@file{libhello}のディレクトリのインストールを符号化します.そして,
  734: ラッパースクリプトは,正しくインストールされるまで実行形式が正しい
  735: (@file{./@value{objdir}}にある)共有ライブラリを見つけることを保証します.
  736: 
  737: 2つの異なるプログラムを比較してみましょう.
  738: 
  739: @example
  740: burger$ @kbd{time ./hell.old}
  741: Welcome to GNU Hell!
  742: ** This is not GNU Hello.  There is no built-in mail reader. **
  743:         0.21 real         0.02 user         0.08 sys
  744: burger$ @kbd{time ./hell}
  745: Welcome to GNU Hell!
  746: ** This is not GNU Hello.  There is no built-in mail reader. **
  747:         0.63 real         0.09 user         0.59 sys
  748: burger$
  749: @end example
  750: 
  751: ラッパースクリプトは実行にかなり時間がかかりますが,共有ライブラリがイン
  752: ストールされていなくても,少なくとも結果は正しくなります.
  753: 
  754: そのため,共有ライブラリがもたらした,全体的なスペース削減ははどうなって
  755: いるのでしょう?
  756: 
  757: @example
  758: burger$ @kbd{ls -l hell.old libhello.a}
  759: -rwxr-xr-x  1 gord  gord  15481 Nov 14 12:11 hell.old
  760: -rw-r--r--  1 gord  gord   4274 Nov 13 18:02 libhello.a
  761: burger$ @kbd{ls -l @value{objdir}/hell @value{objdir}/libhello.*}
  762: -rwxr-xr-x  1 gord  gord  11647 Nov 14 12:10 @value{objdir}/hell
  763: -rw-r--r--  1 gord  gord   4274 Nov 13 18:44 @value{objdir}/libhello.a
  764: -rwxr-xr-x  1 gord  gord  12205 Nov 13 18:44 @value{objdir}/libhello.so.0.0
  765: burger$
  766: @end example
  767: 
  768: うーん,だめだなあ@footnote{訳注:原文は,Well, that sucks.}.おそらく,
  769: 私はこのプロジェクトを破壊し,作成中のゆりかごを取り上げたほうがいいでしょ
  770: う.
  771: 
  772: 実際,それは重要なことを証明しています.共有ライブラリには,それが(関連
  773: する)複雑さのため,オーバーへッドをがあります.この状況では,ダイナミッ
  774: クの価値は8キロバイトで,報酬は約4キロバイトです.そのため,少なくとも2,
  775: 3個以上のプログラムとリンクするまで,共有される@file{libhello}を維持する
  776: ことは利点になりません.
  777: 
  778: 
  779: @node Debugging executables
  780: @section 実行形式のデバッグ
  781: 
  782: @file{hell}が複雑なプログラムの場合,システムにインストールする前にそれ
  783: のテストとデバッグを間違いなく行いたいでしょう.上記のセクションで,
  784: libtoolラッパースクリプトが,プログラムを直接実行することを可能にする方
  785: 法を見ましたが,残念ながら,このメカニズムはデバッガの邪魔になります.
  786: 
  787: @example
  788: burger$ @kbd{gdb hell}
  789: GDB is free software and you are welcome to distribute copies of it
  790:  under certain conditions; type "show copying" to see the conditions.
  791: There is no warranty for GDB; type "show warranty" for details.
  792: GDB 4.16 (i386-unknown-netbsd), (C) 1996 Free Software Foundation, Inc.
  793: 
  794: "hell": not in executable format: File format not recognized
  795: 
  796: (gdb) @kbd{quit}
  797: burger$
  798: @end example
  799: 
  800: 残念です.GDBは実行形式がある場所が分からないので動作しません.そのため,
  801: もう一度実行形式でGDBを呼び出してみてください.
  802: 
  803: @example
  804: burger$ @kbd{gdb @value{objdir}/hell}
  805: trick:/home/src/libtool/demo$ gdb .libs/hell
  806: GDB is free software and you are welcome to distribute copies of it
  807:  under certain conditions; type "show copying" to see the conditions.
  808: There is no warranty for GDB; type "show warranty" for details.
  809: GDB 4.16 (i386-unknown-netbsd), (C) 1996 Free Software Foundation, Inc.
  810: (gdb) @kbd{break main}
  811: Breakpoint 1 at 0x8048547: file main.c, line 29.
  812: (gdb) @kbd{run}
  813: Starting program: /home/src/libtool/demo/.libs/hell
  814: /home/src/libtool/demo/.libs/hell: can't load library 'libhello.so.2'
  815: 
  816: Program exited with code 020.
  817: (gdb) @kbd{quit}
  818: burger$
  819: @end example
  820: 
  821: あぁ.さて,GDBは,@file{hell}がリンクしている共有ライブラリを見つけるこ
  822: とができないため文句を言いました.そのため,正しいライブラリパスを設定し
  823: てデバッガを実行するために,libtoolを使う必要があります.幸い,
  824: @file{@value{objdir}}ディレクトリを完全に忘れて,そのままの実行形式のラッ
  825: パーで実行可能です(@pxref{Execute mode}).
  826: 
  827: @example
  828: burger$ @kbd{libtool gdb hell}
  829: GDB is free software and you are welcome to distribute copies of it
  830:  under certain conditions; type "show copying" to see the conditions.
  831: There is no warranty for GDB; type "show warranty" for details.
  832: GDB 4.16 (i386-unknown-netbsd), (C) 1996 Free Software Foundation, Inc.
  833: (gdb) @kbd{break main}
  834: Breakpoint 1 at 0x8048547: file main.c, line 29.
  835: (gdb) @kbd{run}
  836: Starting program: /home/src/libtool/demo/.libs/hell
  837: 
  838: Breakpoint 1, main (argc=1, argv=0xbffffc40) at main.c:29
  839: 29	  printf ("Welcome to GNU Hell!\n");
  840: (gdb) @kbd{quit}
  841: The program is running.  Quit anyway (and kill it)? (y or n) @kbd{y}
  842: burger$
  843: @end example
  844: 
  845: 
  846: @node Installing libraries
  847: @section ライブラリのインストール
  848: 
  849: @pindex strip
  850: libtoolが無いシステムでライブラリをインストールすることは,全く簡単です
  851: @dots{} それらをその場所にコピーするだけです.@footnote{偶発的にライブラ
  852: リをstripしないでください,そうすると使用不可能になります.}
  853: 
  854: @pindex su
  855: @example
  856: burger$ @kbd{su}
  857: Password: @kbd{********}
  858: burger# @kbd{cp libhello.a /usr/local/lib/libhello.a}
  859: burger#
  860: @end example
  861: 
  862: おっと,@code{ranlib}コマンドを忘れないでください.
  863: 
  864: @example
  865: burger# @kbd{ranlib /usr/local/lib/libhello.a}
  866: burger#
  867: @end example
  868: 
  869: @pindex install
  870: libtoolのインストールは,同様に全く単純です.通常使用する,
  871: @code{install}や@code{cp}コマンドをそのまま使用してください
  872: (@pxref{Install mode}).
  873: 
  874: @example
  875: a23# @kbd{libtool cp libhello.la /usr/local/lib/libhello.la}
  876: cp libhello.la /usr/local/lib/libhello.la
  877: cp @value{objdir}/libhello.a /usr/local/lib/libhello.a
  878: ranlib /usr/local/lib/libhello.a
  879: a23#
  880: @end example
  881: 
  882: アンインストールでlibtoolを助け(@pxref{Uninstall mode}),リンクし
  883: (@pxref{Linking executables}),dlopenでプログラムを助ける
  884: (@pxref{Dlopened modules})ため,libtoolのライブラリ@file{libhello.la}も
  885: インストールされることに注意してください.
  886: 
  887: Here is the shared library example:
  888: 
  889: 共有ライブラリの例は,以下のようになります.
  890: 
  891: @example
  892: burger# @kbd{libtool install -c libhello.la /usr/local/lib/libhello.la}
  893: install -c @value{objdir}/libhello.so.0.0 /usr/local/lib/libhello.so.0.0
  894: install -c libhello.la /usr/local/lib/libhello.la
  895: install -c @value{objdir}/libhello.a /usr/local/lib/libhello.a
  896: ranlib /usr/local/lib/libhello.a
  897: burger#
  898: @end example
  899: 
  900: @cindex stripping libraries
  901: @cindex libraries, stripping
  902: ライブラリインストール時にBSD互換のinstallプログラムを使用する場合,
  903: @samp{-s}(シンボルのstrip)フラグを指定すると安全です.libtoolは@samp{-s} 
  904: フラグを無視する,またはライブラリからデバッグとコンパイラシンボルのみを
  905: stripするプログラムを実行します.
  906: 
  907: ライブラリを一度配置すると,使用する前に必要な追加のコンフィグレーション
  908: を行います.最初に,ビルド時に使用した@samp{-rpath}フラグと同じ場所に,
  909: ライブラリが実際にインストールされていることを確かめる必要があります.
  910: 
  911: @cindex postinstallation
  912: @cindex installation, finishing
  913: @cindex libraries, finishing installation
  914: そして,@samp{libtool -n --finish @var{libdir}}を実行すると,行うことの
  915: ヒントが与えられるはずです(@pxref{Finish mode}).
  916: 
  917: @example
  918: burger# @kbd{libtool -n --finish /usr/local/lib}
  919: PATH="$PATH:/sbin" ldconfig -m /usr/local/lib
  920: -----------------------------------------------------------------
  921: Libraries have been installed in:
  922:    /usr/local/lib
  923: 
  924: To link against installed libraries in a given directory, LIBDIR,
  925: you must use the `-LLIBDIR' flag during linking.
  926: 
  927:  You will also need to do one of the following:
  928:    - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
  929:      during execution
  930:    - add LIBDIR to the `LD_RUN_PATH' environment variable
  931:      during linking
  932:    - use the `-RLIBDIR' linker flag
  933: 
  934: See any operating system documentation about shared libraries for
  935: more information, such as the ld and ld.so manual pages.
  936: -----------------------------------------------------------------
  937: burger#
  938: @end example
  939: 
  940: これらのステップを完了した後,インストールされたライブラリの使用開始が可
  941: 能になります.作成されたライブラリに依存する実行形式もインストールできま
  942: す.
  943: 
  944: 
  945: @node Installing executables
  946: @section 実行形式のインストール
  947: 
  948: インストールされていないlibtoolライブラリに対して,実行形式をリンクする
  949: ためにlibtoolを使用した場合(@pxref{Linking executables}),ライブラリをイ
  950: ンストールした後に実行形式をインストールするため,libtoolを使用する必要
  951: があります.
  952: 
  953: それでは,Ultrixの例を対象に,以下のように実行します.
  954: 
  955: @example
  956: a23# libtool install -c hell /usr/local/bin/hell
  957: install -c hell /usr/local/bin/hell
  958: a23#
  959: @end example
  960: 
  961: 共有ライブラリシステムでは,libtoolはラッパースクリプトを無視し,正しい
  962: バイナリをインストールします.
  963: 
  964: @example
  965: burger# libtool install -c hell /usr/local/bin/hell
  966: install -c @value{objdir}/hell /usr/local/bin/hell
  967: burger#
  968: @end example
  969: 
  970: 
  971: @node Static libraries
  972: @section スタティックライブラリとのリンク
  973: 
  974: @cindex static linking
  975: @cindex convenience libraries
  976: libtoolの旨味を知って,@code{ar}と@code{ranlib}の愚かさへなぜ戻るのでしょ
  977: う?さて,決して共有されるはずがないスタティックアーカイブをつくることが
  978: 望ましいときもあります.最もよくある状況として,複数の異なるプログラムを
  979: ビルドするために使用する,オブジェクトファイルの集まりを持っているときが
  980: あります.個々のプログラムに対し,すべてのオブジェクトファイルをリストアッ
  981: プする代わりに,それらのオブジェクトから``便利なライブラリ''を作成し,ラ
  982: イブラリとプログラムをリンクすることが可能です.この技術は,他のディレク
  983: トリのライブラリへのリンクをサポートするので,他のディレクトリのソースか
  984: らビルドされるオブジェクトファイルをリンクするサポートが欠けている,GNU
  985: automakeを補うためによく使用されます.この制限は,リリース1.4までのGNU
  986: automakeに当てはまります.より新しいリリースは,他のディレクトリのソース
  987: をサポートするでしょう.
  988: 
  989: この便利なライブラリとプログラムをリンクしたいだけの場合,完全にlibtool
  990: を無視し,古い@code{ar}と@code{ranlib}コマンド(や,対応するGNU automake
  991: @samp{_LIBRARIES}規則)が使用可能です.(おそらく使用したくはないでしょう
  992: が)libtoolを使用して,便利なライブラリをインストールすることさえ可能です.
  993: 
  994: @example
  995: burger$ @kbd{libtool ./install-sh -c libhello.a /local/lib/libhello.a}
  996: ./install-sh -c libhello.a /local/lib/libhello.a
  997: ranlib /local/lib/libhello.a
  998: burger$
  999: @end example
 1000: 
 1001: スタティックライブラリのインストールにlibtoolを使用すると,ライブラリが
 1002: (@samp{-s}フラグを使用したインストーラの場合のように)偶然stripされること
 1003: から守り,自動的に実行される正しい@code{ranlib}コマンドと同様になります.
 1004: 
 1005: しかし,libtoolライブラリは単にオブジェクトファイルの集合以上です.それ
 1006: らは古いアーカイブにはない,ライブラリの依存情報をも運ぶことが可能です.
 1007: libtoolの静的な便利なライブラリを作成したい場合,スタティックライブラリ
 1008: のみに興味があることを示すため,@samp{-rpath}フラグを省略し
 1009: @samp{-static}を使用することができます.そのようなスタティックライブラリ
 1010: とリンクするとき,libtoolは実際にすべてのオブジェクトファイルと依存する
 1011: ライブラリをプログラムにリンクします.
 1012: 
 1013: @samp{-rpath}と@samp{-static}の両方を省略した場合,libtoolは,他の
 1014: libtoolライブラリで,共有ライブラリの作成にすら使用可能なlibtoolの便利な
 1015: ライブラリを作成します.静的な場合のように,ライブラリは一組のオブジェク
 1016: トファイルと依存するライブラリの別名として動作しますが,この場合,オブジェ
 1017: クトファイルは共有ライブラリに含まれるほうが適しています.しかし,直接ま
 1018: たは間接的に,単一のプログラムやライブラリに単一の便利なライブラリをリン
 1019: クしないように注意して下さい.さもなければ,シンボル再定義に関するエラー
 1020: を得るでしょう.
 1021: 
 1022: GNU automakeを使用するとき,@samp{-rpath}オプションがリンク時に渡されな
 1023: いように,便利なライブラリに対する@code{lib_LTLIBRARIES}の代わりに
 1024: @code{noinst_LTLIBRARIES}を使用した方が良いでしょう.
 1025: 
 1026: 経験的に,最大一つのlibtoolライブラリにlibtoolの便利なライブラリをリンク
 1027: し,プログラムにはリンクしないようにしてください,そして,libtoolの便利
 1028: なスタティックライブラリを一つのプログラムにのみリンクし,それは,ライブ
 1029: ラリ依存情報を便利なスタティックライブラリのユーザに運ぶことが必要な場合
 1030: のみにしてください.
 1031: 
 1032: @cindex standalone binaries
 1033: 静的なリンクが適している,その他の一般的な状況は,独立したバイナリを作成
 1034: するときです.リンクにlibtoolを使用し,@samp{-all-static}フラグを加えて
 1035: ください.
 1036: 
 1037: 
 1038: @node Invoking libtool
 1039: @chapter @code{libtool}の呼び出し
 1040: @pindex libtool
 1041: @cindex libtool command options
 1042: @cindex options, libtool command
 1043: @cindex command options, libtool
 1044: 
 1045: @code{libtool}プログラムは以下の構文を持ちます.
 1046: 
 1047: @example
 1048: libtool [@var{option}]@dots{} [@var{mode-arg}]@dots{}
 1049: @end example
 1050: 
 1051: @noindent
 1052: そして,以下のオプションを受け入れます.
 1053: 
 1054: @table @samp
 1055: @item --config
 1056: libtoolのコンフィグレーション変数を表示し終了します.
 1057: 
 1058: @item --debug
 1059: シェルスクリプトの実行の追跡を標準出力にダンプします.これは多くの出力を
 1060: 生成するので,@code{less}(や@code{more})にパイプしたり,ファイルにリダイ
 1061: レクトしたいかもしれません.
 1062: 
 1063: @item -n
 1064: @itemx --dry-run
 1065: あらゆるファイルを作成,編集,削除せず,libtoolで実行されるコマンドのみ
 1066: を表示します.
 1067: 
 1068: @item --features
 1069: 基本的なコンフィグレーションオプションを表示します.これは,パッケージが
 1070: ビルドするライブラリを,スタティックまたは共有のいずれにするか決定する方
 1071: 法を提供します.
 1072: 
 1073: @item --finish
 1074: @samp{--mode=finish}と同じです.
 1075: 
 1076: @item --help
 1077: へルプメッセージを表示し終了します.@samp{--mode=@var{mode}}が指定された
 1078: 場合,@var{mode}の詳細へルプを表示します.
 1079: 
 1080: @item --mode=@var{mode}
 1081: 処理モードとして@var{mode}を使用します.デフォルトで,処理モードは
 1082: @var{mode-args}から推測されます.
 1083: 
 1084: @var{mode}が指定された場合,それは以下の一つにする必要があります.
 1085: 
 1086: @table @samp
 1087: @item compile
 1088: ソースファイルをlibtoolオブジェクトにコンパイルします.
 1089: 
 1090: @item execute
 1091: インストールされていない,libtoolが生成したプログラムやライブラリを他の
 1092: プログラムが使用できるように,自動的にライブラリパスを設定します.
 1093: 
 1094: @item finish
 1095: libtoolライブラリのシステムへのインストールを完全に行います.
 1096: 
 1097: @item install
 1098: ライブラリや実行形式をインストールします.
 1099: 
 1100: @item link
 1101: ライブラリや実行形式を作成します.
 1102: 
 1103: @item uninstall
 1104: インストールされたライブラリや実行形式を削除します.
 1105: 
 1106: @item clean
 1107: アンインストールされたライブラリや実行形式を削除します.
 1108: @end table
 1109: 
 1110: @item --version
 1111: ibtoolのバージョン情報を出力し終了します.
 1112: @end table
 1113: 
 1114: @var{mode-args}は引数の変数の数で,それは処理モードの選択に依存します.
 1115: 一般的に,それぞれの@var{mode-arg}は,libtool自身ではなく,libtoolが呼び
 1116: 出すプログラムで解釈されます.
 1117: 
 1118: @menu
 1119: * Compile mode::                Creating library object files.
 1120: * Link mode::                   Generating executables and libraries.
 1121: * Execute mode::                Debugging libtool-generated programs.
 1122: * Install mode::                Making libraries and executables public.
 1123: * Finish mode::                 Completing a library installation.
 1124: * Uninstall mode::              Removing installed executables and libraries.
 1125: * Clean mode::                  Removing uninstalled executables and libraries.
 1126: @end menu
 1127: 
 1128: @node Compile mode
 1129: @section コンパイルモード
 1130: @cindex mode, compile
 1131: @cindex compile mode
 1132: 
 1133: @dfn{コンパイル}モードに対し,@var{mode-args}は,`標準的な'オブジェクト
 1134: ファイルを作成するとき使用するコンパイルコマンドです.これらの引数は,C 
 1135: コンパイラの名前で始まり,オブジェクトファイルのみを作成するための
 1136: @samp{-c}コンパイラフラグを含みます.
 1137: 
 1138: libtoolは,ソースファイル名からディレクトリ要素を削除して出力ファイル名
 1139: を決定し,ソースコードの接尾子(例えば,Cソースコードに対する@samp{.c})を
 1140: ライブラリオブジェクト接尾子@samp{.lo}に置換します.
 1141: 
 1142: 共有ライブラリをビルドする場合は,必要なPIC生成フラグがコンパイルコマン
 1143: ドに置換されます.@samp{-Wc,@var{flag}}と@samp{-Xcompiler @var{flag}}を
 1144: 使用したり,@samp{-Wl,@var{flag}}と@samp{-Xlinker @var{flag}}を使用した
 1145: りして,それぞれ,コンパイラとリンカに指定したフラグを渡すことが可能です.
 1146: 
 1147: @samp{-static}オプションが与えられている場合は,libtoolが
 1148: @samp{--disable-static}でコンフィグレーションされていた場合でも,
 1149: @samp{.o}ファイルがビルされてます.
 1150: 
 1151: 現在は@samp{-o}オプションが,完全にサポートされていることに注意してくだ
 1152: さい.それがサポートされていないプラットフォームでは,(オブジェクトのロッ
 1153: クと移動によって)エミュレートされるので,Makefileを少し編集するだけで
 1154: libtoolは本当に簡単に使用できます.入力例は以下のようになります.
 1155: @example
 1156: libtool gcc -c foo/x.c -o foo/x.lo
 1157: @end example
 1158: これは期待したことを行います.
 1159: 
 1160: しかし,コンパイラが@samp{-c}と@samp{-o}をサポートしていない場合,既存の
 1161: @file{./x.o}を上書きせずに@file{foo/x.c}をコンパイルすることが不可能なこ
 1162: とに注意してください.そのため,ソースファイル@file{./x.c}がある場合,
 1163: @file{./x.o}(や@file{./x.lo})が,サブディレクトリのあらゆる@file{x.lo}の
 1164: 後で再作成されることを確実にするため,@file{Makefile}に依存性の導入を必
 1165: ず行ってください.
 1166: @example
 1167: x.o x.lo: foo/x.lo bar/x.lo
 1168: @end example
 1169: これは,プログラムやライブラリを作成するため,一時的に壊れた@file{x.o}の
 1170: 使用を試みないことを確実にします.それは,@samp{-c}と@samp{-o}を同時にサ
 1171: ポートするプラットフォームで,不必要な再コンパイルを引き起こすかもしれま
 1172: せんが,それは,そうでないものに対して安全にする唯一の方法です.
 1173: 
 1174: 
 1175: @node Link mode
 1176: @section リンクモード
 1177: @cindex link mode
 1178: @cindex mode, link
 1179: 
 1180: @dfn{リンク}モードは,(ライブラリオブジェクトを含む)オブジェクトファイル
 1181: と,その他のライブラリや作成された実行可能なプログラムをリンクします.
 1182: 
 1183: @var{mode-args}は,いくつかのオブジェクトファイルから(@samp{-o}フラグを
 1184: 用いた)出力ファイルを作成するためにCコンパイラが使用するコマンドから成り
 1185: 立ちます.
 1186: 
 1187: 以下の@var{mode-args}の組は特別に扱われます.
 1188: 
 1189: @table @samp
 1190: @cindex undefined symbols, allowing
 1191: @cindex unresolved symbols, allowing
 1192: @item -all-static
 1193: @var{output-file}がプログラムの場合,共有ライブラリと全くリンクしません.
 1194: @var{output-file}がライブラリの場合,スタティックライブラリのみ作成しま
 1195: す.
 1196: 
 1197: @item -avoid-version
 1198: ライブラリとモジュールに対しバージョン管理(@pxref{Versioning})を避けよう
 1199: とし,すなわち,バージョン情報は保存されず,シンボリックリンクも作成され
 1200: ません.プラットフォームがバージョニングを要求する場合,このオプションは
 1201: 効果がありません.
 1202: 
 1203: @item -dlopen @var{file}
 1204: ネイティブなdlopenがホストプラットフォームでサポートされていない場合
 1205: (@pxref{Dlopened modules})や,プログラムが@samp{-static}や
 1206: @samp{-all-static}でリンクされている場合,@samp{-dlpreopen @var{file}}と
 1207: 同じです.それ以外では効果はありません.@var{file}が@code{self}の場合,
 1208: @code{-export-dynamic}を可能にする,または,@samp{-dlpreopen self}に後退
 1209: することにより,libtoolはプログラムがそれ自身を@code{dlopen}可能であるこ
 1210: とを確かめます.
 1211: 
 1212: @item -dlpreopen @var{file}
 1213: @var{file}を出力プログラムにリンクし,そのシンボルを
 1214: @var{lt_preloaded_symbols}に含めます(@pxref{Dlpreopening}).@var{file}が
 1215: @code{self}の場合,プログラムのシンボル自身が@var{lt_preloaded_symbols} 
 1216: に加えられます.@var{file}が@code{force}の場合,libtoolは,
 1217: @var{lt_preloaded_symbols}が空であろうがなかろうが,常に@emph{定義済}で
 1218: あることを確実にします.
 1219: 
 1220: @item -export-dynamic
 1221: @var{output-file}からのシンボルが@code{dlsym}で解決されることを可能にし
 1222: ます(@pxref{Dlopened modules}).
 1223: 
 1224: @item -export-symbols @var{symfile}
 1225: リンカに@var{symfile}でリストアップされているシンボルのみエクスポートす
 1226: るよう伝えます.シンボルファイルは@samp{.sym}で終わるべきで,一行毎に一
 1227: シンボル名を含める必要があります.このオプションに効果がないプラットフォー
 1228: ムがあります.デフォルトですべてのシンボルがエクスポートされます.
 1229: 
 1230: @item -export-symbols-regex @var{regex}
 1231: 正規表現@var{regex}に一致するシンボルのみエクスポートされる以外,
 1232: @samp{-export-symbols}と同じです.デフォルトですべてのシンボルがエクスポー
 1233: トされます.
 1234: 
 1235: @item -L@var{libdir}
 1236: 既にインストールされている,要求されているライブラリに対し,@var{libdir}
 1237: を検索します.
 1238: 
 1239: @item -l@var{name}
 1240: @var{output-file}はインストールされているライブラリ@file{lib@var{name}} 
 1241: を要求します.このオプションは@var{output-file}が実行形式でないときも要
 1242: 求されます.
 1243: 
 1244: @item -module
 1245: dlopen可能なライブラリを作成します(@pxref{Dlopened modules}).このオプショ
 1246: ンはプログラムでは動作しません.モジュール名の'lib'の前置は不要です.し
 1247: かし,名前の破壊を避けるため,'libname'と'name' パッケージで同時に使用し
 1248: てはなりません.
 1249: 
 1250: @item -no-fast-install
 1251: 実行形式@var{output-file}の高速インストールモードを利用不可にします.プ
 1252: ログラムをインストールする必要がないとき役に立ちます.
 1253: 
 1254: @item -no-install
 1255: インストール不可能で,そのためラップスクリプトが不要な実行形式
 1256: @var{output-file}をリンクします.プログラムがビルドツリーでのみ使用され
 1257: る場合,例えば,テストしたり他のファイルを生成するプログラムに対して役に
 1258: 立ちます.
 1259: 
 1260: @item -no-undefined
 1261: @var{output-file}が他のライブラリに依存しないことを宣言します.他のライ
 1262: ブラリに依存する共有ライブラリを作成不可能なプラットフォームもあります
 1263: (@pxref{Inter-library dependencies}).
 1264: 
 1265: @item -o @var{output-file}
 1266: 指定されたオブジェクトとライブラリから@var{output-file}を作成します.
 1267: 
 1268: @item -release @var{release}
 1269: ユーザが他より新しいバージョンを簡単に伝えられるよう,パッケージのリリー
 1270: ス@var{release}で生成されたライブラリを指定します.このフラグを使用する
 1271: 場合,パッケージの2つのリリースがバイナリ互換でないことを警告されます.
 1272: バイナリ互換が欲しい場合,代わりに@samp{-version-info}フラグを使用してく
 1273: ださい(@pxref{Versioning}).
 1274: 
 1275: @item -rpath @var{libdir}
 1276: @var{output-file}がlibtoolライブラリの場合,それをビルドするために,バー
 1277: ジョン情報@var{current},@var{revision},そして@var{age}を使用します
 1278: (@pxref{Versioning}).このフラグをパッケージのリリース情報の指定に使用せ
 1279: ず,そのためには@samp{-release}を参照してください.
 1280: 
 1281: @item -R @var{libdir}
 1282: @var{output-file}がプログラムの場合,プログラムの実行時のパスを
 1283: @var{libdir}に加えます.@var{output-file}がライブラリの場合,ライブラリ
 1284: がプログラムとリンクされるときは,常に@var{libdir}が実行時のパスに加えら
 1285: れるように,その@var{dependency_libs}に-R@var{libdir}を加えます.
 1286: 
 1287: @item -static
 1288: @var{output-file}がプログラムの場合,インストールされていない共有ライブ
 1289: ラリとリンクしません.@var{output-file}がライブラリの場合,スタティック
 1290: ライブラリのみ作成します.
 1291: 
 1292: @item -version-info @var{current}[:@var{revision}[:@var{age}]]
 1293: @var{output-file}がlibtoolライブラリの場合,それをビルドするために,バー
 1294: ジョン情報@var{current},@var{revision},そして@var{age}を使用します
 1295: (@pxref{Versioning}).このフラグをパッケージのリリース情報の指定に使用せ
 1296: ず,そのためには@samp{-release}を参照してください.
 1297: 
 1298: @item -Wl,@var{flag}
 1299: @itemx -Xlinker @var{flag}
 1300: リンカ指定のフラグを直接リンカに渡します.
 1301: @end table
 1302: 
 1303: @var{output-file}が@samp{.la}で終わる場合,libtoolライブラリが作成され,
 1304: それはライブラリオブジェクト(@samp{.lo}ファイル)のみから作成される必要が
 1305: あります.@samp{-rpath}オプションは要求されません.現在の実装では,
 1306: libtoolライブラリが他のインストールされていないlibtoolライブラリに依存す
 1307: ることはできません(@pxref{Inter-library dependencies}).
 1308: 
 1309: @var{output-file}が@samp{.a}で終わる場合,標準的なライブラリは@code{ar} 
 1310: と,おそらく@code{ranlib}を使用して作成されます.
 1311: 
 1312: @cindex partial linking
 1313: @cindex linking, partial
 1314: @var{output-file}が@samp{.o}や@samp{.lo}で終わる場合,リロード可能なオブ
 1315: ジェクトファイルは,(通常@samp{ld -r}を用いて)入力ファイルから作成されま
 1316: す.この手法は@dfn{部分的なリンク}と呼ばれることが多いです.
 1317: 
 1318: それ以外の場合,実行可能なプログラムが作成されます.
 1319: 
 1320: 
 1321: @node Execute mode
 1322: @section 実行モード
 1323: @cindex execute mode
 1324: @cindex mode, execute
 1325: 
 1326: @samp{実行}モードに対し,ライブラリパスは自動的に設定され,プログラムは
 1327: 実行されます.
 1328: 
 1329: @var{mode-args}の最初は,プログラム名として扱われ,残りはプログラムの引
 1330: 数となります.
 1331: 
 1332: 以下の@var{mode-args}の組は特別に扱われます.
 1333: 
 1334: @table @samp
 1335: @item -dlopen @var{file}
 1336: ライブラリパスに@var{file}を含むディレクトリを加えます.
 1337: @end table
 1338: 
 1339: このモードは,あらゆる@samp{-dlopen}フラグによって,ライブラリパス環境変
 1340: 数を設定します.
 1341: 
 1342: すべての@var{args}がlibtoolの実行形式のラッパーの場合,それらは対応する
 1343: インストールされていないバイナリの名前に変換され,それらが要求するすべて
 1344: のライブラリディレクトリがライブラリパスに加えられます.
 1345: 
 1346: 
 1347: @node Install mode
 1348: @section インストールモード
 1349: @cindex install mode
 1350: @cindex mode, install
 1351: 
 1352: @dfn{インストール}モードでは,libtoolは@var{mode-args}を,@code{cp}で始
 1353: まるインストールコマンドやBSD互換の@code{install}プログラムとして解釈し
 1354: ます.
 1355: 
 1356: @var{mode-args}の残りは,そのコマンドの引数として解釈されます.
 1357: 
 1358: コマンドが実行され,特権の不要な必要なインストール後のコマンドも完全に実
 1359: 行されます.
 1360: 
 1361: 
 1362: @node Finish mode
 1363: @section フィニッシュモード
 1364: @cindex finish mode
 1365: @cindex mode, finish
 1366: 
 1367: @dfn{フィニッシュ}モードは,ユーザプログラムにlibtoolライブラリを配置し
 1368: リンクできるよう,システム管理者のインストールを助けます.
 1369: 
 1370: それぞれの@var{mode-arg}はライブラリのディレクトリの名前として解釈されま
 1371: す.このコマンドの実行は,@samp{--dry-run}オプションが役に立つように,スー
 1372: パーユーザの特権を要求するかもしれません.
 1373: 
 1374: 
 1375: @node Uninstall mode
 1376: @section アンインストールモード
 1377: @cindex uninstall mode
 1378: @cindex mode, uninstall
 1379: 
 1380: @dfn{アンインストール}モードはインストールされているライブラリ,実行形式,
 1381: そしてオブジェクトを削除します.
 1382: 
 1383: @var{mode-arg}の最初はファイルの削除に使用するプログラム名(通常は
 1384: @file{/bin/rm})です.
 1385: 
 1386: 残りの@var{mode-args}は,(`-'で始まる)削除プログラムに対するフラグ,また
 1387: は削除するファイル名です.
 1388: 
 1389: 
 1390: @node Clean mode
 1391: @section クリーンモード
 1392: @cindex clean mode
 1393: @cindex mode, clean
 1394: 
 1395: @dfn{クリーン}モードはアンインストールされたライブラリ,実行形式,オブジェ
 1396: クト,そして,それらに関連があるlibtoolの一時ファイルを削除します.
 1397: 
 1398: 最初の@var{mode-arg}は,ファイルを削除するために使用するプログラムの名前
 1399: (通常は@file{/bin/rm})です.
 1400: 
 1401: 残りの@var{mode-args}は削除プログラムに対する(`-'で始まる)フラグ,または
 1402: 削除するファイル名です.
 1403: 
 1404: 
 1405: @node Integrating libtool
 1406: @chapter パッケージとlibtoolの統合
 1407: 
 1408: この章は,ユーザが混乱せずに共有ライブラリをインストールできるように,パッ
 1409: ケージとlibtoolの統合方法を記述します.
 1410: 
 1411: @menu
 1412: * Makefile rules::              Writing @file{Makefile} rules for libtool.
 1413: * Using Automake::              Automatically supporting libtool.
 1414: * Configuring::                 Configuring libtool for a host system.
 1415: * Distributing::                What files to distribute with your package.
 1416: * Static-only libraries::       Sometimes shared libraries are just a pain.
 1417: @end menu
 1418: 
 1419: @node Makefile rules
 1420: @section libtoolに対する@file{Makefile}規則を書く
 1421: @cindex Makefile
 1422: @cindex Makefile.am
 1423: @cindex Makefile.in
 1424: 
 1425: libtoolは,完全にAutomake(@pxref{Top,, Introduction, automake, The
 1426: Automake Manual})と統合されていて,それはAutomake version 1.2から開始さ
 1427: れています.
 1428: 
 1429: 通常の@file{Makefile}(や@file{Makefile.in})で,libtoolを使用したい場合は,
 1430: 独自のものとなります.Automake 1.2を使用せず,パッケージにlibtoolの組み
 1431: 込み方を知らない場合,以下の一つが必要になります.
 1432: 
 1433: @enumerate 1
 1434: @item
 1435: Automake(バージョン1.2以降)を近くのGNUのミラーからダウンロードし,インス
 1436: トールし,その使用を開始してください.
 1437: 
 1438: @item
 1439: @file{Makefile}規則の手での書き方を学んでください.複雑なときもあります
 1440: が,古いライブラリをコンパイルするための規則を書けるぐらいの知識がある場
 1441: 合,libtoolライブラリに対する新しい規則の理解は可能でしょう(ヒント:
 1442: libtool 配布物の@file{demo}サブディレクトリの@file{Makefile.in}を調べて
 1443: ください@dots{} 特に,それがAutomakeによって@file{Makefile.am}から自動的
 1444: に生成されたことに注意してください).
 1445: @end enumerate
 1446: 
 1447: 
 1448: @node Using Automake
 1449: @section libtoolと共にAutomakeを使用する
 1450: 
 1451: @vindex LTLIBRARIES
 1452: libtoolライブラリのサポートは,@samp{LTLIBRARIES}プライマリの下で実装さ
 1453: れています.
 1454: 
 1455: libtool配布物の@file{demo}サブディレクトリの,Automake
 1456: @file{Makefile.am}からの例は,以下のようになっています.
 1457: 
 1458: 最初に,プログラムをlibtoolライブラリとリンクするため,
 1459: @samp{program_LDADD}変数のみを使用してください.
 1460: 
 1461: @example
 1462: bin_PROGRAMS = hell hell.debug
 1463: 
 1464: # Build hell from main.c and libhello.la
 1465: hell_SOURCES = main.c
 1466: hell_LDADD = libhello.la
 1467: 
 1468: # Create an easier-to-debug version of hell.
 1469: hell_debug_SOURCES = main.c
 1470: hell_debug_LDADD = libhello.la
 1471: hell_debug_LDFLAGS = -static
 1472: @end example
 1473: 
 1474: フラグ@samp{-dlopen}と@samp{-dlpreopen}(@pxref{Link mode})は,
 1475: @var{program_LDADD}変数で,より適切になります.残念ながら,リリース1.4ま
 1476: でのGNU automakeは,@var{program_LDADD}変数でこれらのフラグを受け入れな
 1477: いため,以下で代用します.
 1478: 
 1479: @itemize @bullet
 1480: @item
 1481: それらを@var{program_LDFLAGS}に加え,@var{program_DEPENDENCIES}にライブ
 1482: ラリをリストアップし,それらが属するこれらのフラグを受け入れるGNU
 1483: automakeのリリースを待ってください.
 1484: 
 1485: @item
 1486: フラグの回りを引用符で囲みます,しかし,@var{program_DEPENDENCIES}も設定
 1487: する必要があります.
 1488: 
 1489: @example
 1490: program_LDADD = "-dlopen" libfoo.la
 1491: program_DEPENDENCIES = libfoo.la
 1492: @end example
 1493: 
 1494: @item
 1495: @file{configure.in}の@samp{AC_SUBST}で,変数@var{DLOPEN}と
 1496: @var{DLPREOPEN}を設定し,@samp{program_LDADD}での明確なフラグ
 1497: @samp{-dlopen}と@samp{-dlpreopen}に対する置換物として,@samp{@@DLOPEN@@} 
 1498: と@samp{@@DLPREOPEN@@}を使用します.Automakeは,依存性から
 1499: @samp{AC_SUBST}された変数を捨てるので,@samp{program_LDADD}のこれらのフ
 1500: ラグを受け入れたとき,それは正確に期待したように動作します.
 1501: @end itemize
 1502: 
 1503: (インストールされていない共有libtoolライブラリとのリンクを避けるため
 1504: @samp{-static}を使用するような)@samp{program}をリンクしている間,libtool
 1505: に渡したいあらゆるフラグを詰め込むため,@samp{program_LDFLAGS}変数を使用
 1506: することも可能です.
 1507: 
 1508: libtoolライブラリをビルドすることは,ほとんど冒険です@dots{}
 1509: @samp{-version-info}(@pxref{Versioning})オプションをlibtoolに渡すため,
 1510: @samp{libhello_la_LDFLAGS}を使用することに注意してください.
 1511: 
 1512: @example
 1513: # Build a libtool library, libhello.la for installation in libdir.
 1514: lib_LTLIBRARIES = libhello.la
 1515: libhello_la_SOURCES = hello.c foo.c
 1516: libhello_la_LDFLAGS = -version-info 3:12:1
 1517: @end example
 1518: 
 1519: @samp{-rpath}オプションは,(@code{noinst_LTLIBRARIES}としてリストアップ
 1520: されるライブラリ以外)Automakeにより自動的に渡されるので,指定する必要は
 1521: ありません.
 1522: 
 1523: 詳細は,@xref{A Shared Library, Building a Shared Library, The Automake
 1524: Manual, automake, The Automake Manual}.
 1525: 
 1526: 
 1527: @node Configuring
 1528: @section libtoolのコンフィグレーション
 1529: @cindex configuring libtool
 1530: 
 1531: libtoolは,共有ライブラリを作成し適切なものにリンクするため,コンパイラセット
 1532: とオペレーティングシステムの詳細な知識を必要とします.libtool配布物をイ
 1533: ンストールするとき,システム特有のlibtoolスクリプトはバイナリディレクト
 1534: リにインストールされます.
 1535: 
 1536: しかし,独自のパッケージとともにlibtoolを配布するとき
 1537: (@pxref{Distributing}),パッケージをコンパイルするために使用されるコンパ
 1538: イラセットとオペレーティングシステムを,常に知っているわけではありません.
 1539: 
 1540: このため,libtoolを使用する前に@dfn{コンフィグレーション}する必要があり
 1541: ます.この考えは,GNU @code{configure}スクリプトを使用するものに似ていま
 1542: す.@code{configure}は,システムの特徴に対しいくつものテストを行い,
 1543: @file{Makefiles}(と,おそらく@file{config.h}ヘッダファイル)を生成し,そ
 1544: の後,@code{make}を実行しパケージをビルドすることが可能です.
 1545: 
 1546: libtoolは,インストーラのホストマシンに対するlibtoolスクリプトを生成する
 1547: ために,独自のテストを@code{configure}スクリプトに加えます.
 1548: 
 1549: @menu
 1550: * AC_PROG_LIBTOOL::             Configuring @code{libtool} in @file{configure.in}.
 1551: @end menu
 1552: 
 1553: @node AC_PROG_LIBTOOL
 1554: @subsection @code{AC_PROG_LIBTOOL}マクロ
 1555: 
 1556: GNU Autoconf(やAutomake)を使用している場合,@code{AC_PROG_LIBTOOL}の呼び
 1557: 出しを@file{configure.in}に加える必要があります.このマクロは,
 1558: 生成されたlibtoolスクリプトがホストの特徴を理解できるようにするため,
 1559: 多くの新しいテストを@code{configure}スクリプトに加えます.
 1560: 
 1561: @defmac AC_PROG_LIBTOOL
 1562: @defmacx AM_PROG_LIBTOOL
 1563: @samp{--enable-shared}と@samp{--disable-shared}の@code{configure}フラグ
 1564: に対するサポートを加えます.@footnote{@code{AC_PROG_LIBTOOL}は,
 1565: @file{Makefile.in}での@file{Makefile}変数の@code{top_builddir}の定義を要
 1566: 求します.Automakeはこれを自動的に行いますが,Autoconfユーザは,ビルドディ
 1567: レクトリのトップへの相対パス(例えば,@file{../..})を設定する必要がありま
 1568: す.} @code{AM_PROG_LIBTOOL}は,このマクロに対する古い名前で,しばらくは
 1569: サポートされますが,やめた方がいいでしょう.
 1570: 
 1571: デフォルトで,このマクロは,利用可能な場合は共有ライブラリを開始し,共有
 1572: ライブラリと衝突しない場合はスタティックライブラリも可能とします.これら
 1573: のデフォルトは,@code{AC_DISABLE_SHARED}や@code{AC_DISABLE_STATIC}マクロ
 1574: のどちらかで修正可能です.
 1575: 
 1576: @example
 1577: # Turn off shared libraries during beta-testing, since they
 1578: # make the build process take too long.
 1579: AC_DISABLE_SHARED
 1580: AC_PROG_LIBTOOL
 1581: @end example
 1582: 
 1583: ユーザは,パッケージ名を元にビルドされる,共有またはスタティックライブラ
 1584: リを選択するため,@samp{--enable-shared}と@samp{--enable-static}コンフィ
 1585: グレーションフラグで指定を修正できます.例えば,共有する@samp{bfd}と
 1586: @samp{gdb}ライブラリをビルドし,@samp{libg++}を共有にしないため,以下の
 1587: @code{configure}スクリプトの実行で,3つのことのすべて可能となります.
 1588: 
 1589: @example
 1590: trick$ ./configure --enable-shared=bfd,gdb
 1591: @end example
 1592: 
 1593: 一般的に,@samp{--enable-shared=@var{pkgs}}の指定は,カンマで分けられた
 1594: @var{pkgs}リストに名前があるすべてのパッケージを@samp{--enable-shared}で,
 1595: それ以外のすべてのパッケージを@samp{--disable-shared}でコンフィグレーショ
 1596: ンすること同じです.@samp{--enable-static=@var{pkgs}}フラグは,同様に動
 1597: 作しますが,その場合は@samp{--enable-static}と@samp{--disable-static}を
 1598: 使用します.同様に,@samp{--enable-fast-install=@var{pkgs}}フラグは適用
 1599: され,それは,@samp{--enable-fast-install}と
 1600: @samp{--disable-fast-install}を使用します.
 1601: 
 1602: パッケージ名@samp{default}は,@code{PACKAGE}環境変数に名前が設定されてい
 1603: ない,あらゆるパッケージに一致します.
 1604: 
 1605: このマクロは,シェル変数@var{LIBTOOL_DEPS}も設定し,それで,libtoolスク
 1606: リプトが時代遅れになった場合の自動的な更新に使用できるようになります.そ
 1607: うするために@file{configure.in}に以下を加えてください.
 1608: 
 1609: @example
 1610: AC_PROG_LIBTOOL
 1611: AC_SUBST(LIBTOOL_DEPS)
 1612: @end example
 1613: 
 1614: そして,@file{Makefile.in}や@file{Makefile.am}に,以下を加えてください.
 1615: 
 1616: @example
 1617: LIBTOOL_DEPS = @@LIBTOOL_DEPS@@
 1618: libtool: $(LIBTOOL_DEPS)
 1619:         $(SHELL) ./config.status --recheck
 1620: @end example
 1621: 
 1622: GNU automakeを使用してる場合,automakeが面倒をみるので,指示の省略が可能
 1623: です.@file{libtool}での依存性を明確に作成する必要があります.
 1624: 
 1625: @end defmac
 1626: 
 1627: @defmac AC_LIBTOOL_DLOPEN
 1628: dlopenサポートの調査を可能にします.パッケージで@samp{-dlopen}と
 1629: @samp{-dlpreopen}フラグを使用する場合,このマクロ使用すべきで,そうしな
 1630: い場合,libtoolはシステムがdlopenをサポートしていないと仮定します.マク
 1631: ロは@code{AC_PROG_LIBTOOL}の@strong{前で}呼び出す必要があります.
 1632: @end defmac
 1633: 
 1634: @defmac AC_LIBTOOL_WIN32_DLL
 1635: このマクロは,win32プラットフォームでクリーンなdllをビルドするために移植
 1636: する場合,使用する必要があります.通常,これは,あらゆるライブラリデータ
 1637: 項目を@code{__declspec(dllexport)}でエクスポートし,
 1638: @code{__declspec(dllimport)}でインポートすることを意味します.このマクロ
 1639: が使用されていない場合,libtoolはパッケージライブラリがクリーンなdllでは
 1640: なく,win32ホストでのスタティックライブラリのみをビルドすると仮定します.
 1641: 
 1642: このマクロは@code{AC_PROG_LIBTOOL}の@strong{前で}呼び出す必要があり,パッ
 1643: ケージの@code{Makefile}でのリンクモードでの準備として,@code{libtool}に
 1644: @samp{-no-undefined}を渡させる必要があります.通常,@samp{-no-undefined} 
 1645: を渡す場合,すべてのライブラリシンボルが,リンク時には@strong{本当に}定
 1646: 義されていることを確かめる必要があります!
 1647: @end defmac
 1648: 
 1649: @defmac AC_DISABLE_FAST_INSTALL
 1650: @code{AC_PROG_LIBTOOL}のデフォルトの動作を,高速インストールに対する最適
 1651: 化を不可能にするよう変更します.ユーザはこのデフォルトを,プラットフォー
 1652: ムのサポートに依存して,@samp{--enable-fast-install}を指定することで優先
 1653: させることができます.
 1654: @end defmac
 1655: 
 1656: @defmac AC_DISABLE_SHARED
 1657: @defmacx AM_DISABLE_SHARED
 1658: @code{AC_PROG_LIBTOOL}のデフォルトの動作を,共有ライブラリを利用不可能に
 1659: 変更します.ユーザはこのデフォルトを,@samp{--enable-shared}を指定するこ
 1660: とで優先させることができます.
 1661: @end defmac
 1662: 
 1663: @defmac AC_DISABLE_STATIC
 1664: @defmacx AM_DISABLE_STATIC
 1665: @code{AC_PROG_LIBTOOL}のデフォルトの動作を,スタティックライブラリを利用
 1666: 不可能に変更します.ユーザはこのデフォルトを,@samp{--enable-static}を指
 1667: 定することで優先させることができます.
 1668: @end defmac
 1669: 
 1670: @code{AC_PROG_LIBTOOL}内のテストは,以下の環境変数も認識します.
 1671: 
 1672: @defvar CC
 1673: 生成された@code{libtool}が使用するCコンパイラです.これが設定されていな
 1674: い場合,@code{AC_PROG_LIBTOOL}は@code{gcc}や@code{cc}を探します.
 1675: @end defvar
 1676: 
 1677: @defvar CFLAGS
 1678: 標準的なオブジェクトファイルを生成するために使用するコンパイラフラグです.
 1679: これが設定されていない場合,@code{AC_PROG_LIBTOOL}はそのようなフラグを全
 1680: く使用しません.それは,@code{AC_PROG_LIBTOOL}がテストを実行する方法にの
 1681: み効果があり,生成された@code{libtool}には効果はありません.
 1682: @end defvar
 1683: 
 1684: @defvar CPPFLAGS
 1685: Cプリプロセッサフラグです.これが設定されていない場合,
 1686: @code{AC_PROG_LIBTOOL}はそのようなフラグを全く使用しません.それは,
 1687: @code{AC_PROG_LIBTOOL}がテストを実行する方法にのみ効果があり,生成された
 1688: @code{libtool}には効果はありません.
 1689: @end defvar
 1690: 
 1691: @defvar LD
 1692: (生成された@code{libtool}が要求する場合は)システムリンカです.これが設定
 1693: されていない場合,@code{AC_PROG_LIBTOOL}は,@var{CC}で使用されるリンカが
 1694: 何かを判別しようとします.
 1695: @end defvar
 1696: 
 1697: @defvar LDFLAGS
 1698: プログラムをリンクするとき,@code{libtool}が使用するフラグです.これが設
 1699: 定されていない場合,@code{AC_PROG_LIBTOOL}はそのようなフラグを全く使用し
 1700: ません.それは,@code{AC_PROG_LIBTOOL}がテストを実行する方法にのみ効果が
 1701: あり,生成された@code{libtool}には効果はありません.
 1702: @end defvar
 1703: 
 1704: @defvar LIBS
 1705: プログラムのリンクとき,@code{AC_PROG_LIBTOOL}が使用するライブラリです.
 1706: これが設定されていない場合,@code{AC_PROG_LIBTOOL}はそのようなフラグを使
 1707: 用しません.それは@code{AC_PROG_LIBTOOL}が実行するテストにのみに効果があ
 1708: り,生成された@code{libtool}には効果はありません.
 1709: @end defvar
 1710: 
 1711: @defvar NM
 1712: 使用するプログラムで,@code{nm}の調査ではありません.
 1713: @end defvar
 1714: 
 1715: @defvar RANLIB
 1716: 使用するプログラムで,@code{ranlib}の調査ではありません.
 1717: @end defvar
 1718: 
 1719: @defvar LN_S
 1720: プログラムのリンクを作成するコマンドで,可能な場合はソフトリンク,それ以
 1721: 外ではハードリンクです.この変数が設定されていない場合,
 1722: @code{AC_PROG_LIBTOOL}は適切なプログラムを調査します.
 1723: @end defvar
 1724: 
 1725: @defvar DLLTOOL
 1726: 使用するプログラムで,@code{dlltool}の調査ではありません.
 1727: Cygwin/MS-Windowsでのみ意味があります.
 1728: @end defvar
 1729: 
 1730: @defvar OBJDUMP
 1731: 使用するプログラムで,@code{objdump}の調査ではありません.
 1732: Cygwin/MS-Windowsでのみ意味があります.
 1733: @end defvar
 1734: 
 1735: @defvar AS
 1736: 使用するプログラムで,@code{as}の調査ではありません.しばらくは,
 1737: Cygwin/MS-Windows でのみ使用されます.
 1738: @end defvar
 1739: 
 1740: @pindex aclocal
 1741: @code{libtoolize}プログラムを呼び出すとき(@pxref{Invoking libtoolize}),
 1742: それは@code{AC_PROG_LIBTOOL}の定義が見つかる場所を伝えます.Automakeを使
 1743: 用している場合,@code{aclocal}プログラムは自動的に,@code{configure}スク
 1744: リプトに@code{AC_PROG_LIBTOOL}サポートを@code{configure}スクリプトに加え
 1745: ます.
 1746: 
 1747: それにもかかわらず,@file{acinclude.m4}に@file{libtool.m4}のコピーを含め
 1748: ることは賢明で,そのため,@file{aclocal.m4}と@file{configure}がとある理
 1749: 由で再びビルドされた場合も,適切なlibtoolマクロが使用されます.代わりに,
 1750: ユーザが@file{libtool.m4}の互換バージョンをインストールしていて,
 1751: @code{aclocal}にアクセス可能なことを期待します.これは,バージョンが一致
 1752: しない場合,不運なエラーを導くかもしれません.
 1753: 
 1754: 
 1755: @node Distributing
 1756: @section パッケージにlibtoolを含める
 1757: 
 1758: libtoolを使用するため,パッケージに以下のファイルを含める必要があります.
 1759: 
 1760: @table @file
 1761: @item config.guess
 1762: @pindex config.guess
 1763: 標準的なシステム名の判別を試みます.
 1764: 
 1765: @item config.sub
 1766: @pindex config.sub
 1767: 標準的なシステム名を評価する,サブルーチンスクリプトです.
 1768: 
 1769: @item ltmain.sh
 1770: @pindex ltmain.sh
 1771: 基本的なlibtool機能を実装する一般的なスクリプトです.
 1772: @end table
 1773: 
 1774: libtoolスクリプト自身はパッケージに含まれないことに注意してください.
 1775: @xref{Configuring}.
 1776: 
 1777: 手動でこれらのファイルをパッケージにコピーするより,@code{libtoolize}プ
 1778: ログラムを使用した方がよいでしょう.
 1779: 
 1780: @menu
 1781: * Invoking libtoolize::         @code{libtoolize} command line options.
 1782: * Autoconf .o macros::          Autoconf macros that set object file names.
 1783: @end menu
 1784: 
 1785: @node Invoking libtoolize
 1786: @subsection @code{libtoolize}の呼び出し
 1787: @pindex libtoolize
 1788: @cindex libtoolize command options
 1789: @cindex command options, libtoolize
 1790: @cindex options, libtoolize command
 1791: 
 1792: @code{libtoolize}プログラムは,libtoolサポートをパッケージに追加する標準
 1793: 的な方法を提供します.将来は,より良い調査の使用法や,より簡単にlibtool 
 1794: を作成する特徴を実装するかもしれません.
 1795: 
 1796: @code{libtoolize}プログラムは以下の構文です.
 1797: 
 1798: @example
 1799: libtoolize [@var{option}]@dots{}
 1800: @end example
 1801: 
 1802: @noindent
 1803: そして,以下のオプションを受け入れます.
 1804: 
 1805: @table @samp
 1806: @item --automake
 1807: 静かに動作し,libtoolがサポートされているAutomakeを仮定します.
 1808: 
 1809: @samp{libtoolize --automake}は,@code{AC_PROG_LIBTOOL}が
 1810: @file{configure.in}にあるとき,Automakeがlibtoolファイルをパッケージに追
 1811: 加するために使用します.
 1812: 
 1813: @item --copy
 1814: @itemx -c
 1815: libtoolデータディレクトリから,シンボリックリンクを作成するのではなく,
 1816: ファイルをコピーします.
 1817: 
 1818: @item --debug
 1819: シェルスクリプトの実行の追跡を,標準出力にダンプします.これは大量の出力
 1820: を生成するため,@code{less}(や@code{more})にパイプしたり,ファイルにリダ
 1821: イレクトしたいかもしれません.
 1822: 
 1823: @item --dry-run
 1824: @itemx -n
 1825: ファイルシステムを変更するコマンドは実行せず,それらを出力するだけです.
 1826: 
 1827: @item --force
 1828: @itemx -f
 1829: 既存のlibtoolのファイルを置換します.デフォルトで,@code{libtoolize}は既
 1830: 存のファイルを上書きしません.
 1831: 
 1832: @item --help
 1833: へルプメッセージを出力し終了します.
 1834: 
 1835: @item --ltdl
 1836: パッケージのサブディレクトリに,libltdlをインストールします.
 1837: 
 1838: @item --ltdl-tar
 1839: ファイルlibltdl.tar.gzをパッケージに追加します.
 1840: 
 1841: @item --version
 1842: @code{libtoolize}のバージョン情報を出力し終了します.
 1843: @end table
 1844: 
 1845: @findex AC_CONFIG_AUX_DIR
 1846: @code{libtoolize}が,パッケージの@file{configure.in}で,明確な
 1847: @code{AC_CONFIG_AUX_DIR}の呼び出しを検出した場合(@pxref{Input, , The
 1848: Autoconf Manual, autoconf, The Autoconf Manual}),指定されたディレクトリ
 1849: にファイルを配置します.
 1850: 
 1851: @code{libtoolize}は,パッケージにlibtoolサポートを加えるヒントも同様に表
 1852: 示します.
 1853: 
 1854: 
 1855: @node Autoconf .o macros
 1856: @subsection Autoconfの@samp{.o}マクロ
 1857: 
 1858: utoconfパッケージは,テストを実行するいくつかのマクロをもたらし,それは,
 1859: オブジェクトファイル名に対応して変数を設定します.libtoolオブジェクトに
 1860: 対応する名前を使用する必要があるときもあります.
 1861: 
 1862: ここにlibtoolオブジェクトがリストアップする変数名があります.
 1863: 
 1864: @defvar LTALLOCA
 1865: @findex AC_FUNC_ALLOCA
 1866: @code{AC_FUNC_ALLOCA}で置換されます(@pxref{Particular Functions,
 1867: Particular Function Checks, The Autoconf Manual, autoconf, The Autoconf
 1868: Manual}).空,または@samp{alloca.lo}を含みます.
 1869: @end defvar
 1870: 
 1871: @defvar LTLIBOBJS
 1872: @findex AC_REPLACE_FUNCS
 1873: @code{AC_REPLACE_FUNCS}(@pxref{Generic Functions, Generic Function
 1874: Checks, The Autoconf Manual, autoconf, The Autoconf Manual})とその他の関
 1875: 数で置換されます.
 1876: @end defvar
 1877: 
 1878: 残念ながら,安定版のリリースのAutoconf(これを書いている時期は,2.13)は,
 1879: libtoolでこれらの変数を提供する方法が全くありません.そのため,それに依
 1880: 存して,パッケージの@file{configure.in}で@code{AC_OUTPUT}を呼び出す前に,
 1881: 以下のコードの実装を使用してください.
 1882: 
 1883: @example
 1884: LTLIBOBJS=`echo "$LIBOBJS" | sed 's/\.[^.]* /.lo /g;s/\.[^.]*$/.lo/'`
 1885: AC_SUBST(LTLIBOBJS)
 1886: LTALLOCA=`echo "$ALLOCA" | sed 's/\.[^.]* /.lo /g;s/\.[^.]*$/.lo/'`
 1887: AC_SUBST(LTALLOCA)
 1888: AC_OUTPUT(@dots{})
 1889: @end example
 1890: 
 1891: 
 1892: @node Static-only libraries
 1893: @section スタティックのみのライブラリ
 1894: @cindex debugging libraries
 1895: @cindex developing libraries
 1896: @cindex double-compilation, avoiding
 1897: @cindex avoiding shared libraries
 1898: @cindex eliding shared libraries
 1899: @cindex using shared libraries, not
 1900: @cindex shared libraries, not using
 1901: @cindex time, saving
 1902: @cindex saving time
 1903: 
 1904: パッケージを開発しているとき,パッケージを@samp{--disable-shared}フラグ
 1905: でコンフィグレーションしたり,@code{AC_DISABLE_SHARED} Autoconfマクロ
 1906: (@pxref{AC_PROG_LIBTOOL, , The @code{AC_PROG_LIBTOOL} macro})を使用して,
 1907: @code{AC_PROG_LIBTOOL}のデフォルトに優先することに価値があることもよくあ
 1908: ります.これは,libtoolが共有ライブラリをビルドすることを避け,それには,
 1909: いくつかの利点があります.
 1910: 
 1911: @itemize @bullet
 1912: @item
 1913: 2回目のコンパイルを速くし,開発サイクルを高速にします.
 1914: 
 1915: @item
 1916: 共有ライブラリによって加えられる複雑さの詳細が不要なので,デバッグがより
 1917: 簡単になります.
 1918: 
 1919: @item
 1920: スタティックのみのプラットフォームでのlibtoolの動作方法が分かります.
 1921: @end itemize
 1922: 
 1923: パッケージの@file{README}に,他の開発者に@samp{--disable-shared}で時間を
 1924: 稼げることを知らせるため,ちょっとした注意を書きたいかもしれません.以下
 1925: の例の注意は,GIMP@footnote{思い切りがよくない人のためのGNU Image
 1926: Manipulation Programです.@url{http://www.gimp.org/}を参照してください.} 
 1927: 配布物の@file{README}から持ってきました.
 1928: 
 1929: @example
 1930: The GIMP uses GNU Libtool in order to build shared libraries on a
 1931: variety of systems. While this is very nice for making usable
 1932: binaries, it can be a pain when trying to debug a program. For that
 1933: reason, compilation of shared libraries can be turned off by
 1934: specifying the @samp{--disable-shared} option to @file{configure}.
 1935: @end example
 1936: 
 1937: 
 1938: @node Versioning
 1939: @chapter ライブラリインターフェースのバージョン
 1940: @cindex dynamic dependencies
 1941: @cindex dependency versioning
 1942: @cindex shared library versions
 1943: 
 1944: 共有ライブラリで導入された発行物で,最も難しいものは,実行時の依存性の作
 1945: 成と解決です.プログラムとライブラリの依存性は,@code{sed}のような単一の
 1946: 名前の用語で,よく記述されます.そのため``libtoolはsedに依存する''と告げ,
 1947: それで十分目的を果たせます.
 1948: 
 1949: しかし,規則的にインターフェースが変更されるとき,我々はより具体的に告げ
 1950: る必要があります.``Gnus 5.1はEmacs 19.28以上を要求する.''ここでは,名
 1951: 前からなるインターフェースの記述と``バージョンナンバー''です.
 1952: 
 1953: 種類の説明はいくつかの目的において十分でないことすらあります.Emacs 20で
 1954: 変更された場合,Gnus 5.1を破壊するのに十分ではないでしょうか?
 1955: 
 1956: 同じ問題は,共有ライブラリでも存在します.我々は,プログラムが必要として
 1957: いるインターフェースを提供するライブラリのみとリンクされることを,ダイナ
 1958: ミックリンカが保証できるように,プログラムが依存する共有ライブラリを記述
 1959: するために,公式なバージョン管理システムが必要です.
 1960: 
 1961: @menu
 1962: * Interfaces::                  What are library interfaces?
 1963: * Libtool versioning::          Libtool's versioning system.
 1964: * Updating version info::       Changing version information before releases.
 1965: * Release numbers::             Breaking binary compatibility for aesthetics.
 1966: @end menu
 1967: 
 1968: @node Interfaces
 1969: @section ライブラリインターフェースとは?
 1970: @cindex library interfaces
 1971: 
 1972: ライブラリのインターフェースは,以下の何か(またはそれ以上)でしょう.
 1973: 
 1974: @itemize @bullet
 1975: @item
 1976: グローバル変数: 名前と型
 1977: 
 1978: @item
 1979: グローバル関数: 引数の型と数,戻り値の型,関数名
 1980: 
 1981: @item
 1982: 標準入力,標準出力,標準エラー,ファイル形式
 1983: 
 1984: @item
 1985: ソケット,パイプ,プロセス間通信のプロトコル書式
 1986: @end itemize
 1987: 
 1988: スタティック関数は,ライブラリのユーザが直接利用不可能なので,インター
 1989: フェースに数えられないことに注意してください.
 1990: 
 1991: 
 1992: @node Libtool versioning
 1993: @section libtoolのバージョン管理システム
 1994: @cindex libtool library versions
 1995: @cindex formal versioning
 1996: @cindex versioning, formal
 1997: 
 1998: libtoolは独自の公式のバージョン管理システムがあります.それは,あまり柔
 1999: 軟ではありませんが,強力なバージョン管理システムで,確かに最も単純です.
 2000: 
 2001: ライブラリとは,整数で任意に表示できるインターフェースのいくつかの組を
 2002: エクスポートするものだと考えて下さい.プログラムがライブラリとリンクされ
 2003: るとき,これらのインターフェースのサブセットを利用するかもしれません.
 2004: 
 2005: プログラムが使用するインターフェースのlibtoolの記述は単純です.それは,
 2006: 結果のバイナリにある最大と最小のインターフェースの番号を符号化します
 2007: (@var{first-interface}, @var{last-interface}).
 2008: 
 2009: ダイナミックリンカは,ライブラリが@var{first-interface}と
 2010: @var{last-interface}の間の@emph{すべての}インターフェースの番号をサポー
 2011: トする場合,プログラムがライブラリとリンク可能なことを保証します.
 2012: 
 2013: libtoolの移植性の要求が,実際に必要と言うよりは厳密なので,問題を生じる
 2014: 可能性があることに注意してください.
 2015: 
 2016: さて,@file{libhello}がインターフェースの5,16,17,18,と19をサポートし,
 2017: libtoolは@file{libhello}を@file{test}にリンクするとき使用されると仮定し
 2018: ます.
 2019: 
 2020: libtoolは@file{test}に数字5と19を符号化し,ダイナミックリンカは,5と19の
 2021: 間の@emph{すべての}インターフェースをサポートしているライブラリのみと,
 2022: @file{test}をリンクします.そのため,ダイナミックリンカは@file{libhello} 
 2023: と@file{test}をリンクすることを拒否するのです!
 2024: 
 2025: この問題を排除するために,libtoolはライブラリは,連続したインターフェー
 2026: ス番号を宣言することのみ可能としています.そのため,@file{libhello}は,
 2027: 16 から19までのインターフェースをサポートすることを宣言するのが精一杯で
 2028: す.そして,ダイナミックリンカは,@file{libhello}を@file{test}とリンクし
 2029: ます.
 2030: 
 2031: そのため,libtoolライブラリバージョンは,3つの整数で宣言されます.
 2032: 
 2033: @table @var
 2034: @item current
 2035: このライブラリで実装されている,最も新しいインターフェース番号.
 2036: 
 2037: @item revision
 2038: @var{current}のインターフェースの実装番号.
 2039: 
 2040: @item age
 2041: このライブラリで実装されている,最新と最古のインターフェースの違い.言い
 2042: 換えると,ライブラリは,@code{@var{current} - @var{age}}から
 2043: @code{@var{current}}までの番号の範囲で,すべてのインターフェース番号を実
 2044: 装しています.
 2045: @end table
 2046: 
 2047: 2つのライブラリが,個別の@var{current}と@var{age}を持つ場合,ダイナミッ
 2048: クリンカは,より大きい@var{revision}番号を選択します.
 2049: 
 2050: 
 2051: @node Updating version info
 2052: @section ライブラリバージョン情報の更新
 2053: 
 2054: libtoolのバージョン管理システムを使用したい場合,リンクモード
 2055: (@pxref{Link mode})の時に,@samp{-version-info}フラグを使用して,libtool
 2056: にバージョン情報を指定する必要があります.
 2057: 
 2058: このフラグは,@samp{@var{current}[:@var{revision}[:@var{age}]]}の形式の
 2059: 引数を受け入れます.そして,@samp{-version-info 3:12:1}を渡すと,
 2060: @var{current}を3,@var{revision}を12,そして@var{age}を1に設定します.
 2061: 
 2062: @var{revision}や@var{age}が省略された場合,デフォルトは0になります.また,
 2063: @var{age}は@var{current}インターフェース番号以下にする必要があることに注
 2064: 意してください.
 2065: 
 2066: ライブラリバージョン情報を更新する助けとなる規則の集合は,以下のようにな
 2067: ります.
 2068: 
 2069: @enumerate 1
 2070: @item
 2071: バージョン情報は,それぞれのlibtoolライブラリに対し@samp{0:0:0}で始めて
 2072: ください.
 2073: 
 2074: @item
 2075: ソフトウェアの一般へのリリースの直前にのみ,バージョン情報を更新してくだ
 2076: さい.より頻繁な更新は不要で,現在のインターフェース番号が速くなることを
 2077: 保証するだけです.
 2078: 
 2079: @item
 2080: 前回の更新から,ライブラリソースコードが完全に変更された場合,
 2081: @var{revision}を増加してください(@samp{@var{c}:@var{r}:@var{a}}は
 2082: @samp{@var{c}:@math{r+1}:@var{a}}となります).
 2083: 
 2084: @item
 2085: 前回の更新から,インターフェースが加えられた,削除された,または変更され
 2086: た場合,@var{current}を増加し,@var{revision}を0に設定してください.
 2087: 
 2088: @item
 2089: 前回の一般へのリリースから,あるインターフェースが削除された場合,
 2090: @var{age}を0に設定してください.
 2091: 
 2092: @item
 2093: 前回の一般へのリリースから,あるインターフェースが削除された場合,
 2094: @var{age}を0に設定してください.
 2095: @end enumerate
 2096: 
 2097: パッケージのリリース番号に対応するように,インターフェース番号を設定する
 2098: 試みは@strong{@emph{決して}}しないでください.これは,ライブラリバージョ
 2099: ンの目的の誤解を促進する悪習にすぎません.その代わり,@samp{-release}
 2100: フラグ(@pxref{Release numbers})を使用しますが,パッケージが他のリリース
 2101: とバイナリ互換でないことを警告されます.
 2102: 
 2103: 
 2104: @node Release numbers
 2105: @section リリース情報の管理
 2106: 
 2107: プログラムをライブラリにリンクしたいユーザに明確になるように,パッケージ
 2108: リリース名を共有ライブラリに符号化したいこともよくあります.この便利さは,
 2109: 特にGNU/Linuxで使用されます.
 2110: 
 2111: @example
 2112: trick$ @kbd{ls /usr/lib/libbfd*}
 2113: /usr/lib/libbfd.a	    /usr/lib/libbfd.so.2.7.0.2
 2114: /usr/lib/libbfd.so
 2115: trick$
 2116: @end example
 2117: 
 2118: @samp{trick}として,@file{/usr/lib/libbfd.so}は@file{libbfd.so.2.7.0.2} 
 2119: へのシンボリックリンクで,それは@samp{binutils-2.7.0.2}の一部として配布
 2120: されています.
 2121: 
 2122: ライブラリインターフェースは,リリース番号のように,滅多に同時に変更され
 2123: す,ライブラリ接尾子はすべてのプラットフォームを跨り,すべて同じではない
 2124: ので,残念ながらこの便利さはlibtoolのライブラリバージョンの情報の考えと
 2125: 直接衝突します.
 2126: 
 2127: そのため,両方の見方に適応するため,@samp{-version-info}を使用したくない
 2128: ライブラリに対し,リリース情報を設定するにあたり,@samp{-release}フラグ
 2129: を使用することができます.@file{libbfd}の例では,libtoolが使用する次のリ
 2130: リースは,@samp{-release 2.9.0}でビルドされるべきで,それは,GNU/Linuxで,
 2131: 以下のファイルを生成します.
 2132: 
 2133: @example
 2134: trick$ @kbd{ls /usr/lib/libbfd*}
 2135: /usr/lib/libbfd-2.9.0.so     /usr/lib/libbfd.a
 2136: /usr/lib/libbfd.so
 2137: trick$
 2138: @end example
 2139: 
 2140: この場合,@file{/usr/lib/libbfd.so}は@file{libbfd-2.9.0.so}へのシンボリッ
 2141: クリンクです.これは@samp{binutils-2.9.0}を扱っているユーザにとって,バー
 2142: ジョン情報のlibtoolの考えに妥協することなく,明白になります.
 2143: 
 2144: このオプションはライブラリ名を編集することに注意し,過去のライブラリリリー
 2145: スとのバイナリ互換を壊したくない場合は使用しないでください.一般的に,パッ
 2146: ケージの内部ライブラリや,大変頻繁に変更されるインターフェースを持つ物に
 2147: 対してのみ@samp{-release}を使用してください.
 2148: 
 2149: 
 2150: @node Library tips
 2151: @chapter インターフェース設計に対する助言
 2152: @cindex library interfaces, design
 2153: @cindex design of library interfaces
 2154: 
 2155: 良いライブラリインターフェースと書くことは,多くの経験とライブラリが解決
 2156: する問題への完全な理解が必要です.
 2157: 
 2158: 良いインターフェースを設計した場合,頻繁に変更する必要がなく,ドキュメン
 2159: トを更新し続ける必要がなく,ユーザはライブラリの使用方法を何度も学習する
 2160: 必要がありません.
 2161: 
 2162: ここにライブラリインターフェースの設計に関するヒントの短いリストがあり,
 2163: それは仕事上で役立つでしょう.
 2164: 
 2165: @table @asis
 2166: @item 計画前
 2167: エントリポイントを頻繁に削除する必要がないように,すべてのインターフェー
 2168: スを本当に最小限にするように試みてください.
 2169: 
 2170: @item インターフェースの変更を避ける
 2171: @cindex renaming interface functions
 2172: エントリポイントの再設計と変更を地獄のように繰り返すのが好きな人もいます
 2173: (注意:関数の@emph{名前変更}はエントリポイントの変更と考えられます).イ
 2174: ンターフェースを再設計する必要がある場合,ユーザが既存のコードを書き換え
 2175: る必要がないように,互換機能を残すことを試みてください.
 2176: 
 2177: @item 不透明なデータ型の使用
 2178: @cindex opaque data types
 2179: ライブラリユーザがアクセスするデータ型の定義は,少ないければ少ないほど良
 2180: いでしょう.可能な場合,一般的な(内部データにキャスト可能な)ポインタを受
 2181: け入れる関数を設計し,ライブラリユーザが直接データを操作するのを許可する
 2182: のではなく,アクセスする関数を提供してください.そうすることで,インター
 2183: フェースを変更せずに,データ構造を変更することが自由になります.
 2184: 
 2185: これは,本質的にオブジェクト指向のシステムで抽象的なデータ型と継承を使用
 2186: するのと同じです.
 2187: 
 2188: @item ヘッダファイルの使用
 2189: @cindex header files
 2190: ライブラリのグローバル関数と変数のそれぞれのドキュメントをヘッダファイル
 2191: に注意して書いていて,ライブラリソースファイルに含めている場合,コンパイ
 2192: ラは偶然にインターフェースの変更の有無を知らせるでしょう(@pxref{C header
 2193: files}).
 2194: 
 2195: @item 可能な場所での@code{static}キーワード(またはその等価物)の使用
 2196: @cindex global functions
 2197: ライブラリが持つグローバル関数は,減らせば減らすほど,より柔軟に変更でき
 2198: ます.スタティック関数と変数は,形式を変更したいとき変更できます@dots{} 
 2199: ユーザはそれらにアクセスできず,そのためインターフェースは変更されません.
 2200: @end table
 2201: 
 2202: @menu
 2203: * C header files::              How to write portable include files.
 2204: @end menu
 2205: 
 2206: @node C header files
 2207: @section Cヘッダファイルを書く
 2208: @cindex portable C headers
 2209: @cindex C header files, portable
 2210: @cindex include files, portable
 2211: 
 2212: 移植性の高いCヘッダファイルを書くことは難しく,それは異なる形式のコンパ
 2213: イラで読まれる可能性があるためです.
 2214: 
 2215: @table @asis
 2216: @item C++コンパイラ
 2217: C++コンパイラは,Cより強固に形式化されているため,完全なプロトタイプで宣
 2218: 言された関数を要求します.C関数と変数は,名前がおかしくならないように,
 2219: @code{extern "C"}ディレクティブで宣言する必要があります.libtool でC++の
 2220: 使用に関連したその他の問題は,@xref{C++ libraries}.
 2221: 
 2222: @item ANSI Cコンパイラ
 2223: ANSI Cコンパイラは,C++コンパイラほど厳密ではありませんが,関数のプロト
 2224: タイプは,ヘッダファイルを@code{#include}したときの不必要な警告を避ける
 2225: ため,行う方が良いでしょう.
 2226: 
 2227: @item 非ANSI Cコンパイラ
 2228: Non-ANSIコンパイラは,関数がプロトタイプされている場合,エラーを報告しま
 2229: す.
 2230: @end table
 2231: 
 2232: これらの複雑さは,上記それぞれのコンパイラを利用可能にするため,ライブラ
 2233: リインファーフェースヘッダで,いくつかのCプリプロセッサの魔法を使用する
 2234: 必要があることを意味します.
 2235: 
 2236: libtool配布物の@file{demo}サブディレクトリの@file{foo.h}は,安全にシステ
 2237: ムディレクトリにインストール可能な,ヘッダファイルの書き方の例を提供しま
 2238: す.
 2239: 
 2240: そのファイルの関連する部分は,以下のようになっています.
 2241: 
 2242: @example
 2243: /* BEGIN_C_DECLS should be used at the beginning of your declarations,
 2244:    so that C++ compilers don't mangle their names.  Use END_C_DECLS at
 2245:    the end of C declarations. */
 2246: #undef BEGIN_C_DECLS
 2247: #undef END_C_DECLS
 2248: #ifdef __cplusplus
 2249: # define BEGIN_C_DECLS extern "C" @{
 2250: # define END_C_DECLS @}
 2251: #else
 2252: # define BEGIN_C_DECLS /* empty */
 2253: # define END_C_DECLS /* empty */
 2254: #endif
 2255: 
 2256: /* PARAMS is a macro used to wrap function prototypes, so that
 2257:    compilers that don't understand ANSI C prototypes still work,
 2258:    and ANSI C compilers can issue warnings about type mismatches. */
 2259: #undef PARAMS
 2260: #if defined (__STDC__) || defined (_AIX) \
 2261:         || (defined (__mips) && defined (_SYSTYPE_SVR4)) \
 2262:         || defined(WIN32) || defined(__cplusplus)
 2263: # define PARAMS(protos) protos
 2264: #else
 2265: # define PARAMS(protos) ()
 2266: #endif
 2267: @end example
 2268: 
 2269: これらのマクロは,以下のように@file{foo.h}で使用されます.
 2270: 
 2271: @example
 2272: #ifndef FOO_H
 2273: #define FOO_H 1
 2274: 
 2275: /* The above macro definitions. */
 2276: #include "@dots{}"
 2277: 
 2278: BEGIN_C_DECLS
 2279: 
 2280: int foo PARAMS((void));
 2281: int hello PARAMS((void));
 2282: 
 2283: END_C_DECLS
 2284: 
 2285: #endif /* !FOO_H */
 2286: @end example
 2287: 
 2288: @file{#ifndef FOO_H}が,@file{foo.h}の本体を,与えられたコンパイルで一回
 2289: 以上読み込むことを避けることに注意してください.
 2290: 
 2291: また,@code{BEGIN_C_DECLS}/@code{END_C_DECLS}の組の外側あるものだけが,
 2292: @code{#include}行にあります.厳密にいうと,それは,保護が必要なCのシンボ
 2293: ル名ですが,ヘッダの内容の中心周辺にこれらのマクロの単一の組がある場合,
 2294: ヘッダファイルはより管理しやすくなります.
 2295: 
 2296: @code{PARAMS},@code{BEGIN_C_DECLS},そして@code{END_C_DECLS}のこれらの
 2297: 定義を独自のヘッダで使用すべきです.そして,C++,ANSI,そして非ANSIのコ
 2298: ンパイラ@footnote{我々は,@code{__P},@code{__BEGIN_DECLS}そして
 2299: @code{__END_DECLS}の使用を推奨していました.アンダースコアで始まるシンボ
 2300: ル(とプリプロセッサマクロさえも)がコンパイラの使用で予約されているので,
 2301: 悪いアドバイスでした.}で有効なヘッダファイルを作成するために,それらを
 2302: 使用することが可能となります.
 2303: 
 2304: 移植可能なコードをネイティブに書かないでください,上記のヒントに続けるこ
 2305: とで,最も明白な問題を無くすことに役立ちますが,明らかに別の微妙な問題が
 2306: あります.以下の問題に対処する必要があるかもしれません.
 2307: 
 2308: @itemize @bullet
 2309: @item
 2310: ANSI以前のコンパイラは,一般的なポインタ型@code{void *}を常にサポートす
 2311: るわけではなく,そこでは@code{char *}を使用する必要があります.
 2312: 
 2313: @item
 2314: @code{const},@code{signed}そして@code{signed}キーワードは,サポートされ
 2315: ていないコンパイラもあり,特にANSI以前のコンパイラがあげられます.
 2316: 
 2317: @item
 2318: @code{long double}型は,多くのコンパイラでサポートされていません.
 2319: @end itemize
 2320: 
 2321: 
 2322: @node Inter-library dependencies
 2323: @chapter ライブラリ内部の依存
 2324: @cindex dependencies between libraries
 2325: @cindex inter-library dependencies
 2326: 
 2327: 定義では,すべての共有ライブラリシステムは,シンボル解決が実行時まで延期
 2328: されるように,実行形式をライブラリに依存させる方法を提供します.
 2329: 
 2330: @dfn{ライブラリ内部の依存性}は,他のライブラリに依存するライブラリにあり
 2331: ます.例えば,libtoolライブラリ@file{libhello}が@code{cos}関数を使用する
 2332: 場合,それは@file{libm}に対するライブラリ内部の依存性があり,数学ライブ
 2333: ラリが@code{cos}を実装しています.
 2334: 
 2335: 共有ライブラリシステムには,内部で一貫した方法で,この機能を提供するもの
 2336: もあります.これらのシステムは,潜在的に無限長の依存性の連鎖を認めます.
 2337: 
 2338: しかし,ほとんどの共有ライブラリのシステムは,単一レベルの依存のみを認め
 2339: るという制限があります.これらのシステムでは,プログラムは共有ライブラリ
 2340: に依存しますが,共有ライブラリは他の共有ライブラリに依存しません.
 2341: 
 2342: あらゆる事象で,ライブラリ内部の依存性を宣言するため,libtoolは単純なメ
 2343: カニズムを提供します.独自のライブラリに依存するすべてのライブラリ
 2344: @file{lib@var{name}}に対しライブラリを作成するとき,対応する
 2345: @code{-l@var{name}}オプションをリンク行に単純に加えます.@file{libm}に依
 2346: 存する@file{libhello}の例をビルドしてみます.
 2347: 
 2348: @example
 2349: burger$ @kbd{libtool gcc -g -O -o libhello.la foo.lo hello.lo \
 2350:                 -rpath /usr/local/lib -lm}
 2351: burger$
 2352: @end example
 2353: 
 2354: プログラムを@file{libhello}に対しリンクするとき,@samp{-l}オプションを再
 2355: び指定する必要はありません.必要なライブラリがすべて見つかることを保証す
 2356: るため,libtoolがそれを行います.この制約は,静的なライブラリシステムと,
 2357: 単純な動的ライブラリシステムとの互換性を保つために必要です.
 2358: 
 2359: AIXのように,この柔軟性さえ許可されないプラットフォームもあります.共有
 2360: ライブラリをビルドするため,それは完全に自己内蔵型である必要があり(すな
 2361: わち,@samp{.lo}ファイルや@samp{-l}で指定されたライブラリでシンボルが見
 2362: つかるもののみを参照する),@var{-no-undefined}フラグを指定する必要があり
 2363: ます.デフォルトで,libtoolはこの種のプラットフォームではスタティックラ
 2364: イブラリのみをビルドします.
 2365: 
 2366: 1.2以前のlibtoolのリリースのコードにおける,単純に考えられたライブラリ内
 2367: 部の依存性の追跡は,ライブラリを他のライブラリとリンクすることが可能なと
 2368: きが明白でないため,それが利用ができず,複雑な異常終了が発生します.この
 2369: 概念のより複雑な実装は,リリース1.3の前に再導入されましたが,libtoolがサ
 2370: ポートするすべてのプラットフォームに移植されませんでした.デフォルトで,
 2371: 保守的な動作は,ライブラリが他のライブラリとリンクすることを避け,プログ
 2372: ラムがリンクされるときのみに,その内部依存性が導入されます.
 2373: 
 2374: 
 2375: @node Dlopened modules
 2376: @chapter dlopenモジュール
 2377: @findex dlopen
 2378: @findex dlsym
 2379: @findex dlclose
 2380: @findex shl_load
 2381: @cindex dynamic linking, applications
 2382: @cindex dlopening modules
 2383: @cindex modules, dynamic
 2384: @cindex application-level dynamic linking
 2385: 
 2386: @dfn{ダイナミックリンク}の議論では,その用語が2つの異なる概念を述べると
 2387: きに使用されるので,混乱することがあります.
 2388: 
 2389: @enumerate 1
 2390: @item
 2391: 共有ライブラリに対しプログラムをコンパイルとリンクし,それは,ダイナミッ
 2392: クリンカにより実行時に自動的に解決される.この処理では,ダイナミックリン
 2393: クはアプリケーション透過です.
 2394: 
 2395: @item
 2396: アプリケーションの,@code{dlopen}@footnote{HP-UXでは異なり,
 2397: @code{shl_load}という名の関数が使用されます.}のような関数の呼び出しで,
 2398: それは,ユーザが指定したモジュールを実行時に任意にロードします.この形式
 2399: のダイナミックリンクは,アプリケーションで明示的に制御されます.
 2400: @end enumerate
 2401: 
 2402: 混乱を軽減するため,このマニュアルは2番目の形式のダイナミックリンクを
 2403: @dfn{dlopen}モジュールとして述べることにします.
 2404: 
 2405: dlopenモジュールの主な利点は,プログラムを拡張するために,インタプリタ言
 2406: 語を使用するのではなく,コンパイルされたオブジェクトコードにアクセスする
 2407: 能力です.実際,dlopenは,言語を拡張する効果的な方法を提供するため,イン
 2408: タプリタ言語でよく使用されます.
 2409: 
 2410: バージョン@value{VERSION}の現在は,libtoolはdlopenされるモジュールのサポー
 2411: トを提供します.しかし,パッケージがそのようなサポートを行うことを,
 2412: @file{configure.in}で,マクロ@samp{AC_LIBTOOL_DLOPEN}を使用して指示した
 2413: 方が良いでしょう.このマクロが使用されない(または@samp{AC_PROG_LIBTOOL} 
 2414: の@emph{後で}使用される)場合,libtoolはdlopenメカニズムが利用不可能と仮
 2415: 定し,シミュレーションを試みます.
 2416: 
 2417: この章ではdlopenでアクセス可能なモジュールを生成するため,dlopenアプリケー
 2418: ション開発者がlibtoolを使用する方法を議論します.
 2419: 
 2420: @menu
 2421: * Building modules::            Creating dlopenable objects and libraries.
 2422: * Dlpreopening::                Dlopening that works on static platforms.
 2423: * Finding the dlname::          Choosing the right file to @code{dlopen}.
 2424: * Dlopen issues::               Unresolved problems that need your attention.
 2425: @end menu
 2426: 
 2427: @node Building modules
 2428: @section dlopenのためのモジュールのビルド
 2429: 
 2430: オペレーティングシステムには,プログラムシンボルを@code{dlsym}(またはそ
 2431: の等価)関数を用いて動的に解決するために,特別に宣言する必要があるものも
 2432: あります.
 2433: 
 2434: libtoolは,@samp{-export-dynamic}と@samp{-module}リンクフラグを提供し
 2435: (@pxref{Link mode}),それはこの宣言を行います.他のモジュールやdlopenさ
 2436: れているlibtoolライブラリをdlopenするアプリケーションプログラムをリンク
 2437: する場合,これらのフラグを使用する必要があります.
 2438: 
 2439: 例えば,後でアプリケーションにdlopenされる共有ライブラリ@file{libhello} 
 2440: をビルドしたい場合,他のリンクオプションに@samp{-module}を加えます.
 2441: 
 2442: @example
 2443: burger$ @kbd{libtool gcc -module -o libhello.la foo.lo \
 2444:                 hello.lo -rpath /usr/local/lib -lm}
 2445: burger$
 2446: @end example
 2447: 
 2448: @emph{実行形式}からのシンボルが,dlopenしたいライブラリの未解決の参照を
 2449: 満足させる必要がある場合,フラグ@samp{-export-dynamic}を使用する必要があ
 2450: ります.dlopenを呼び出す実行形式をリンクするとき,@samp{-export-dynamic} 
 2451: を使用してください.
 2452: 
 2453: @example
 2454: burger$ @kbd{libtool gcc -export-dynamic -o hell-dlopener main.o}
 2455: burger$
 2456: @end example
 2457: 
 2458: 
 2459: @node Dlpreopening
 2460: @section dlopen
 2461: 
 2462: libtoolは,dlopenするlibtoolオブジェクトとlibtoolライブラリファイルに対
 2463: し,@emph{たとえ@code{dlopen}と@code{dlsym}関数が無いプラットフォームで
 2464: も},そのシンボルが解決できるように,特別のサポートを提供します.
 2465: 
 2466: ``laziness''の増加順にプログラムにコードをロードする,以下の別の方法を考
 2467: 慮します.
 2468: 
 2469: @enumerate 1
 2470: @item
 2471: 参照するしないに関わらない,実行形式の一部となるオブジェクトファイルへの
 2472: リンクです.オブジェクトファイルが見つからない場合,リンカは実行形式の作
 2473: 成を停止します.
 2474: 
 2475: @item
 2476: 上記のオブジェクトファイルでの未定義の参照を満足させるように,リンク時に
 2477: 検索されるようにするための,リンカに対するスタティックライブラリの宣言で
 2478: す.スタティックライブラリが見つからない場合,リンカは実行形式の作成を停
 2479: 止します.
 2480: 
 2481: @item
 2482: 上記のファイルでの未定義の参照を満足させるために,実行時に検索されるよう
 2483: にするための,実行時リンクの共有ライブラリの宣言です.共有ライブラリが見
 2484: つからない場合,ダイナミックリンカは実行形式の作成を停止します.
 2485: 
 2486: @item
 2487: アプリケーション自身が解決することができるように,参照を動的解決する
 2488: dlopenモジュールです.モジュールを開くときエラーが発生したり,モジュール
 2489: が見つからない場合,アプリケーションは壊れることなく回復します.
 2490: @end enumerate
 2491: 
 2492: libtoolは,コンパイル時にオブジェクトファイルをプログラムにリンクし,プ
 2493: ログラムのシンボルテーブルを表現するデータ構造を作成することで,スタティッ
 2494: クなプラットフォームで@samp{-dlopen}オプションをエミュレートします.
 2495: 
 2496: この特徴を使用するため,プログラムのリンク時(@pxref{Link mode})に
 2497: @samp{-dlopen}や@samp{-dlpreopen}フラグを使用することで,アプリケーショ
 2498: ンでdlopenしたいオブジェクトを宣言する必要があります.
 2499: 
 2500: @deftypefn {Structure} {struct} lt_dlsymlist @{ @w{const char *@var{name};} @w{lt_ptr @var{address};} @}
 2501: @var{name}属性は,@code{"fprintf"}のような,シンボル名のNULL終端されてい
 2502: る文字列です.@var{address}属性は,@code{&fprintf}のような対応するオブジェ
 2503: クトへの一般的なポインタです.
 2504: @end deftypefn
 2505: 
 2506: @deftypevar {const lt_dlsymlist *} lt_preloaded_symbols
 2507: @var{lt_symbol}構造体の配列で,プログラムにリンクされる,プリロードされ
 2508: ているすべてのシンボルを表現します.それぞれの@samp{-dlpreloaded}ファイ
 2509: ルに対し,ファイルの@var{name}を用いた要素と,@code{0}の@var{address}が
 2510: あり,このファイルからエクスポートされるすべてのシンボルが続きます.実行
 2511: 形式自身に対し,特別の名前@@PROGRAM@@が使用されます.最後の要素は,
 2512: @var{name}と@code{0}の@var{address}を持ちます.
 2513: @end deftypevar
 2514: 
 2515: ドル記号のような,ANSI Cでは有効ではない識別子を許可するコンパイラもあり
 2516: ます.libtoolはANSI Cで有効なシンボル(最初がASCII文字またはアンダースコ
 2517: アで,0以上のASCII文字,数字,そしてアンダースコアが続くもの)のみ認識す
 2518: るので,非ASCIIシンボルは@var{lt_preloaded_symbols}に出現しません.
 2519: 
 2520: 
 2521: @node Finding the dlname
 2522: @section dlopenで正しい名前の検索
 2523: @cindex names of dynamic modules
 2524: @cindex dynamic modules, names
 2525: 
 2526: @samp{-module}を用いてライブラリがリンクされた後,dlopen可能になります.
 2527: 残念ながら ライブラリ名が変更されるため,パッケージでdlopenの正しいファ
 2528: イルを決定する必要があります.
 2529: 
 2530: 最も率直で柔軟な実装は,インストールされた@samp{.la}ファイルを探し,以下
 2531: の行を検索することで実行時に決定することです.
 2532: 
 2533: @example
 2534: # The name that we can @code{dlopen}.
 2535: dlname='@var{dlname}'
 2536: @end example
 2537: 
 2538: @var{dlname}が空の場合,ライブラリはdlopenされません.それ以外では,それ
 2539: でライブラリのdlnameを与えます.そのため,ライブラリが
 2540: @file{/usr/local/lib/libhello.la}にインストールされていて,@var{dlname}
 2541: が@file{libhello.so.3}の場合,@file{/usr/local/lib/libhello.so.3}が
 2542: dlopenされます.
 2543: 
 2544: プログラムがこのアプローチを行っている場合,ライブラリが最終的にインストー
 2545: ルされるディレクトリと同じように,@code{LD_LIBRARY_PATH}@footnote{AIXで
 2546: の@code{LIBPATH}とHP-UXでの@code{SHLIB_PATH}です.}環境変数でリストアッ
 2547: プされているディレクトリで検索します.この変数(または同等物)を検索するこ
 2548: とで,インストール前でも,プログラムがlibtoolを使用してリンクし提供され
 2549: ているdlopenモジュールを見つけることを保証します.
 2550: 
 2551: 
 2552: @node Dlopen issues
 2553: @section 未解決のdlopenの問題
 2554: @cindex pitfalls with dlopen
 2555: @cindex dlopening, pitfalls
 2556: @cindex trouble with dlopen
 2557: 
 2558: 以下の問題は,libtoolのdlopenサポートを使用しても解決しません.
 2559: 
 2560: @itemize @bullet
 2561: @item
 2562: dlopen関数は一般に,共有ライブラリプラットフォームでのみ利用可能です.パッ
 2563: ケージをスタティックなプラットフォームに移植したい場合,libltdl
 2564: (@pxref{Using libltdl})を使用する,または,代わりとなる独自のdlopenダイ
 2565: ナミックコードを開発する必要があります.最も妥当な解決方法は,
 2566: @code{dlopen}ファミリーのラッパー関数を書くことを必要とし,それは,与え
 2567: られたプラットフォームでdlopenがサポートされていないまたは利用不可能なと
 2568: きの,パッケージ特有のトリックです.
 2569: 
 2570: @item
 2571: 関数の@code{dlopen}ファミリーの実装には大きな違いがあります.同じ関数名
 2572: を用いないプラットフォーム(特にHP-UXでは@code{shl_load}ファミリーを用い
 2573: ます)さえ存在します.
 2574: 
 2575: @item
 2576: アプリケーション開発者は,@code{dlopen}に渡す正しいモジュール名を発見す
 2577: るために,カスタムの検索関数を書く必要があります.
 2578: @end itemize
 2579: 
 2580: 
 2581: @node Using libltdl
 2582: @chapter libltdlの使用
 2583: @findex libltdl
 2584: @findex dlopen
 2585: @findex dlsym
 2586: @findex dlclose
 2587: @findex dlerror
 2588: @findex shl_load
 2589: @cindex dynamic linking, applications
 2590: @cindex dlopening modules
 2591: @cindex modules, dynamic
 2592: @cindex application-level dynamic linking
 2593: 
 2594: libtoolは,@file{libltdl}と呼ばれる小さなライブラリを提供し,それは,
 2595: dlopenライブラリの様々な困難をプログラマから隠すことを目指します.それは,
 2596: dlopenの機能で必要とされるアプリケーションとともに配布可能な,ヘッダファ
 2597: イルと小さなCソースファイルから成り立ちます.@file{libltdl}サービスの単
 2598: 純な実装に対し,あまりに制限が多いダイナミックリンカをもつプラットフォー
 2599: ム上では,GNU DLDを要求したり,libtoolのdlpreopenメカニズムを用いてダイ
 2600: ナミックリンクをエミュレートするだけのものもあります.
 2601: 
 2602: @noindent
 2603: libltdlは,現在以下のダイナミックリンクメカニズムをサポートします.
 2604: 
 2605: @itemize @bullet
 2606: @item
 2607: @code{dlopen} (Solaris,Linux,そして様々なBSD)
 2608: @item
 2609: @code{shl_load} (HP-UX)
 2610: @item
 2611: @code{LoadLibrary} (Win16とWin32)
 2612: @item
 2613: @code{load_add_on} (BeOS)
 2614: @item
 2615: GNU DLD (スタティックライブラリに対するダイナミックリンクのエミュレーション)
 2616: @item
 2617: libtoolのdlpreopen (@pxref{Dlpreopening})
 2618: @end itemize
 2619: 
 2620: @noindent
 2621: 以下の例外で,libltdlはGNUライブラリ公有使用許諾書の条件下でライセンスさ
 2622: れています.
 2623: 
 2624: @quotation
 2625: GNU Lesser General Public Licenseの特別な例外として,GNU libtoolを使用し
 2626: てビルドされるプログラムやライブラリの一部としてこのファイルを配布する場
 2627: 合,プログラムの残りに対して使用する配布条件と同じものにして,それを含め
 2628: ることができます.
 2629: @end quotation
 2630: 
 2631: @menu
 2632: * Libltdl interface::           How to use libltdl in your programs.
 2633: * Modules for libltdl::         Creating modules that can be @code{dlopen}ed.
 2634: * Thread Saftey in libltdl::	Registering callbacks for multi-thread safety.
 2635: * User defined module data::    Associating data with loaded modules.
 2636: * Module loaders for libltdl::  Creating user defined module loaders.
 2637: * Distributing libltdl::        How to distribute libltdl with your package.
 2638: @end menu
 2639: 
 2640: @node Libltdl interface
 2641: @section プログラムでのlibltdlの使用法
 2642: 
 2643: @noindent
 2644: libltdl APIは,強力なSolarisとLinuxのdlopenインターフェースに似ていて,
 2645: それは,非常に簡単ですが強力です.
 2646: 
 2647: @noindent
 2648: プログラムでlibltdlを使用するために,ヘッダファイル@file{ltdl.h}をインク
 2649: ルードする必要があります.
 2650: 
 2651: @example
 2652: #include <ltdl.h>
 2653: @end example
 2654: 
 2655: @noindent
 2656: libltdlの前回のリリースでは,@sc{posix}名前空間の慣習に違反していたシン
 2657: ボルを,いくつか使用していました.これらのシンボルは,現在非難され,ここ
 2658: で記述されるように置換されました.古い非難されているシンボル名に依存した
 2659: コードがある場合,@file{ltdl.h}をインクルードする前に
 2660: @samp{LT_NON_POSIX_NAMESPACE}を定義すると,変換されたマクロが提供されま
 2661: す.使用するシンボルの組が何であっても,新しいAPIは前回のものとバイナリ
 2662: 互換ではないので,このバージョンのlibltdlを使用するため,アプリケーショ
 2663: ンを再コンパイルする必要があるでしょう.
 2664: 
 2665: @noindent
 2666: libltdlがスレッドセーフでない,すなわち,マルチスレッドアプリケーション
 2667: は,libtoolに対しミューテックスを使用する必要があることに注意してくださ
 2668: い.それは,GNU/Linuxのglibc 2.0の@samp{RTLD_LAZY}を用いた@code{dlopen} 
 2669: が(デフォルトでlibtoolを使用します),スレッドセーフではないことが報告さ
 2670: れていますが,この問題は,glibc 2.1でおそらく修正されるでしょ.一方,
 2671: @samp{RTLD_NOW}は,FreeBSD上のマルチスレッドアプリケーションで問題が生じ
 2672: たと報告されています.これらの問題に関する作業は,読者の演習として残って
 2673: います.貢献は,きっと歓迎されます.
 2674: 
 2675: @noindent
 2676: 以下の型は@file{ltdl.h}で定義されています.
 2677: 
 2678: @deftp {Type} lt_ptr
 2679: @code{lt_ptr}は,汎用ポインタです.
 2680: @end deftp
 2681: 
 2682: @deftp {Type} lt_dlhandle
 2683: @code{lt_dlhandle}はモジュール"ハンドル"です.すべてのlt_dlopenされるモ
 2684: ジュールはそれに関連付けされたハンドルがあります.
 2685: @end deftp
 2686: 
 2687: @deftp {Type} lt_dlsymlist
 2688: @code{lt_dlsymlist}はdlpreopenされるモジュールのシンボルリストです.この
 2689: 構造体は,@pxref{Dlpreopening}で記述されます.
 2690: @end deftp
 2691: 
 2692: @page
 2693: @noindent
 2694: libltdlは以下の関数を提供します.
 2695: 
 2696: @deftypefun int lt_dlinit (void)
 2697: libltdlを初期化します.この関数は,libltdl使用する前に呼び出す必要があり,
 2698: 複数回呼び出すことが可能です.成功したら0,それ以外ではエラーの番号を返
 2699: します.
 2700: @end deftypefun
 2701: 
 2702: @deftypefun int lt_dlexit (void)
 2703: libltdlを終了し,すべてのモジュールを閉じます.この関数は,
 2704: @code{lt_dlinit}が正常に呼び出された回数と同じだけ呼び出されたとき,
 2705: libltdlを終了するだけです.成功したら0,それ以外ではエラーの番号を返しま
 2706: す.
 2707: @end deftypefun
 2708: 
 2709: @deftypefun lt_dlhandle lt_dlopen (const char *@var{filename})
 2710: ファイル名@var{filename}を用いてモジュールを開き,そのハンドルを返します.
 2711: @code{lt_dlopen}は,libtoolダイナミックモジュール,プリロードされたスタ
 2712: ティックモジュール,プログラム自身,そしてネイティブなダイナミックライブ
 2713: ラリを開くことが可能です.
 2714: 
 2715: モジュール内の未解決のシンボルは,それが依存する(まだ実装されていない)ラ
 2716: イブラリと,前もってdlopenされたモジュールを用いて解決されます.このモ
 2717: ジュールを使用している実行形式が@code{-export-dynamic}フラグでリンクされ
 2718: ている場合,実行形式の大域的なシンボルもモジュール内の参照の解決に使用さ
 2719: れます.
 2720: 
 2721: @var{filename}が@code{NULL}でプログラムが@code{-export-dynamic}や
 2722: @code{-dlopen self}を用いてリンクされている場合,@code{lt_dlopen}はプロ
 2723: グラム自身のハンドルを返し,それはそのシンボルのアクセスに使用可能です.
 2724: 
 2725: libltdlがライブラリを見つけられず,ファイル名@var{filename}がディレクト
 2726: リコンポーネントを持たない場合,それは,以下の検索パスを(以下の順番で),
 2727: さらにモジュールを検索します.
 2728: 
 2729: @enumerate 1
 2730: @item
 2731: ユーザ定義の検索パス:
 2732: 
 2733: この検索パスは,関数@code{lt_dlsetsearchpath}と@code{lt_dladdsearchdir} 
 2734: を用いたプログラムで設定可能です.
 2735: 
 2736: @item
 2737: libltdlの検索パス:
 2738: 
 2739: この検索パスは,環境変数@var{LTDL_LIBRARY_PATH}の値です.
 2740: 
 2741: @item
 2742: システムのライブラリ検索パス:
 2743: 
 2744: システム依存のライブラリ検索パスです(例えば,Linuxでは
 2745: @var{LD_LIBRARY_PATH}になります).
 2746: @end enumerate
 2747: 
 2748: それぞれの検索パスは,例えば@code{"/usr/lib/mypkg:/lib/foo"}のような,コ
 2749: ロンで分けられた絶対的なディレクトリのリストにする必要があります.
 2750: 
 2751: 同じモジュールが複数回ロードされた場合,同じハンドルが返されます.あらゆ
 2752: る原因で@code{lt_dlopen}が失敗した場合,@code{NULL}が返されます.
 2753: @end deftypefun
 2754: 
 2755: @deftypefun lt_dlhandle lt_dlopenext (const char *@var{filename})
 2756: ファイル名に異なるファイル名の拡張子を追加を試みる以外は,
 2757: @code{lt_dlopen}と同じです.ファイル名@var{filename}を持つファイルが見つ
 2758: からない場合,libltdlは,以下の拡張子の追加を試みます.
 2759: 
 2760: @enumerate 1
 2761: @item
 2762: libtoolのアーカイブ拡張子@samp{.la}です.
 2763: 
 2764: @item
 2765: ホストプラットフォームの本来のダイナミックライブラリに使用される拡張子で,
 2766: 例えば,@samp{.so},@samp{.sl}等です.
 2767: @end enumerate
 2768: 
 2769: この探索手法は,本来のダイナミックライブラリの命名規則を知らないプログラ
 2770: ムが,そのようなライブラリを,libtoolモジュールと同様に,透過的に
 2771: @code{dlopen}することを可能にするために設計されています.
 2772: @end deftypefun
 2773: 
 2774: @deftypefun int lt_dlclose (lt_dlhandle @var{handle})
 2775: モジュール@var{handle}の参照カウントを減らします.ゼロになったり,このモ
 2776: ジュールに依存する他のモジュールがない場合,モジュールはアンロードされま
 2777: す.成功時には0を返します.
 2778: @end deftypefun
 2779: 
 2780: @deftypefun lt_ptr lt_dlsym (lt_dlhandle @var{handle}, const char *@var{name})
 2781: モジュール@var{handle}内のアドレスを返し,そこでは,ヌルで終端された文字
 2782: 列@var{name}で与えられるシンボルがロードされています.シンボルが見つから
 2783: ない場合は@code{NULL}を返します.
 2784: @end deftypefun
 2785: 
 2786: @deftypefun {const char *}lt_dlerror (void)
 2787: libltdlのあらゆる関数から発生した最も新しいエラーを記述する,可読性の高
 2788: い文字列を返します.初期化からまたは最後に呼び出されてからエラーが発生し
 2789: ていない場合,@code{NULL}を返します.
 2790: @end deftypefun
 2791: 
 2792: @deftypefun int lt_dlpreload (const lt_dlsymlist *@var{preloaded})
 2793: プリロードされているモジュール@var{preloaded}のリストを登録します.
 2794: @var{preloaded}が@code{NULL}の場合,@code{lt_dlpreload_default}で設定さ
 2795: れているリスト以外の,これまで登録されているすべてのシンボルリストが検出
 2796: されます.成功時には0を返します.
 2797: @end deftypefun
 2798: 
 2799: @deftypefun int lt_dlpreload_default (const lt_dlsymlist *@var{preloaded})
 2800: プリロードされているモジュールリストのデフォルトを@var{preloaded}に設定
 2801: し,それは@code{lt_dlpreload}で検出されません.この関数は,
 2802: @code{lt_dlinit}を使用して初期化されるためにlibltdlを要求し@emph{ない}こ
 2803: とと,デフォルトでプリロードされるモジュールを登録するためにプログラムで
 2804: 使用できることに注意してください.この関数を直接呼び出す代わりに,ほとん
 2805: どのプログラムはマクロ@code{LTDL_SET_PRELOADED_SYMBOLS}を使用します.
 2806: 
 2807: 成功時には0を返します.
 2808: @end deftypefun
 2809: 
 2810: @defmac LTDL_SET_PRELOADED_SYMBOLS()
 2811: プリロードされるシンボルのデフォルトリストを設定します.プリロードされる
 2812: libltdlのモジュールを初期化するために,プログラムで使用した方が良いでしょ
 2813: う.
 2814: 
 2815: @example
 2816: #include <ltdl.h>
 2817: 
 2818: int main() @{
 2819:   /* ... */
 2820:   LTDL_SET_PRELOADED_SYMBOLS();
 2821:   /* ... */
 2822: @}
 2823: @end example
 2824: @end defmac
 2825: 
 2826: @deftypefun int lt_dladdsearchdir (const char *@var{search_dir})
 2827: 検索ディレクトリ@var{search_dir}をユーザー定義のライブラリ検索パスに追加
 2828: します.成功時には0を返します.
 2829: @end deftypefun
 2830: 
 2831: @deftypefun int lt_dlsetsearchpath (const char *@var{search_path})
 2832: 現在のユーザ定義のライブラリ検索パスを@var{search_path}で置換し,それは
 2833: コロンで分けられた絶対的なディレクトリのリストにする必要があります.成功
 2834: 時には0を返します.
 2835: @end deftypefun
 2836: 
 2837: @deftypefun {const char *}lt_dlgetsearchpath (void)
 2838: 現在のユーザ定義のライブラリ検索パスを返します.
 2839: @end deftypefun
 2840: 
 2841: @deftypefun int lt_dlmakeresident (lt_dlhandle @var{handle})
 2842: モジュールを@samp{lt_dlclose}できないように印を付けます.モジュールがプ
 2843: ロジェクトの中心部の機能を実装している場合,削除されるとコードが壊れるの
 2844: で,これは役に立つはずです.成功すると0を返します.
 2845: 
 2846: 実行しているバイナリに対する@var{handle}を取得するために@samp{lt_dlopen
 2847: (NULL)}を使用する場合,そのハンドルは常駐しているような印が常に付き,し
 2848: たがってうまく@samp{lt_dlclose}することができません.
 2849: @end deftypefun
 2850: 
 2851: @deftypefun int lt_dlisresident (lt_dlhandle @var{handle})
 2852: 特定のモジュールが常駐しているように印が付いているかどうか調査し,その場
 2853: 合は1を返し,それ以外では0を返します.この関数の実行中にエラーがある場合, 
 2854: -1 が返され,@code{lt_dlerror}を用いて回収されるエラーメッセージが設定さ
 2855: れます.
 2856: @end deftypefun
 2857: 
 2858: @deftypevar {lt_ptr (*) (size_t @var{size})} lt_dlmalloc
 2859: @deftypevarx {void (*) (lt_ptr @var{ptr})} lt_dlfree
 2860: これらの変数は,デフォルトで@code{malloc}と@code{free}に設定されますが,
 2861: 同等の機能を提供する他の関数に設定可能です.しかし,
 2862: @code{lt_dlpreopen_default}やマクロ@code{LTDL_SET_PRELOADED_SYMBOLS}以外
 2863: のあらゆるlibltdl関数の呼び出し後に,その値を編集すべきではありません.
 2864: @end deftypevar
 2865: 
 2866: 
 2867: @node Modules for libltdl
 2868: @section @code{dlopen}可能なモジュールの作成
 2869: 
 2870: libtoolモジュールは,いくつかの例外はありますが,通常のlibtoolライブラリ
 2871: に似ています.
 2872: 
 2873: libtoolの@samp{-module}スイッチを用いて,モジュールとリンクする必要があ
 2874: り,そして,dlopenをサポートしていないプラットフォームでlibtoolが
 2875: dlpreopenできるよう,@samp{-dlopen modulename.la}を用いてモジュールを
 2876: dlopenするために,あらゆるプログラムとリンクすべきです.モジュールが,あ
 2877: らゆる他のライブラリに依存する場合,モジュールとリンクするときや,それを
 2878: dlopenするプログラムをリンクするとき,それらを確実に指定してください.特
 2879: 定のモジュールに対し@pxref{Versioning}を使用禁止にしたい場合,
 2880: @samp{-avoid-version}スイッチを用いてリンクすべきです.libtoolモジュール
 2881: は,"lib"接頭辞が不要なことに注意してください.しかし,automake 1.4やそ
 2882: れ以降のものは,そのようなモジュールのビルドが必要です.
 2883: 
 2884: 通常,その内部を知る必要なしにプログラムがdlopenできるよう,一組のモジュー
 2885: ルは同じインターフェース提供し,すなわち同じシンボルをエクスポートします.
 2886: すべてのエクスポートされたシンボルで,シンボルの衝突を避けるため,
 2887: "modulename_LTX_"を前置する必要があります(@samp{modulename}はモジュール
 2888: 名です).内部シンボルは,例えば"_modulename_"を前置するといった,他のモ
 2889: ジュールと衝突しないような方法で命名する必要があります.一回以上宣言され
 2890: た,同じシンボルを持つことをサポートするシステムもありますが,それは通常
 2891: 移植性がなく,そのようなモジュールをdlpreopenすることを不可能にします.
 2892: libltdlは,シンボルの本当の名前を得るとき,自動的に接頭辞を切り取ります.
 2893: さらに,非libtoolモジュールもdlopenできるよう,接頭辞を使用していないモ
 2894: ジュールをサポートします.
 2895: 
 2896: @file{foo1.c}は移植可能なlibtoolモジュールの例です.エクスポートされたシ
 2897: ンボルは"foo1_LTX_",内部シンボルは"_foo1_"が前置されています.コードの
 2898: 可読性を高めるため,エイリアスは最初に定義されています.
 2899: 
 2900: @example
 2901: /* aliases for the exported symbols */
 2902: #define foo	foo1_LTX_foo
 2903: #define bar	foo1_LTX_bar
 2904: 
 2905: /* a global variable definition */
 2906: int bar = 1;
 2907: 
 2908: /* a private function */
 2909: int _foo1_helper() @{
 2910:   return bar;
 2911: @}
 2912: 
 2913: /* an exported function */
 2914: int foo() @{
 2915:   return _foo1_helper();
 2916: @}
 2917: @end example
 2918: 
 2919: @noindent
 2920: @file{Makefile.am}は,モジュール@file{foo1.la}をビルドするのに必要な規則
 2921: を含んでいます.
 2922: 
 2923: @example
 2924: ...
 2925: lib_LTLIBRARIES = foo1.la
 2926: 
 2927: foo1_la_SOURCES = foo1.c
 2928: foo1_la_LDFLAGS = -module
 2929: ...
 2930: @end example
 2931: 
 2932: 
 2933: @node Thread Saftey in libltdl
 2934: @section マルチスレッド環境でのlibtldlの使用
 2935: 
 2936: @code{lt_dlmutex_register()}関数を使用し,適切なコールバック関数の定義を
 2937: 提供することで,libltdlをマルチスレッド環境で使用することが可能です.
 2938: 
 2939: @deftypefn {Type} void lt_dlmutex_lock (void)
 2940: これは,ミューテックスロックが必要なlibltdlの実装コードの部分の,最初に
 2941: 呼び出される関数のアドレスを持っている,関数のポインタ型です.
 2942: 
 2943: libltdlは本質的に再帰的なので,これらのコールバック関数によって使用され
 2944: るロックメカニズムがリエントリー可能であることは重要で,そうでなければ,
 2945: おかしな問題が発生します.
 2946: @end deftypefn
 2947: 
 2948: @deftypefn {Type} void lt_dlmutex_unlock (void)
 2949: アンロック関数に一致する型です.
 2950: @end deftypefn
 2951: 
 2952: @deftypefn {Type} void lt_dlmutex_seterror @w{(const char *@var{error});}
 2953: libltdl @sc{api}の関数の多くは,エラーを発生したクライアントを示す,特殊
 2954: な戻り値をとります.通常(シングルスレッドアプリケーションでは),内部から
 2955: 回収することができるエラーを記述する文字列は,@code{lt_dlerror()}に保存
 2956: されます.
 2957: 
 2958: この形式の関数は,それがマルチスレッドのコンテクストで動作するように,ラ
 2959: イブラリに登録される必要があります.関数は,スレッドローカルストレージに
 2960: 渡されるあらゆるエラーメッセージを保存すべきです.
 2961: @end deftypefn
 2962: 
 2963: @deftypefn {Type} {const char *} lt_dlmutex_geterror (void)
 2964: スレッドローカルのストレージに,最後にエラーメッセージを保存したものに関
 2965: 連するコールバック関数に一致する型です.
 2966: 
 2967: 正しく登録されたとき,クライアントに対するエラーメッセージを回収するため
 2968: に,全てのスレッドから@code{lt_dlerror())}によって,この関数は使用されま
 2969: す.
 2970: @end deftypefn
 2971: 
 2972: @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})}
 2973: libltdlのマルチスレッドの準備で,上記のそれぞれの関数の型を登録するため
 2974: に,この関数を使用してください.全ての引数は,有効な@code{NULL}でない関
 2975: 数アドレスにする必要があり,また,そうでない場合は,シングルスレッドオペ
 2976: レーションへの戻り値として,全て@code{NULL}にする必要があります.
 2977: @end deftypefn
 2978: 
 2979: 
 2980: @node User defined module data
 2981: @section ロードされたモジュールに関連するデータ
 2982: 
 2983: libltdlが管理している,それぞれのロードされたモジュールに関する内部情報
 2984: には,ユーザが利用可能なものもあり,それは以下のような構造体の形式です.
 2985: 
 2986: @deftypefn {Type} {struct} lt_dlinfo @{ @w{char *@var{filename};} @w{char *@var{name};} @w{int @var{ref_count};} @}
 2987: @code{lt_dlinfo}は,モジュールの情報を保存するために使用されます.
 2988: @var{filename}属性は,@code{NULL}で終端された,実際のモジュールファイル
 2989: 名の文字列です.モジュールがlibtoolモジュールの場合,@var{name}はそのモ
 2990: ジュール名(例えば,@code{"dir/libfoo.la"}に対する@code{"libfoo"})で,そ
 2991: れ以外では@code{NULL}に設定されます.@var{ref_count}属性は,現在ロードさ
 2992: れている同じモジュールの回数を記述する参照カウンタです.
 2993: @end deftypefn
 2994: 
 2995: 以下の関数は,与えられた@var{handle}に対するこの構造体のlibltdlの内部の
 2996: コピーへのポインタを返します.
 2997: 
 2998: @deftypefun {const lt_dlinfo *} lt_dlgetinfo (@w{lt_dlhandle @var{handle}})
 2999: モジュール@var{handle}に関するいくつかの情報を含む構造体の,ポインタを返
 3000: します.構造体の内容は編集してはなりません.失敗時には@code{NULL}が返り
 3001: ます.
 3002: @end deftypefun
 3003: 
 3004: さらに,ロードした全てのモジュールのハンドルリストを保持する手助けをする
 3005: ために,これらの関数で,ロードされているモジュールのlibltdlのリスト全体
 3006: を繰り返すことが可能となります.
 3007: 
 3008: @deftypefun int lt_dlforeach (@w{int (*@var{func}) (lt_dlhandle @var{handle}, lt_ptr @var{data})}, @w{lt_ptr @var{data}})
 3009: ロードされているそれぞれのモジュールに対し関数@var{func}を呼び出します.
 3010: 引数の@var{handle}は,ロードされているモジュールのハンドルの一つで,
 3011: @var{data}は,@code{lt_dlforeach}に渡す@var{data}引数です.@var{func}が
 3012: ハンドルの一つに対し,ゼロでない値を返すとすぐに,@code{lt_dlforeach}は
 3013: @var{func}の呼び出しを停止し,直ちに1を返します.それ以外は0が返ります.
 3014: @end deftypefun
 3015: 
 3016: @deftypefun lt_dlhandle lt_dlhandle_next (@w{lt_dlhandle place})
 3017: @var{place}が@code{NULL}の場合は,リスト内の最初のハンドルを返し,そして
 3018: 順番に次ものを呼び出すことで,ロードされているモジュール全体を繰り返しま
 3019: す.@var{place}が,ロードされているモジュールリスト内の最後の要素の場合,
 3020: この関数は@code{NULL}を返します.
 3021: @end deftypefun
 3022: 
 3023: もちろん,アプリケーションの目的のために,それぞれのハンドルに関連付けす
 3024: る必要があるデータがある場合,libltdlで管理されるリストと平行して,ロー
 3025: ドされたモジュールハンドルの独自のリストの管理が必要になります.しかし,
 3026: 個別のモジュールハンドルを用いたアプリケーションデータに,ロードされたも
 3027: のとして関連付けさせるために,以下の@sc{api}の呼び出しを使用する場合には,
 3028: 実際にはそうする必要はありません.前もって保存したデータを回収するために
 3029: 後で利用するlibltdlからのユニークな呼び出しidを,最初に取得する必要があ
 3030: ります.これで,ロードされているモジュールに対する独自のデータを個別に保
 3031: 存したい異なるライブラリが,もう一つの(ライブラリ)のデータへのインター
 3032: フェースなしでそれを行うことが可能となります.
 3033: 
 3034: @deftp {Type} lt_dlcaller_id
 3035: 個別のデータセットのキーを保つ,透過でない型です.
 3036: @end deftp
 3037: 
 3038: @deftypefun lt_dlcaller_id lt_dlcaller_register (void)
 3039: モジュールデータ毎に個別のセットを,保存し回収するためのユニークなキーを
 3040: 取得するために,これを使用してください.
 3041: @end deftypefun
 3042: 
 3043: @deftypefun lt_ptr lt_dlcaller_set_data (@w{lt_dlcaller_id @var{key}}, @w{lt_dlhandle @var{handle}}, @w{lt_ptr @var{data}})
 3044: 後で回収するために,@var{key}と@var{handle}にユニークに関連付けされたデー
 3045: タのセットとして,@var{data}を設定します.この関数は,以前に関連付けされ
 3046: た@var{key}と@var{handle}がある場合は,その@var{data}を返します.0の結果
 3047: は,前回のエラー(が存在する場合)に対する診断結果が,@code{lt_dlerror()}
 3048: で利用可能であることを示している可能性があります.
 3049: 
 3050: 例えば,いくつかの関連データを正しく削除するために,以下のようにします.
 3051: 
 3052: @example
 3053:     lt_ptr stale = lt_dlcaller_set_data (key, handle, 0);
 3054:     if (stale == NULL)
 3055:       @{
 3056:         char *error_msg = lt_dlerror ();
 3057: 
 3058:         if (error_msg != NULL)
 3059:           @{
 3060:             my_error_handler (error_msg);
 3061:             return STATUS_FAILED;
 3062:           @}
 3063:       @}
 3064:     else
 3065:       @{
 3066:         free (stale);
 3067:       @}
 3068: @end example
 3069: @end deftypefun
 3070: 
 3071: @deftypefun lt_ptr lt_dlcaller_get_data (@w{lt_dlcaller_id @var{key}}, @w{lt_dlhandle @var{handle}})
 3072: @var{key}と@var{handle}に関連付けされている@var{data}のアドレス,または,
 3073: 無い場合は@code{NULL}を返します.
 3074: @end deftypefun
 3075: 
 3076: ここまでの関数は,アプリケーションにロードされたりアンロードされたりした
 3077: モジュールを追跡させる必要なく,オペレーションの検索と適用を実装するため
 3078: に,@code{lt_dlforeach}と組み合わせることが可能です.
 3079: 
 3080: @example
 3081: int
 3082: my_dlcaller_callback (lt_dlhandle handle, lt_ptr key_ptr)
 3083: @{
 3084:   struct my_module_data *my_data;
 3085: 
 3086:   my_data = lt_dlcaller_get_data (handle, (lt_dlcaller_id) *key_ptr);
 3087: 
 3088:   return process (my_data);
 3089: @}
 3090: 
 3091: int
 3092: my_dlcaller_foreach (lt_dlcaller_id key)
 3093: @{
 3094:   lt_dlforeach (my_dlcaller_callback, (lt_ptr) &key);
 3095: @}
 3096: @end example
 3097: 
 3098: 
 3099: @node Module loaders for libltdl
 3100: @section 新しいモジュールローダの作成方法と登録方法
 3101: 
 3102: モジュールにアクセスするためのlibltdlの方法は多いけれど,プロジェクトの
 3103: 目的に十分でないときもあります.独自のローダを書き,@code{lt_dlopen}が利
 3104: 用できるように,libltdlでそれを登録することが可能です.
 3105: 
 3106: ローダを書くことは,@code{lt_dlopen},@code{lt_dlsym}そして
 3107: @code{lt_dlclose}で呼び出し可能な,少なくとも3つの関数を書くことを必要と
 3108: します.オプションで,@code{lt_dlexit}が実行されるときクリーンアップ処理
 3109: を実行する終了関数と,@code{lt_dlsym}に渡されるあらゆるシンボルに前置さ
 3110: れるシンボルの前置文字を提供することも可能です.これらの関数は,以下の関
 3111: 数のポインタ型に一致する必要があり,その後,それらを
 3112: @code{lt_user_dlloader}の代わりに関連付けし,登録することが可能です.
 3113: 
 3114: ローダの登録には,@code{lt_dlloader_find}が認識でき,
 3115: @code{lt_dlloader_remove}で削除できるように,それに対する名前を選択する
 3116: ことが必要です.選択した名前はユニークである必要があり,libltdlの組み込
 3117: みローダで既に使用しているものはいけません.
 3118: 
 3119: @table @asis
 3120: @item "dlopen"
 3121: 存在する場合は,システムのダイナミックローダ.
 3122: @item "dld"
 3123: libltdlがビルドされたときに@file{libdld}がインストールされている場合は,
 3124: @sc{gnu} dldローダ.
 3125: @item "dlpreload"
 3126: プリロードされているスタティックモジュールの@code{lt_dlopen}のためのロー
 3127: ダ.
 3128: @end table
 3129: 
 3130: 前置される"dl"は,libltdlの将来のバージョンで提供されるローダとして予約
 3131: されているので,独自のローダ名に使用すべきではありません.
 3132: 
 3133: @noindent
 3134: 以下の型は,@file{ltdl.h}で定義されています.
 3135: 
 3136: @deftp {Type} lt_module
 3137: @code{lt_module}はモジュール依存のdlloaderです.ダイナミックモジュールロー
 3138: ダの拡張は,これらの低レベルの型を使用して通信を行ないます.
 3139: @end deftp
 3140: 
 3141: @deftp {Type} lt_dlloader
 3142: @code{lt_dlloader}はモジュールローダの型に対するハンドルです.
 3143: @end deftp
 3144: 
 3145: @deftp {Type} lt_dlloader_data
 3146: @code{lt_dlloader_data}はローダのインスタンスデータに対して使用されます.
 3147: @end deftp
 3148: 
 3149: @deftypefn {Type} {struct} lt_user_dlloader @{@w{const char *@var{sym_prefix};} @w{lt_module_open *@var{module_open};}@w{lt_module_close *@var{module_close};} @w{lt_find_sym *@var{find_sym};} @w{lt_dlloader_exit *@var{dlloader_exit};} @w{lt_dlloader_data @var{dlloader_data};} @}
 3150: ダイナミックモジュールを開くために新しい方法を定義したくて,それを使用し
 3151: た@code{lt_dlopen} @sc{api}がある場合,これらの構造体のインスタンスを作
 3152: 成し,それを@code{lt_dlloader_add}に渡す必要があります.好みの
 3153: @var{dlloader_data}フィールドで渡すことが可能で,それは,関数ポインタフィー
 3154: ルドで指定されている,それぞれの関数への最初のパラメータの値として戻りま
 3155: す.
 3156: @end deftypefn
 3157: 
 3158: @deftypefn {Type} lt_module lt_module_open (@w{lt_user_data @var{loader_data},} @w{const char *@var{filename}})
 3159: @code{lt_dlloader}モジュールローダに対するローダ関数の型です.
 3160: @code{struct lt_user_dlloader}構造体のdlloader_dataフィールドに設定され
 3161: る値は,@var{loader_data}パラメータで,この関数に渡されます.そのような
 3162: 関数の実装は,指名されたモジュールのロードを試み,関連する
 3163: @code{lt_module_close}と@code{lt_sym_find}関数のポインタに渡すのに適切な
 3164: @code{lt_module}を返すべきです.関数が失敗した場合は@code{NULL}を返し,
 3165: @code{lt_dlseterror}を用いてエラーメッセージを設定すべきです.
 3166: @end deftypefn
 3167: 
 3168: @deftypefn {Type} int lt_module_close (@w{lt_dlloader_data @var{loader_data},} @w{lt_module @var{module}})
 3169: ユーザが定義したモジュールローダに対するアンローダの型です.そのような関
 3170: 数の実装は,@var{module}モジュールに結び付けられたあらゆるリソースの解放
 3171: を試み,その後でメモリからアンロードすべきです.理由があって関数が失敗し
 3172: た場合,@code{lt_dlseterror}を用いてエラーメッセージを設定し,ゼロ以外を
 3173: 返すべきです.
 3174: @end deftypefn
 3175: 
 3176: @deftypefn {Type} lt_ptr lt_find_sym (@w{lt_user_data @var{loader_data},} @w{lt_module @var{module},} @w{const char *@var{symbol}})
 3177: ユーザが定義したモジュールローダに対する,シンボルルックアップ関数の型で
 3178: す.そのような関数の実装は,モジュール@var{module}内の指名された
 3179: @var{symbol}のアドレスを返す,もしくは,検査が失敗した場合は,エラーメッ
 3180: セージを@code{lt_dlseterror}で設定し,@code{NULL}を返すべきです.
 3181: @end deftypefn
 3182: 
 3183: @deftypefn {Type} int lt_dlloader_exit (@w{lt_user_data @var{loader_data}})
 3184: ユーザが定義したモジュールローダに対する,終了関数の型です.そのような関
 3185: 数の実装は,ローダに関連するあらゆるリソースを解放すべきで,それには
 3186: @code{lt_user_dlloader}の@code{dlloader_data}フィールド内部にあるユーザ
 3187: が指定したあらゆるデータを含みます.@code{NULL}でない場合は,関数は
 3188: @code{lt_dlexit}と@code{lt_dlloader_remove}から呼び出されます.
 3189: @end deftypefn
 3190: 
 3191: 例えば,以下のようにします.
 3192: 
 3193: @example
 3194: int
 3195: register_myloader (void)
 3196: @{
 3197:   lt_user_dlloader dlloader;
 3198: 
 3199:   /* User modules are responsible for their own initialisation. */
 3200:   if (myloader_init () != 0)
 3201:     return MYLOADER_INIT_ERROR;
 3202: 
 3203:   dlloader.sym_prefix    = NULL;
 3204:   dlloader.module_open   = myloader_open;
 3205:   dlloader.module_close  = myloader_close;
 3206:   dlloader.find_sym      = myloader_find_sym.
 3207:   dlloader.dlloader_exit = myloader_exit;
 3208:   dlloader.dlloader_data = (lt_user_data)myloader_function;
 3209: 
 3210:   /* Add my loader as the default module loader. */
 3211:   if (lt_dlloader_add (lt_dlloader_next (NULL), &dlloader, "myloader") != 0)
 3212:     return ERROR;
 3213: 
 3214:   return OK;
 3215: @}
 3216: @end example
 3217: 
 3218: ローダに対する必要な初期化がある場合は,ローダが登録される前に手動で実行
 3219: する必要があることに注意してください -- libltdlはユーザローダの初期化を
 3220: 扱いません.
 3221: 
 3222: 終了はlibltdlで扱われ@emph{ます}が,@code{dlloader_exit}のコールバックが
 3223: 初期化フェーズの間に要求された,あらゆるリソースを解放することを確かめる
 3224: ことは重要です.
 3225: 
 3226: @page
 3227: @noindent
 3228: libltdlは,独自のモジュールローダを書くために,以下の関数を提供します.
 3229: 
 3230: @deftypefun int lt_dlloader_add (@w{lt_dlloader *@var{place},} @w{lt_user_dlloader *@var{dlloader},} @w{const char *@var{loader_name}})
 3231: 新しいモジュールローダを全てのローダリストに加え,それは,(@var{place}が
 3232: @code{NULL}の場合は)最後のローダとして,それ以外では@var{place}として渡
 3233: されたローダの直前に加えます.@var{loader_name}は,新しく登録されたロー
 3234: ダが渡された場合,@code{lt_dlloader_name}を返します,これらの
 3235: @var{loader_name}は,ユニークである必要があり,そうでない場合は,
 3236: @code{lt_dlloader_remove}と@code{lt_dlloader_find}は動作不可能です.成功
 3237: に対し0を返します.
 3238: 
 3239: @example
 3240: @{
 3241:   /* Make myloader be the last one. */
 3242:   if (lt_dlloader_add (NULL, myloader) != 0)
 3243:     perror (lt_dlerror ());
 3244: @}
 3245: @end example
 3246: @end deftypefun
 3247: 
 3248: @deftypefun int lt_dlloader_remove (@w{const char *@var{loader_name}})
 3249: ユニークな名前@var{loader_name}で識別されているローダを削除します.これ
 3250: が成功可能となる前に,指名されたローダにより開かれている全てのモジュール
 3251: を,閉じておく必要があります.成功に対し0を返し,それ以外では,エラーメッ
 3252: セージが@code{lt_dlerror}から取得可能です.
 3253: 
 3254: @example
 3255: @{
 3256:   /* Remove myloader. */
 3257:   if (lt_dlloader_remove ("myloader") != 0)
 3258:     perror (lt_dlerror ());
 3259: @}
 3260: @end example
 3261: @end deftypefun
 3262: 
 3263: @deftypefun {lt_dlloader *}lt_dlloader_next (@w{lt_dlloader *@var{place}})
 3264: ローダモジュール全体を繰り返し,それは,@var{place}が@code{NULL}の場合は
 3265: 最初のローダを返し,順番に次を呼び出すことで行います.ハンドルは,
 3266: @code{lt_dlloader_add}用です.
 3267: 
 3268: @example
 3269: @{
 3270:   /* Make myloader be the first one. */
 3271:   if (lt_dlloader_add (lt_dlloader_next (NULL), myloader) != 0)
 3272:     return ERROR;
 3273: @}
 3274: @end example
 3275: @end deftypefun
 3276: 
 3277: @deftypefun {lt_dlloader *}lt_dlloader_find (@w{const char *@var{loader_name}})
 3278: @var{loader_name}識別子に一致する最初のローダを返し,識別子が見つからな
 3279: い場合は@code{NULL}を返します.
 3280: 
 3281: libltdl自身で使用可能な識別子は,ホストアーキテクチャがサポートしている
 3282: 場合は@dfn{dlopen}@footnote{これは,モジュールをロードしている@sc{api} 
 3283: に依存します -- 例えば,@code{shl_load}と@code{LoadLibrary}です},
 3284: @dfn{dld},そして@dfn{dlpreload}です.
 3285: 
 3286: @example
 3287: @{
 3288:   /* Add a user loader as the next module loader to be tried if
 3289:      the standard dlopen loader were to fail when lt_dlopening. */
 3290:   if (lt_dlloader_add (lt_dlloader_find ("dlopen"), myloader) != 0)
 3291:     return ERROR;
 3292: @}
 3293: @end example
 3294: @end deftypefun
 3295: 
 3296: @deftypefun {const char *}lt_dlloader_name (@w{lt_dlloader *@var{place}})
 3297: @code{lt_dlloader_next}や@code{lt_dlloader_find}で取得される,
 3298: @var{PLACE}の識別名を返します.この関数が失敗する場合,@code{NULL}を返し,
 3299: @code{lt_dlerror}で回収するためのエラーを設定します.
 3300: @end deftypefun
 3301: 
 3302: @deftypefun {lt_user_data *}lt_dlloader_data (@w{lt_dlloader *@var{place}})
 3303: @code{lt_dlloader_next}や@code{lt_dlloader_find}で取得される,
 3304: @var{PLACE}のアドレスを返します.この関数が失敗する場合,@code{NULL}を返
 3305: し,@code{lt_dlerror}で回収するためのエラーを設定します.
 3306: @end deftypefun
 3307: 
 3308: 
 3309: @subsection ユーザモジュールローダでのエラー処理
 3310: 
 3311: @deftypefun int lt_dladderror (@w{const char *@var{diagnostic}})
 3312: この関数で,独自のエラーメッセージを@code{lt_dlerror}に組み込むことが可
 3313: 能となります.@code{lt_dlerror}で返すための適切な診断メッセージに渡すも
 3314: のと,@code{lt_dlseterror}で使用されるエラー識別子が返されます.
 3315: 
 3316: 識別子の割り当てが失敗した場合,この関数は-1を返します.
 3317: 
 3318: @example
 3319: int myerror = lt_dladderror ("Doh!");
 3320: if (myerror < 0)
 3321:   perror (lt_dlerror ());
 3322: @end example
 3323: @end deftypefun
 3324: 
 3325: @deftypefun int lt_dlseterror (@w{int @var{errorcode}})
 3326: 独自のモジュールローダを書くとき,@code{lt_dlerror}インターフェースを通
 3327: じて伝搬されるようにエラーを発生させるために,この関数を使用すべきです.
 3328: libltdlで使用される標準エラーの全ては,@file{ltdl.h}で宣言されていて,そ
 3329: うでなければ,@code{lt_dladderror}を用いて独自に書き加えることが可能です.
 3330: 
 3331: @example
 3332: if (lt_dlseterror (LTDL_ERROR_NO_MEMORY) != 0)
 3333:   perror (lt_dlerror ());
 3334: @end example
 3335: @end deftypefun
 3336: 
 3337: 
 3338: @node Distributing libltdl
 3339: @section パッケージとともにlibltdlを配布する方法
 3340: 
 3341: libltdlはlibtoolとともにインストールされるのですが,libtoolやlibltdlをイ
 3342: ンストールしていないパッケージユーザの利便性のため,パッケージの配布物に
 3343: libltdlを含めたいと思うかもしれません.この場合,手動でパッケージに加え
 3344: る@code{ltdl}オブジェクト,または,使用したいlibltdlの特色を決定する必要
 3345: があります.それは,便利なライブラリやインストール可能なlibtoolライブラ
 3346: リです.
 3347: 
 3348: @code{libltdl}をッケージに加える最も簡単な方法は,ソースファイルの
 3349: @file{ltdl.c}と@file{ltdl.h}をパッケージのソースディレクトリにコピーし,
 3350: ソースの残りと一緒にリンクすることです.これの手助けをするため,autoconf 
 3351: のm4マクロが@file{ltdl.m4}で利用可能です.autoconfを実行する前に,それら
 3352: が@file{aclocal.m4}で利用可能かどうかを確かめる必要があります --
 3353: automakeを使用している場合は@file{ltdl.m4}の内容を@file{acinclude.m4}に
 3354: 加え,そうでない場合は@file{aclocal.m4}に加えます.マクロを利用可能にし
 3355: た後,@file{ltdl.o}を正しくビルドするために必要なコンフィグレーション時
 3356: の調査を実行するため,@samp{AC_LIB_LTDL}マクロの呼び出しを,パッケージの
 3357: @file{configure.in}に加える必要があります.インストールされているlibltdl 
 3358: やlibltdlに依存しているライブラリと,パケージのバイナリをリンクしようと
 3359: する場合,この手法には問題があります.シンボルの二重定義の問題があるかも
 3360: しれません.
 3361: 
 3362: 便利なライブラリの利点の一つは,インストールされていないということなので,
 3363: libtoolを使用するという事実はユーザにとって明白ではなく,ユーザが以前に
 3364: インストールしているlibtoolのバージョンを上書きしません.一方,(例えば,
 3365: バグフィックスといった)理由があり,libltdlをアップグレードしたい場合,イ
 3366: ンストールされているバージョンのlibtoolを置き換える代わりに,パッケージ
 3367: を再コンパイルする必要があります.しかし,プログラムやライブラリが以前に
 3368: インストールされているバージョンのlibltdlを使用しているライブラリとリン
 3369: クする場合,リンカエラーが発生し実行時にクラッシュするかもしれません.も
 3370: う一つの問題は,一つ以上のlibtoolライブラリへ便利なライブラリをリンクで
 3371: きないことで,複製されたシンボルを得る可能性があるので,そのときは,これ
 3372: らのライブラリを用いた単一のプログラムとリンクしてください.一般的に,
 3373: libtoolを使用している他のライブラリに依存しないプログラムでは,便利なラ
 3374: イブラリを問題なく使用可能です.libltdlのこの特徴を利用可能にするため,
 3375: @samp{AC_LIBLTDL_CONVENIENCE}行を@file{configure.in}に,
 3376: @samp{AC_PROG_LIBTOOL}の@emph{前に}加えた方が良いでしょう.
 3377: 
 3378: インストール可能なバージョンのlibltdlを選択するために,マクロ
 3379: @samp{AC_LIBLTDL_INSTALLABLE}の呼び出しを@file{configure.in}に,
 3380: @samp{AC_PROG_LIBTOOL}の@emph{前に}加えた方が良いでしょう.このマクロは,
 3381: libltdlが既にインストールされているかどうか調査し,そうでない場合,ビル
 3382: ドしインストールされるパッケージlibltdlを埋め込むことを要求します.しか
 3383: し,バージョン調査は実行されないことに注意してください.ユーザは,コンフィ
 3384: グレーションスイッチ@samp{--enable-ltdl-install}を使用することで,他のバー
 3385: ジョンの存在に関係なく,テストを優先し,埋め込まれたlibtoolをインストー
 3386: ルする必要があるか決定することができます.
 3387: 
 3388: libtoolをパッケージに埋め込むため,@code{libtoolize}コマンドラインに
 3389: @samp{--ltdl}のみ加えてください.それで,パッケージのサブディレクトリ
 3390: @samp{libltdl}にlibtoolのソースをコピーします.どちらのマクロも,
 3391: @samp{libltdl}ディレクトリの位置を指定する追加の引数を受け入れます.デフォ
 3392: ルトで,どちらのマクロも@samp{$@{top_srcdir@}/libltdl}を仮定します.
 3393: 
 3394: どのマクロを使用しても,@file{configure.in}は@samp{AC_CONFIG_SUBDIRS}を
 3395: 使用して,libltdlをコンフィグレーションし,@file{Makefile}が,例えば,
 3396: automakeの@var{SUBDIRS}を使用して,libtoolのディレクトリでサブmakeを開始
 3397: することを確実にするのはあなたです.どちらのマクロも,libltdlでリンクす
 3398: るために使用するリンクフラグのシェル変数@var{LIBLTDL}と,@file{ltdl.h}を
 3399: インクルードするプログラムをコンパイルするために使用するプリプロセッサフ
 3400: ラグ@var{INCLTDL}を定義します.この変数が@file{Makefile}で利用可能にする
 3401: ことを確実にするため@samp{AC_SUBST}を使用したり,デフォルトで
 3402: @samp{AC_SUBST}される,@var{LIBS}と@var{CPPFLAGS}のような変数に加えるの
 3403: はあなた次第です.
 3404: 
 3405: 便利なlibltdlを使用している場合,@var{LIBLTDL}は便利なlibltdlのバージョ
 3406: ンに対するパス名で,@var{INCLTDL}はlibltdlを含むディレクトリが続く
 3407: @samp{-I}になり,どちらも@samp{$@{top_builddir@}/},または,
 3408: @samp{$@{top_srcdir@}/}で,それぞれ始まります.
 3409: 
 3410: インストールされているlibltdlのバージョンを要求し,それが見つかった場合
 3411: @footnote{たとえ,libltdlがインストールされていても,libltdlがCライブラ
 3412: リ以外のライブラリが提供するシンボルに依存する場合,
 3413: @samp{AC_LIBLTDL_INSTALLABLE}は検出に失敗する可能性があります.この場合,
 3414: libltdlのビルドとインストールは不必要です.},@var{LIBLTDL}は
 3415: @samp{-lltdl} に,@var{INCLTDL}は空に設定されます(それは,libltdlがライ
 3416: ブラリパスにある場合,@file{ltdl.h}がインクルードパスのどこかにあるとい
 3417: う,暗黙の仮定です).インストール可能なlibltdlのバージョンをビルドする必
 3418: 要がある場合,@samp{$@{top_builddir@}/}で始まるそのパス名は,
 3419: @var{LIBLTDL}に保存され,@var{INCLTDL}は便利なライブラリの場合と同様に設
 3420: 定されます.
 3421: 
 3422: そのため,libltdlとプログラムをリンクしたいときは,それをインストールさ
 3423: れたまたはインストール可能な便利なライブラリにし,すなわち,libtoolを使
 3424: 用して,@samp{$(INCLTDL)}を用いてコンパイルし,@samp{$(LIBLTDL)}を用いて
 3425: リンクしてください.
 3426: 
 3427: おそらく@samp{AC_LIBTOOL_DLOPEN}も@file{configure.in}に,
 3428: @samp{AC_PROG_LIBTOOL}の@emph{前に}加えた方が良く,そうしない場合は,
 3429: libtoolはdlopenメカニズムがサポートされていないと仮定し,おそらく希望し
 3430: ていないdlpreopenに逆戻りします.
 3431: 
 3432: libltdlとプログラムをリンクするとき,@code{-static}や@code{-all-static} 
 3433: スイッチの使用を避けてください.dlopen関数はスタティックリンクに対して利
 3434: 用可能でない可能性があるので,これはすべてのプラットフォームで動作するわ
 3435: けではありません.
 3436: 
 3437: 以下の例は,パッケージに便利なlibltdlを埋め込む方法を示します.インストー
 3438: ル可能な形態を使用するために,@samp{AC_LIBLTDL_CONVENIENCE}を
 3439: @samp{AC_LIBLTDL_INSTALLABLE}で置換してください.我々は,libltdlが
 3440: @samp{libtoolize --ltdl}を使用して埋め込まれていると仮定しています.
 3441: 
 3442: configure.inは以下のようになります.
 3443: @example
 3444: ...
 3445: dnl Enable building of the convenience library
 3446: dnl and set LIBLTDL accordingly
 3447: AC_LIBLTDL_CONVENIENCE
 3448: dnl Substitute INCLTDL and LIBLTDL in the Makefiles
 3449: AC_SUBST(INCLTDL)
 3450: AC_SUBST(LIBLTDL)
 3451: dnl Check for dlopen support
 3452: AC_LIBTOOL_DLOPEN
 3453: dnl Configure libtool
 3454: AC_PROG_LIBTOOL
 3455: dnl Configure libltdl
 3456: AC_CONFIG_SUBDIRS(libltdl)
 3457: ...
 3458: @end example
 3459: 
 3460: Makefile.amは以下のようになります.
 3461: @example
 3462: ...
 3463: SUBDIRS = libltdl
 3464: 
 3465: INCLUDES = $(INCLTDL)
 3466: 
 3467: myprog_LDFLAGS = -export-dynamic
 3468: # The quotes around -dlopen below fool automake <= 1.4 into accepting it
 3469: myprog_LDADD = $(LIBLTDL) "-dlopen" self "-dlopen" foo1.la
 3470: myprog_DEPENDENCIES = $(LIBLTDL) foo1.la
 3471: ...
 3472: @end example
 3473: 
 3474: 
 3475: @node Other languages
 3476: @chapter 他の言語でlibtoolを使用する
 3477: @cindex C, not using
 3478: @cindex languages, non-C
 3479: @cindex C++, using
 3480: 
 3481: libtoolは最初に,C言語での共有ライブラリを書くことに対するサポートを加え
 3482: るために実装されました.しかし,時間が経ち,プログラマが好みのプログラム
 3483: 言語での共有ライブラリの便利さを自由に得られるように,libtoolは他の言語
 3484: と統合されています.
 3485: 
 3486: この章は,libtoolが他の言語と相互作用する方法と,Cを用いない場合に必要と
 3487: される特記事項を記述します.
 3488: 
 3489: @menu
 3490: * C++ libraries::
 3491: @end menu
 3492: 
 3493: @node C++ libraries
 3494: @section C++に対するライブラリを書く
 3495: @c FIXME: in the TOC, the ++ is too large (seems to be math mode)
 3496: @cindex trouble with C++
 3497: @cindex pitfalls using C++
 3498: @cindex C++, pitfalls
 3499: 
 3500: C++コードのライブラリを作成することは,そのオブジェクトファイルがCのもの
 3501: と3つの点で異なっているだけので,かなり簡単な処理になります.
 3502: 
 3503: @enumerate 1
 3504: @item
 3505: 名前をmangleするため,C++ライブラリはC++コンパイラで作成されたものだけ利
 3506: 用可能です.この決定は,コンストラクタ,例外処理,そしてRTTIのような機能
 3507: の実装との衝突からユーザを守るため,C++の設計者によってなされました.
 3508: 
 3509: @item
 3510: システムによっては,ダイナミックリンカが動的(すなわち実行時)に初期化の実
 3511: 行するため,C++コンパイラは特別な動作を行なう必要があります.これは,そ
 3512: のようなライブラリとリンクするため,@file{ld}を直接呼び出すべきではなく,
 3513: その代わりにC++コンパイラを使用するべきだということを意味します.
 3514: 
 3515: @item
 3516: C++コンパイラは,いくつかの標準C++ライブラリとデフォルトでリンクしますが,
 3517: libtoolは,これらのライブラリがどれかを知らないため,それに対してリンク
 3518: する方法を調査するため,ライブラリ内部の依存の解析さえ実行できません.そ
 3519: れゆえ,C++プログラムやライブラリとリンクするため@file{ld}を実行すると失
 3520: 敗すると思われます.しかし,C++コンパイラを直接実行することは,ライブラ
 3521: リ内部の依存に関係する問題を生じる可能性があります.
 3522: @end enumerate
 3523: 
 3524: 結論として,libtoolはC++ライブラリに対する一般的な使用のための準備ができ
 3525: ていません.標準Cコンパイラでコンパイルする場合は,``初期化要素は一定で
 3526: はない''というエラーの原因となる,あらゆるグローバルまたはスタティック変
 3527: 数の初期化を避けるべきです.
 3528: 
 3529: この問題に関して動作する他の方法もありますが,それらはこのマニュアルの範
 3530: 囲を越えています.
 3531: 
 3532: さらに,C++コンパイラがデフォルトでリンクするC++標準ライブラリと,リンク
 3533: コマンドラインの明示的なリストは,コンフィグレーション時に分かった方が良
 3534: いでしょう.たぶん将来,libtoolはこの仕事を単独で可能となるでしょう.
 3535: 
 3536: 
 3537: @node Troubleshooting
 3538: @chapter トラブルシューティング
 3539: @cindex troubleshooting
 3540: @cindex problems, solving
 3541: @cindex solving problems
 3542: @cindex problems, blaming somebody else for
 3543: 
 3544: libtoolは,現在のオペレーティングシステムで最新を保つよう変更しながら,
 3545: コンスタントに開発されていています.libtoolがプラットフォーム上で思った
 3546: ように動作しない場合,問題点と解決方法を決定する助けとなる,この章を読ん
 3547: だ方が良いでしょう.
 3548: 
 3549: @menu
 3550: * Libtool test suite::          Libtool's self-tests.
 3551: * Reporting bugs::              How to report problems with libtool.
 3552: @end menu
 3553: 
 3554: @node Libtool test suite
 3555: @section libtoolのテストスイート
 3556: @cindex test suite
 3557: 
 3558: libtoolは,その能力をテストし,libtoolプログラムの明らかなバグを報告する,
 3559: プログラムの独自のセットとともにあります.これらのテストは,libtoolの過
 3560: 去の問題と他のオペレーティングシステム内の既知の欠陥を基にして,絶えず進
 3561: 化もしています.
 3562: 
 3563: @file{INSTALL}ファイルに記述されているように,libtoolのビルド後,基本的
 3564: な機能要求に合っていることを確めるために,@kbd{make check}を実行すること
 3565: が可能です.
 3566: 
 3567: @menu
 3568: * Test descriptions::           The contents of the test suite.
 3569: * When tests fail::             What to do when a test fails.
 3570: @end menu
 3571: 
 3572: @node Test descriptions
 3573: @subsection テストスイートの記述
 3574: 
 3575: テストスイートの現在のプログラムと,それらがテストするもののリストは以下
 3576: のようになっています.
 3577: 
 3578: @table @file
 3579: 
 3580: @item cdemo-conf.test
 3581: @itemx cdemo-exec.test
 3582: @itemx cdemo-make.test
 3583: @itemx cdemo-static.test
 3584: @itemx cdemo-shared.test
 3585: @pindex cdemo-conf.test
 3586: @pindex cdemo-exec.test
 3587: @pindex cdemo-make.test
 3588: @pindex cdemo-static.test
 3589: @pindex cdemo-shared.test
 3590: これらのプログラムは,libtool配布物の@file{cdemo}サブディレクトリが,正
 3591: しくコンフィグレーションされ,ビルドされることを知るために調査します.
 3592: 
 3593: @file{cdemo}サブディレクトリは,libtoolの便利なライブラリのデモンストレー
 3594: ションと,ビルド時にスタティックライブラリの作成を可能とするメカニズムを
 3595: 含んでいて,コンポーネントが共有ライブラリであったとしても,プログラムや
 3596: 他のライブラリと遅れてリンクされることを可能とする方法です.
 3597: 
 3598: @file{cdemo-make.test}と@file{cdemo-exec.test}のテストは,3つの異なる
 3599: libtoolコンフィグレーションで,3回実行されます.@file{cdemo-conf.test} 
 3600: は,スタティックライブラリと共有ライブラリの両方をビルドするために(両方
 3601: サポートしているプラットフォームではデフォルトです)@file{cdemo/libtool} 
 3602: をコンフィグレーションし,@file{cdemo-static.test}はスタティックライブラ
 3603: リのみビルドし(@samp{--disable-shared}),そして@file{cdemo-shared.test} 
 3604: は共有ライブラリのみビルドします(@samp{--disable-static}).
 3605: 
 3606: @item demo-conf.test
 3607: @itemx demo-exec.test
 3608: @itemx demo-inst.test
 3609: @itemx demo-make.test
 3610: @itemx demo-unst.test
 3611: @itemx demo-static.test
 3612: @itemx demo-shared.test
 3613: @itemx demo-nofast.test
 3614: @itemx demo-pic.test
 3615: @itemx demo-nopic.test
 3616: @pindex demo-conf.test
 3617: @pindex demo-exec.test
 3618: @pindex demo-inst.test
 3619: @pindex demo-make.test
 3620: @pindex demo-unst.test
 3621: @pindex demo-static.test
 3622: @pindex demo-shared.test
 3623: @pindex demo-nofast.test
 3624: @pindex demo-pic.test
 3625: @pindex demo-nopic.test
 3626: これらのプログラムは,libtool配布物の@file{demo}サブディレクトリが,コン
 3627: フィグレーション,ビルド,インストール,そしてアンインストールが正しくで
 3628: きることを知るために調査します.
 3629: 
 3630: @file{demo}サブディレクトリは,libtoolを使用する平凡なパッケージのデモン
 3631: ストレーションを含みます.テストの@file{demo-make.test},
 3632: @file{demo-exec.test},@file{demo-inst.test},そして
 3633: @file{demo-unst.test}は,4つの異なるlibtoolのコンフィグレーションの下で,
 3634: 4回実行されます.@file{demo-conf.test}は,スタティックと共有の両方のラ
 3635: イブラリをビルドするために@file{demo/libtool}をコンフィグレーションし,
 3636: @file{demo-static.test}は,スタティックライブラリのみビルドし
 3637: (@samp{--disable-shared}),そして@file{demo-shared.test}は,共有ライブラ
 3638: リのみをビルドします(@samp{--disable-static}).@file{demo-nofast.test}は,
 3639: 高速インストールモードを使用禁止にするために
 3640: (@samp{--enable-fast-install=no}),@file{demo/libtool}をコンフィグレーショ
 3641: ンします.@file{demo-pic.test}は,PICコードをビルドしたいときは
 3642: (@samp{--with-pic}),非PICコードをビルドしたいときは
 3643: (@samp{--without-pic}) にするように,@file{demo/libtool}をコンフィグレー
 3644: ションします.
 3645: 
 3646: @item deplibs.test
 3647: @pindex deplibs.test
 3648: スタティックライブラリを共有ライブラリにリンク不可能なシステムもたくさん
 3649: あります.そのような場合を避けるため,libtoolは
 3650: @code{deplibs_check_method}を使用します.このテストは,libtoolの
 3651: @code{deplibs_check_method}が正しく動作するかどうか調査します.
 3652: 
 3653: @item hardcode.test
 3654: @pindex hardcode.test
 3655: 共有ライブラリを持つすべてのシステムで,実行形式に対しリンクされるライブ
 3656: ラリの位置が実行形式の内部に符号化されるはずです@pxref{Linking
 3657: executables}.このテストは,システムリンカがライブラリの位置をハードコー
 3658: ドし,libtool自身のリンカの動作方法の概念と一致することを保証する条件を
 3659: 調査します.
 3660: 
 3661: @item build-relink.test
 3662: @pindex build-relink.test
 3663: 変数@var{shlibpath_overrides_runpath}が正しく設定されているかどうか調査
 3664: します.テストが失敗し,@var{VERBOSE}が設定されている場合,それは変数を
 3665: 設定する必要がないことを示します.
 3666: 
 3667: @item noinst-link.test
 3668: @pindex noinst-link.test
 3669: libtoolが,たった今ビルドされたライブラリにリンクする方が良い時,以前に
 3670: インストールされているバージョンにリンクしようとしないかどうか調査します.
 3671: 
 3672: @item depdemo-conf.test
 3673: @itemx depdemo-exec.test
 3674: @itemx depdemo-inst.test
 3675: @itemx depdemo-make.test
 3676: @itemx depdemo-unst.test
 3677: @itemx depdemo-static.test
 3678: @itemx depdemo-shared.test
 3679: @itemx depdemo-nofast.test
 3680: @pindex depdemo-conf.test
 3681: @pindex depdemo-exec.test
 3682: @pindex depdemo-inst.test
 3683: @pindex depdemo-make.test
 3684: @pindex depdemo-unst.test
 3685: @pindex depdemo-static.test
 3686: @pindex depdemo-shared.test
 3687: @pindex depdemo-nofast.test
 3688: これらのプログラムは,libtool配布物の@file{depdemo}サブディレクトリの,
 3689: コンフィグレーション,ビルド,インストール,そしてアンインストールを,正
 3690: しく行えることを判定するための調査を行います.
 3691: 
 3692: @file{depdemo}サブディレクトリは,libtoolに依存する内部ライブラリのデモ
 3693: ンストレーションを含みます.このテストプログラムは,いくつかの交互依存し
 3694: ているライブラリをリンクします.
 3695: 
 3696: テストの,@file{depdemo-make.test},@file{depdemo-exec.test},
 3697: @file{depdemo-inst.test},そして@file{depdemo-unst.test}は,4つの異なる
 3698: libtoolのコンフィグレーションの下で,4回実行されます.
 3699: @file{depdemo-conf.test}は,スタティックと共有の両方のライブラリをビルド
 3700: するために,@file{depdemo/libtool}をコンフィグレーションし,
 3701: @file{depdemo-static.test}はスタティックライブラリのみビルドし
 3702: (@samp{--disable-shared}),@file{depdemo-shared.test}は共有ライブラリの
 3703: みビルドします(@samp{--disable-static}).@file{depdemo-nofast.test}は高
 3704: 速インストールモード(@samp{--enable-fast-install=no})を利用不可能にする
 3705: ために,@file{depdemo/libtool}をコンフィグレーションします.
 3706: 
 3707: @item mdemo-conf.test
 3708: @itemx mdemo-exec.test
 3709: @itemx mdemo-inst.test
 3710: @itemx mdemo-make.test
 3711: @itemx mdemo-unst.test
 3712: @itemx mdemo-static.test
 3713: @itemx mdemo-shared.test
 3714: @pindex mdemo-conf.test
 3715: @pindex mdemo-exec.test
 3716: @pindex mdemo-inst.test
 3717: @pindex mdemo-make.test
 3718: @pindex mdemo-unst.test
 3719: @pindex mdemo-static.test
 3720: @pindex mdemo-shared.test
 3721: これらのプログラムは,libtool配布物の@file{mdemo}サブディレクトリが,コ
 3722: ンフィグレーション,ビルド,インストール,そしてアンインストールが正しく
 3723: できることを知るために調査します.
 3724: 
 3725: @file{mdemo}サブディレクトリは,libtoolと,システム非依存のモジュールロー
 3726: ドのための,dlopenラッパー@file{libltdl}を使用するパッケージのデモンスト
 3727: レーションを含みます.ライブラリ@file{libltdl}は,様々なプラットフォーム
 3728: (Linux,Solaris,HP/UX等)に対する,dlpreopenモジュールに対するサポートを
 3729: 含む(@pxref{Dlpreopening})dlopenラッパーを提供します.
 3730: 
 3731: テストの@file{mdemo-make.test},@file{mdemo-exec.test},
 3732: @file{mdemo-inst.test},そして@file{mdemo-unst.test}は,3つの異なる
 3733: libtoolのコンフィグレーションの下で,3回実行されます.
 3734: @file{mdemo-conf.test}は,スタティックと共有の両方のライブラリをビルドす
 3735: るために@file{mdemo/libtool}をコンフィグレーションし,
 3736: @file{mdemo-static.test}は,スタティックライブラリのみビルドし
 3737: (@samp{--disable-shared}),そして@file{mdemo-shared.test}は,共有ライブ
 3738: ラリのみをビルドします(@samp{--disable-static}).
 3739: 
 3740: @item dryrun.test
 3741: @pindex dryrun.test
 3742: このテストは,libtoolの@code{--dry-run}モードが正しく働くかどうかを調査
 3743: します.
 3744: 
 3745: @item assign.test
 3746: @pindex assign.test
 3747: libtoolスクリプト内の割り当てられている同じ行で,停止したり,続けたりし
 3748: ないかどうか調査します.
 3749: 
 3750: @item link.test
 3751: @pindex link.test
 3752: このテストは,libtoolでないスタティックライブラリに対する直接的なリンク
 3753: が正しく動作することを保証します.
 3754: 
 3755: @item link-2.test
 3756: @pindex link-2.test
 3757: このテストは,@samp{.lo}で終わるファイルがプログラムファイルに直接リンク
 3758: されないことを確かめます.
 3759: 
 3760: @item nomode.test
 3761: @pindex nomode.test
 3762: 実際にlibtoolの助けが可能かどうか調査します.
 3763: 
 3764: @item quote.test
 3765: @pindex quote.test
 3766: このプログラムはlibtoolのメタ文字を引用符で囲むことを調査します.
 3767: 
 3768: @item sh.test
 3769: @pindex sh.test
 3770: `test'コマンドがlibtoolに忘れていないか調査します.
 3771: 
 3772: @item suffix.test
 3773: @pindex suffix.test
 3774: 他のプログラミング言語がlibtoolで使用されるとき(@pxref{Other languages}),
 3775: ソースファイルは@samp{.c}以外の接尾子で終わるかもしれません.このテスト
 3776: は,サポートするすべてのファイル形式に対する接尾子を扱うこと可能で,接尾
 3777: 子が不当なときは失敗することを確認します.
 3778: 
 3779: @end table
 3780: 
 3781: @node When tests fail
 3782: @subsection テストが失敗するとき
 3783: @cindex failed tests
 3784: @cindex tests, failed
 3785: 
 3786: 上記のそれぞれのテストは,@kbd{make check}を実行するとき出力を生成しない
 3787: ように設計されています.それぞれのプログラムの終了ステータスで,テストが
 3788: 成功しなかったかどうかを@file{Makefile}に伝えます.
 3789: 
 3790: テストが失敗した場合,それはlibtool内のプログラムエラー,またはプログラ
 3791: ム自身のエラーのどちらかが存在することを意味します.
 3792: 
 3793: 特定のテストを調査するために,通常のプログラムで行うように,直接実行する
 3794: ことが可能です.テストがこの方法で呼び出されたとき,それは,問題を決定す
 3795: るのに役に立ちそうな出力を生成します.
 3796: 
 3797: テストプログラムに出力を生成させるもうひとつの方法は,実行前に
 3798: @var{VERBOSE}環境変数を@samp{yes}に設定することです.例えば,@kbd{env
 3799: VERBOSE=yes make check}ですべてのテストが実行され,それぞれについてデバッ
 3800: グ情報の表示が得られます.
 3801: 
 3802: 
 3803: @node Reporting bugs
 3804: @section バグの報告
 3805: @cindex bug reports
 3806: @cindex reporting bugs
 3807: @cindex problem reports
 3808: 
 3809: libtoolにバグを発見したと考えた場合,もう一度考えた直したほうが良いでしょ
 3810: う.libtool管理者は,責任転嫁(または``バグを通過させる''かもしれません)
 3811: で有名です@footnote{訳注:原文では,passing the buck(責任転嫁)とpassing
 3812: the bug(バグを通過させる)をかけています}.libtoolは,共有ライブラリの実
 3813: 装で既知の欠陥を修正するために開発されたので,libtoolのバグのほとんどは,
 3814: ある程度は,他のオペレーティングシステムのバグになります.しかし,
 3815: libtool の管理者は,他人のバギーなオペレーティングシステムに対するサポー
 3816: トを加えることを,確かに楽しんでいます.[Texinfoでウインクしている笑顔を
 3817: 表示する,いい方法があれば良いのですが.]
 3818: 
 3819: libtoolの純粋なバグは,シェルスクリプトの移植性の問題,ドキュメントのエ
 3820: ラー,そしてテストスイートの失敗(@pxref{Libtool test suite})を含みます.
 3821: 
 3822: 最初に,問題と考えられる動作が,既に特徴として言及されていないことを確か
 3823: めるために,ドキュメントとへルプ画面を調査してください.
 3824: 
 3825: そして,バグを報告することに関するEmacsガイド(@pxref{Bugs, , Reporting
 3826: Bugs, emacs, The Emacs Manual})を読んでください.リストアップされている
 3827: 詳細は,Emacs特有のものもありますが,基本的な原則は一般的なものです.
 3828: 
 3829: 最後に,テストスイートの出力(@pxref{When tests fail}),バグを再生成する
 3830: のに必要なすべての詳細,そして,動作がバグだと考えられる理由の概要のよう
 3831: な適切なあらゆる@emph{事実}とともに,@value{BUGADDR}にバグの報告を送って
 3832: ください.サブジェクト行に,単語``libtool''と,同様に使用しているバージョ
 3833: ンナンバー(それは,@kbd{ltconfig --version}の入力で分かります)が含まれて
 3834: いることを確認してください.
 3835: 
 3836: 
 3837: @node Maintaining
 3838: @chapter libtoolの管理用メモ
 3839: 
 3840: この章は,libtool管理者が見つける重要な情報を含みます.新しいシステムへ
 3841: の移植や,独自のlibtoolを書くことを考慮しない場合,役に立たないでしょう.
 3842: 
 3843: @menu
 3844: * New ports::                   How to port libtool to new systems.
 3845: * Tested platforms::            When libtool was last tested.
 3846: * Platform quirks::             Information about different library systems.
 3847: * libtool script contents::     Configuration information that libtool uses.
 3848: * Cheap tricks::                Making libtool maintainership easier.
 3849: @end menu
 3850: 
 3851: @node New ports
 3852: @section 新しいシステムへのlibtoolの移植
 3853: 
 3854: サポートされていないシステムへのlibtoolの移植に乗り出す前に,既存の仕事
 3855: と重複していないことを確認するために,@value{MAILLIST}に電子メールを送る
 3856: 価値はあります.
 3857: 
 3858: 移植の文章が見つからない場合,文句を言ってください! パッチを用いた苦情
 3859: と,ドキュメントやlibtool自身の改良は十分に歓迎されます.
 3860: 
 3861: @menu
 3862: * Information sources::         Where to find relevant documentation
 3863: * Porting inter-library dependencies::  Implementation details explained
 3864: @end menu
 3865: 
 3866: @node Information sources
 3867: @subsection 情報源
 3868: 
 3869: 新たな移植の必要性が明らかになると,通常,以下の情報が必要となります.
 3870: 
 3871: @table @asis
 3872: @item 標準的なシステム名
 3873: 他のシステムに影響しないようにlibtoolのコンフィグレーション処理を変更可
 3874: 能にするため,このシステムに対する@code{config.guess}の出力が必要です.
 3875: 
 3876: @item @code{ld}と@code{cc}に対するmanページ
 3877: 共有ライブラリを作成するため,共有ライブラリのみにリンクするため,そして,
 3878: PICを生成するために使用するフラグを,通常これらは記述しています.必要な
 3879: 情報を見つけるため,以下の相互参照が必要かもしれません.
 3880: 
 3881: @item @code{ld.so},@code{rtld},または,その同等物のmanページ
 3882: これらは,システムで共有ライブラリがロードされる仕組みを理解するための,
 3883: 有益な情報源です.
 3884: 
 3885: @item @code{ldconfig}やその同等物のmanページ
 3886: このページは,通常,共有ライブラリをインストールする方法を記述します.
 3887: 
 3888: @item @kbd{ls -l /lib /usr/lib}の出力
 3889: これは,システムの共有ライブラリの命名規則を表示し,それは,シンボリック
 3890: リンクの名前も含んでいます.
 3891: 
 3892: @item あらゆる追加の文章
 3893: 共有ライブラリの構築とインストール方法の特別な文章があるシステムもありま
 3894: す.
 3895: @end table
 3896: 
 3897: Bourneシェルプログラムの方法を知っている場合,完全に自分で移植することが
 3898: 可能です.それ以外の場合,関連する作業を行う腕のある人を探す必要がありま
 3899: す.libtoolメーリングリストの人々は,新たな移植への援助を志願する意思が
 3900: あるので,彼らに情報を送ることができます.
 3901: 
 3902: 独自に移植するためには,プラットフォーム特有のコンフィグレーションプロセ
 3903: スの変更を行うため,@code{libtool.m4}マクロを明確に修正する必要がありま
 3904: す.@code{PORTME}キーワードに対するファイルを検索する必要があり,それで,
 3905: 変更に必要なヒントを得られるでしょう.一般的に,呼び出されるものは,適切
 3906: なコンフィグレーション変数の編集です(@pxref{libtool script contents}).
 3907: 
 3908: 最善策は,既にサポートされている良く似たシステムを見つけ,変更の基本とす
 3909: ることです.しかし,システムが他のサポートされているシステムと,大きく異
 3910: なる場合や,新しいコンフィグレーション変数を加え,それに応じて
 3911: @code{ltmain.in}スクリプトを変更する必要がある場合もあります.欲しいもの
 3912: を達成するための,最も効果的な方法の助言がある可能性があるので,
 3913: @code{ltmain.in}を変更する前に,メーリングリストに書いて確認してください.
 3914: 
 3915: 
 3916: @node Porting inter-library dependencies
 3917: @subsection ライブラリ内部の依存性のサポートの移植
 3918: @cindex inter-library dependency
 3919: @vindex deplibs_check_method
 3920: 
 3921: バージョン1.2c以降,libtoolは,Toshio Kuratomi
 3922: @email{badger@@prtr-13.ucsc.edu}のパッチのおかげで,ライブラリ内部の依存
 3923: 性を可能とする機能が再導入されてるプラットフォームもあります.パッチに含
 3924: まれるメッセージの短いバージョンは以下のようになります.
 3925: 
 3926: 基本的な体系はこのようになります.@file{libtool.m4}で,libtoolを書いてい
 3927: る人は,@samp{$deplibs}が@samp{$archive_cmds}のどこかに含まれていること,
 3928: また,変数@samp{$deplibs_check_method}と,@samp{deplibs_check_method}が
 3929: ファイルマジックの場合は@samp{$file_magic_cmd}が設定されていることを確認
 3930: します.
 3931: 
 3932: @samp{deplibs_check_method}は,以下の5つの内の一つのはずです.
 3933: @table @samp
 3934: @item file_magic [@var{regex}]
 3935: @vindex file_magic
 3936: @vindex file_magic_cmd
 3937: @vindex file_magic_test_file
 3938: ライブラリリンクパスで正しいlibnameを持つライブラリを探します.そして,
 3939: ライブラリで@samp{$file_magic_cmd}を実行し,@code{egrep}を使用した
 3940: @var{regex}に一致することを調査します.@var{file_magic_test_file}が
 3941: @file{libtool.m4}によって設定されているとき,正規表現がその出力と一致す
 3942: るかどうかを検証し,それ以外ではユーザが警告を受けるようにするため,それ
 3943: は@samp{$file_magic_cmd}への引数として使用されます.
 3944: 
 3945: @item test_compile
 3946: @vindex test_compile
 3947: ライブラリリストの出力以外とプログラムがリンク可能かどうかのみを調査し,
 3948: それらが@code{ldd}の出力でリストアップされていることを調査します.それは
 3949: 現在,使用されておらず,将来は打ち切る可能性があります.
 3950: 
 3951: @item pass_all
 3952: @vindex pass_all
 3953: 調査せず,すべて通過します.例えばDEC OSF/1 3 と 4のような,デフォルトで,
 3954: コードが位置に依存せず,ライブラリ内部の依存性がダイナミックリンカで適切
 3955: にサポートされているプラットフォームで,これは動作するでしょう.
 3956: 
 3957: @item none
 3958: @vindex none
 3959: deplibsをdeplibs=""に再設定します.そのように,@samp{archive_cmds}は,す
 3960: べてのプラットフォームでdeplibsを含むはずですが,deplibは必要がなければ
 3961: 使用されません.
 3962: 
 3963: @item unknown
 3964: @vindex unknown
 3965: @file{libtool.m4}で優先されない場合,すべてのシステムでデフォルトです.
 3966: それは@samp{none}と同じですが,正しい値が何か,我々が本当に知らないこと
 3967: を文章化していて,我々はそれを改善するパッチを歓迎します.
 3968: @end table
 3969: 
 3970: @file{ltmain.in}で,我々は本当に一生懸命作業しました.それは,
 3971: (libname_spec等の評価を使用するための変数を設定/リリース行う)小さな初期
 3972: 化と移植,そして使用するメソッドを決定するケース文です.これは,実際には
 3973: コードです...  もう少し凝縮できれば良かったのですが,関数呼び出しを用い
 3974: ずにできるとは思えませんでした.私はほとんどの(ループの外に出す等の)最適
 3975: 化を行いましたが,余分なものがあるかもしれません.明確な最適化を考える前
 3976: に,前進を止め,発見されたバグに対して作業すべきだと考えました.
 3977: 
 3978: 
 3979: @node Tested platforms
 3980: @section テストされたプラットフォーム
 3981: 
 3982: この表は,共有ライブラリのサポートを謡っているプラットフォームで,
 3983: libtoolがテストされたことが分かっている最後の時期を記述しています.
 3984: 
 3985: @example
 3986: @include PLATFORMS-ja
 3987: @end example
 3988: 
 3989: 注:ベンダー配布されているHP-UXの@code{sed}(1)プログラムは,ひどく壊れて
 3990: いて,libtoolの要求を処理することができないため,ユーザは異常の問題を報
 3991: 告する可能性があります.これらのシステムで動作する(GNU @code{sed})のよう
 3992: な@code{sed}をインストールする以外に,回避方法はありません.
 3993: 
 3994: 注:ベンダー配布されているNCR MP-RAS @code{cc}プログラムは,標準エラーに
 3995: 著作権を出力し,@file{conftest.err}の大きさのテストで混乱します.回避方
 3996: 法は,@code{configure}を実行するとき,@kbd{CC='cc -Hnocopyr'}を用いて
 3997: @code{CC} を指定します.
 3998: 
 3999: 
 4000: @node Platform quirks
 4001: @section プラットフォームの癖
 4002: 
 4003: このセクションは,libtoolの管理者の健康に捧げます.それは,libtoolが使用
 4004: するプログラム,システムごとの違い,そしてテストの方法を記述します.
 4005: 
 4006: libtoolはシェルスクリプトなので,最初から最後まで読むだけで理解すること
 4007: は難しいはずです.このセクションは,libtoolが特定の方法で行う理由の理解
 4008: を助けます.スクリプト自身が組み合わされているので,libtoolの改善や,独
 4009: 自に書く方法の,より良いセンスが必要でしょう.
 4010: 
 4011: @menu
 4012: * References::                  Finding more information.
 4013: * Compilers::                   Creating object files from source files.
 4014: * Reloadable objects::          Binding object files together.
 4015: * Multiple dependencies::	Removing duplicate dependant libraries.
 4016: * Archivers::                   Programs that create static archives.
 4017: @end menu
 4018: 
 4019: @node References
 4020: @subsection リファレンス
 4021: 
 4022: 以下は,価値のある文章の参照リストです.
 4023: 
 4024: @itemize @bullet
 4025: @item
 4026: SGIのIRIXのマニュアルページで,それは
 4027: @url{http://techpubs.sgi.com/cgi-bin/infosrch.cgi?cmd=browse&db=man}で見
 4028: つかります.
 4029: 
 4030: @item
 4031: Sunのフリーサービス領域
 4032: (@url{http://www.sun.com/service/online/free.html})とドキュメントサーバ
 4033: (@url{http://docs.sun.com/}).
 4034: 
 4035: @item
 4036: CompaqのTru64 UNIXオンラインドキュメントは
 4037: (@url{http://tru64unix.compaq.com/faqs/publications/pub_page/doc_list.html}) 
 4038: にあり,C++ドキュメントは
 4039: (@url{http://tru64unix.compaq.com/cplus/docs/index.htm})です.
 4040: 
 4041: @item
 4042: Hewlett-Packardは(@url{http://docs.hp.com/index.html})にオンラインドキュ
 4043: メントがあります.
 4044: 
 4045: @item
 4046: IBMは(@url{http://www.rs6000.ibm.com/resource/aix_resource/Pubs/})にオン
 4047: ラインドキュメントがあります.
 4048: @end itemize
 4049: 
 4050: 
 4051: @node Compilers
 4052: @subsection コンパイラ
 4053: 
 4054: libtoolに影響するコンパイラの特徴は,PICオブジェクトを生成するための(存
 4055: 在する場合は)必要なフラグのみです.一般的に,Cコンパイラが特定のPICフラ
 4056: グをサポートする場合,あらゆる派生的なコンパイラは同じフラグをサポートし
 4057: ます.この規則に対し,注目すべき若干の例外があるまでは,このセクションで
 4058: はCコンパイラのみを説明します.
 4059: 
 4060: プラットフォームに関係なく,以下のCコンパイラは,標準のコマンドライオプ
 4061: ションがあります.
 4062: 
 4063: @table @code
 4064: @item gcc
 4065: 
 4066: これはGNU Cコンパイラで,多くのフリーオペレーティングシステム(少し例をあ
 4067: げると,FreeBSD,GNU/Hurd,GNU/Linux,Lites,NetBSD,そしてOpenBSDです)
 4068: に対する,システムコンパイラでもあります.
 4069: 
 4070: @samp{-fpic}や@samp{-fPIC}フラグは,位置に依存しないコードを生成するため
 4071: に使用可能です.@samp{-fPIC}は動作するコードを生成することを保証しますが,
 4072: m68k,m88k,そしてSparcチップ上ではコードは遅くなります.しかし,これら
 4073: のチップで@samp{-fpic}を使用すると,共有ライブラリでの自由なサイズが強制
 4074: 的に制限されます.
 4075: @end table
 4076: 
 4077: このサブセクションの残りは,バンドルされているオペレーティングシステムの
 4078: コンパイラをリストアップします.
 4079: 
 4080: @c FIXME these should all be better-documented
 4081: 
 4082: @table @code
 4083: @item aix3*
 4084: @itemx aix4*
 4085: AIXはPowerPCとRS/6000チップのみに移植されているので,AIXコンパイラはPIC 
 4086: フラグはありません.@footnote{PowerPCとRS/6000チップ(@code{powerpc-*-*},
 4087: @code{powerpcle-*-*},そして@code{rs6000-*-*})に対しコンパイルされている
 4088: すべてのコードは,オペレーティングシステムやコンパイラスイートに関係なく
 4089: 位置に依存しません.そのため,``標準オブジェクト''はこれらのシステムの共
 4090: 有ライブラリの構築で使用され,特別なPICコンパイラフラグは要求されません.}
 4091: 
 4092: @item hpux10*
 4093: PICを生成するために@samp{+Z}を使用してください
 4094: 
 4095: @item osf3*
 4096: Digital/UNIX 3.xは,少なくともPowerPCプラットフォームでなければ,PICフラ
 4097: グはありません.
 4098: 
 4099: @item solaris2*
 4100: PICを生成するために@samp{-KPIC}を使用してください.
 4101: 
 4102: @item sunos4*
 4103: PICを生成するために@samp{-PIC}を使用してください.
 4104: @end table
 4105: 
 4106: 
 4107: @node Reloadable objects
 4108: @subsection リロード可能なオブジェクト
 4109: 
 4110: すべての既知のシステム上で,リロード可能なオブジェクトは@kbd{ld -r -o
 4111: @var{output}.o @var{input1}.o @var{input2}.o}を実行することで生成可能で
 4112: す.このリロード可能なオブジェクトは,他のオブジェクトと完全な同義語とし
 4113: て扱うことが可能です.
 4114: 
 4115: 
 4116: @node Multiple dependencies
 4117: @subsection 複数の依存性
 4118: 
 4119: ほとんどの近代的なプラットフォームでは,依存するライブラリがリストアップ
 4120: される順序はオブジェクトの生成で影響がありません.理論上,シンボルを提供
 4121: しているライブラリの後に,リストアップされている他のライブラリに足りない
 4122: シンボルを提供するライブラリを要求するプラットフォームがあります.
 4123: 
 4124: 特に,一組のスタティックアーカイブのそれぞれが,他のシンボルのいくつかを
 4125: 解決する場合,それらのアーカイブの前後両方に他のものをリストアップするこ
 4126: とが必要かもしれません.複製されたライブラリはリンク行から削除されるので,
 4127: libtoolは,現在この状況に十分に対処していません.
 4128: 
 4129: 正しくリンクされたオブジェクトを生成するために,ライブラリを複数回リスト
 4130: アップすることを要求するホストで開発していることが分かった場合,以下のよ
 4131: うにして,libtoolの除去アルゴリズムを無効にすることが可能です.
 4132: 
 4133: @example
 4134: $ libtool ... -lfoo -lbar -Wl,-lfoo
 4135: @end example
 4136: 
 4137: 
 4138: @node Archivers
 4139: @subsection アーカイバ
 4140: 
 4141: すべての既知のシステム上で,スタティックライブラリのビルドは,@kbd{ar
 4142: cru lib@var{name}.a @var{obj1}.o @var{obj2}.o @dots{}}の実行で完成するは
 4143: ずで,そこでは,@samp{.a}ファイルは出力ライブラリで,それぞれの@samp{.o}
 4144: ファイルはオブジェクトファイルです.
 4145: 
 4146: すべての既知のシステム上で,@code{ranlib}という名のプログラムがある場合,
 4147: リンクする前に@kbd{ranlib lib@var{name}.a}コマンドを用いて,作成されるラ
 4148: イブラリを``祝福''するために使用する必要があります.Irixのように,代わり
 4149: に@code{ar ts}を使用するシステムもあります.
 4150: 
 4151: 
 4152: @node libtool script contents
 4153: @section @code{libtool}スクリプトの内容
 4154: @cindex implementation of libtool
 4155: @cindex libtool implementation
 4156: 
 4157: バージョン1.4からは,@code{libtool}スクリプトは@code{configure}によって
 4158: 生成されます(@pxref{Configuring}.以前のバージョンでは,@file{ltconfig} 
 4159: と呼ばれるへルパースクリプトを呼び出すことで,@code{configure}はそれを達
 4160: 成していました.libtoolのバージョン0.7から1.0までは,このスクリプトは,
 4161: 単純にシェル変数を設定し,libtoolのバックエンドの@code{ltmain.sh}の源と
 4162: なっていました.libtoolバージョン1.1から1.3までの@code{ltconfig}は,
 4163: @code{ltmain.sh}の内容を,生成された@code{libtool}にインライン化し,それ
 4164: は多くのシステムでパフォーマンスを改善しました.@file{ltconfig}が実行す
 4165: るために使用するテストは,現在@file{libtool.m4}にあり,そこで我々は
 4166: Autoconfを使用して書くことが可能となっています.これは,インライン化され
 4167: た@code{ltmain.sh}の実行時の動作に有利で,@emph{そして},管理が必要な生
 4168: のシェルコードの量をかなり取り除くことで,構築時間を短くする改善を行いま
 4169: した.
 4170: 
 4171: 後で評価するもの対するシェルコマンドを保持する変数の命名に使用される規則
 4172: は,有効な単一行のシェルスクリプトが必要とされるところで接尾子
 4173: @code{_cmd},複数行のシェルスクリプトが後で評価することが@strong{可能な} 
 4174: ところで接尾子@code{_cmds}を使用することです.規則では,@code{_cmds}変数
 4175: は,必要なところで,@code{~}文字で評価ユニットを区切ります.
 4176: 
 4177: それぞれのコンフィグレーション変数と,@code{ltmain.sh}で使用する方法のリ
 4178: ストは,以下のようになります(@pxref{Configuring}).
 4179: 
 4180: @defvar AR
 4181: システムライブラリアーカイバの名前です.
 4182: @end defvar
 4183: 
 4184: @defvar CC
 4185: libtoolをコンフィグレーションするために使用するCコンパイラの名前です.
 4186: @end defvar
 4187: 
 4188: @defvar LD
 4189: リロード可能にするリンクとおそらく共有ライブラリに対し,libtoolが内部で
 4190: 使用するリンカの名前です.
 4191: @end defvar
 4192: 
 4193: @defvar NM
 4194: BSD互換の@code{nm}プログラムの名前で,それは以下の書式の一つで,大域的な
 4195: シンボルを生成します.
 4196: 
 4197: @example
 4198: @var{address} C @var{global-variable-name}
 4199: @var{address} D @var{global-variable-name}
 4200: @var{address} T @var{global-function-name}
 4201: @end example
 4202: @end defvar
 4203: 
 4204: @defvar RANLIB
 4205: 存在する場合,ranlibプログラムの名前を設定します.
 4206: @end defvar
 4207: 
 4208: @defvar allow_undefined_flag
 4209: 結果として生じる共有ライブラリに,未解決のシンボルがあることを宣言するた
 4210: めに,@samp{archive_cmds}で使用されるフラグです.そのようなフラグが不要
 4211: な場合は空です.ライブラリで定義されていないシンボルを参照して,共有ライ
 4212: ブラリを生成する方法がない場合,@samp{unsupported}を設定します.
 4213: @end defvar
 4214: 
 4215: @defvar always_export_symbols
 4216: アーカイブとリンクする前に,@var{export_symbols_cmds}を使用してエクスポー
 4217: トされるシンボルのリストを,libtoolが自動的に生成するかどうかです.
 4218: @samp{yes}または@samp{no}に設定します.デフォルトは@samp{no}です.
 4219: @end defvar
 4220: 
 4221: @defvar archive_cmds
 4222: @defvarx archive_expsym_cmds
 4223: @defvarx old_archive_cmds
 4224: それぞれ,共有ライブラリ,@samp{-export-symbols}を用いた共有ライブラリ,
 4225: そしてスタティックライブラリを生成するために使用するコマンドです.
 4226: @end defvar
 4227: 
 4228: @defvar old_archive_from_new_cmds
 4229: 共有ライブラリがスタティックライブラリに依存する場合,
 4230: @samp{old_archive_from_new_cmds}はスタティックライブラリを生成するために
 4231: 使用するコマンドを含みます.この変数が空の場合,@samp{old_archive_cmds}
 4232: は使用されません.
 4233: @end defvar
 4234: 
 4235: @defvar old_archive_from_expsyms_cmds
 4236: スタティックライブラリが,共有ライブラリで正しくリンクするために,エクス
 4237: ポートシンボルリストから作成される必要がある場合,
 4238: @samp{old_archive_from_expsyms_cmds}は,そのスタティックライブラリを作成
 4239: するために必要なコマンドを含みます.これらのコマンドが実行されるとき,変
 4240: 数@var{soname}は,共有ライブラリの名前を疑問符の中に含み,
 4241: @var{$objdir/$newlib}は,これらのコマンドがビルドする静的ライブラリのパ
 4242: スを含みます.これらのコマンドを実行した後,libtoolは,@var{soname}の代
 4243: わりに@var{$objdir/$newlib}に対してリンクするための処理を行います.
 4244: @end defvar
 4245: 
 4246: @defvar build_libtool_libs
 4247: このシステムで,libtoolが共有ライブラリをビルドできるかどうかです.
 4248: @samp{yes}または@samp{no}に設定します.
 4249: @end defvar
 4250: 
 4251: @defvar build_old_libs
 4252: このシステムで,libtoolがスタティックライブラリをビルドできるかどうかで
 4253: す.@samp{yes}または@samp{no}に設定します.
 4254: @end defvar
 4255: 
 4256: @defvar compiler_c_o
 4257: コンパイラが,同時に@code{-c}と@code{-o}オプションをサポートするかどうか
 4258: です.@samp{yes}または@samp{no}に設定します.
 4259: @end defvar
 4260: 
 4261: @defvar compiler_o_lo
 4262: コンパイラが,直接".lo"ファイルへのコンパイルをサポートするかどうかで,
 4263: 例えば,オブジェクトファイルが,接尾子".o"を持つ必要があるかどうかです.
 4264: @samp{yes}または@samp{no}に設定します.
 4265: @end defvar
 4266: 
 4267: @defvar dlopen_support
 4268: プラットフォームで,@code{dlopen}をサポートするかどうかです.@samp{yes} 
 4269: または@samp{no}に設定します.
 4270: @end defvar
 4271: 
 4272: @defvar dlopen_self
 4273: 実行形式自身が@code{dlopen}可能かどうかです.@samp{yes}または@samp{no} 
 4274: に設定します.
 4275: @end defvar
 4276: 
 4277: @defvar dlopen_self_static
 4278: 静的にリンクされているとき(@samp{-all-static}),実行形式自身が
 4279: @code{dlopen}可能かどうかです.@samp{yes}または@samp{no}に設定します.
 4280: @end defvar
 4281: 
 4282: @defvar echo
 4283: バックスラッシュをエスケープ文字と解釈しない@code{echo}プログラムです.
 4284: @end defvar
 4285: 
 4286: @defvar exclude_expsyms
 4287: プリリードされているシンボルにリストアップされないシンボルのリストです.
 4288: @end defvar
 4289: 
 4290: @defvar export_dynamic_flag_spec
 4291: dlopenされる共有ライブラリが,プログラムで定義されているシンボルへの参照
 4292: を可能にするコンパイラリンクフラグです.
 4293: @end defvar
 4294: 
 4295: @defvar export_symbols_cmds
 4296: @var{libobjs}からファイル@var{export_symbols}へエクスポートされたシンボ
 4297: ルを抽出するコマンドです.
 4298: @end defvar
 4299: 
 4300: @defvar extract_expsyms_cmds
 4301: 共有ライブラリからエクスポートされたシンボルリストを抽出するコマンドです.
 4302: これらのコマンドは,ファイル@var{$objdir/$soname-def}が無い場合に実行さ
 4303: れ,@samp{old_archive_from_expsyms_cmds}が使用するため,エクスポートされ
 4304: たシンボル名をそのファイルに書き出します.
 4305: @end defvar
 4306: 
 4307: @defvar fast_install
 4308: libtoolが特権を与える人を,インストール者または開発者のどちらかに決定し
 4309: ます.インストール者がビルドツリーでプログラムを実行することは滅多になく,
 4310: 開発者は滅多にインストールしないしないと仮定します.これは,
 4311: @var{shlibpath_overrides_runpath}が@samp{yes}でないプラットフォーム上で
 4312: のみ意味があるので,この場合,@var{fast_install}は@samp{needless}設定さ
 4313: れます.@var{fast_install}が@samp{yes}に設定される場合,libtoolはインス
 4314: トールされたライブラリを検索するプログラムを作成し,プログラムがビルドツ
 4315: リーで実行される場合,まだインストールされていないライブラリを使用するた
 4316: め,要求があれば,新しいコピーがリンクされます.@samp{no}に設定されてい
 4317: る場合,libtoolは,まだインストールされていないライブラリを使用するプロ
 4318: グラムを作成し,インストール時にプログラムの新しいコピーをリンクします.
 4319: デフォルト値は@samp{yes}または@samp{needless}で,それは,プラットフォー
 4320: ムとコンフィグレーションフラグに依存し,コンフィグレーションフラグ
 4321: @samp{--disable-fast-install}を用いると,@samp{yes}から@samp{no}に切り替
 4322: えられます.
 4323: @end defvar
 4324: 
 4325: @defvar finish_cmds
 4326: 指定されたディレクトリで共有ライブラリを見つける方法を,ダイナミックリン
 4327: カに伝えるコマンドです.
 4328: @end defvar
 4329: 
 4330: @defvar finish_eval
 4331: コマンドが表示されない以外,@var{finish_cmds}と同じです.
 4332: @end defvar
 4333: 
 4334: @defvar fix_srcfile_path
 4335: コンパイラに対するシェル変数$srcfileを修正する式です.
 4336: @end defvar
 4337: 
 4338: @defvar global_symbol_pipe
 4339: @var{NM}の出力を受け,Cの名前が続く生のシンボルのリストを生成するパイプ
 4340: ラインです.例えば,以下のようになります.
 4341: 
 4342: @example
 4343: $ @kbd{eval "$NM progname | $global_symbol_pipe"}
 4344: D @var{symbol1} @var{C-symbol1}
 4345: T @var{symbol2} @var{C-symbol2}
 4346: C @var{symbol3} @var{C-symbol3}
 4347: @dots{}
 4348: $
 4349: @end example
 4350: 
 4351: 最初の列は,(いくつかのプラットフォーム上でコードからデータを伝えるため
 4352: に使用される)シンボル形式を含みますが,その意味はシステムに依存します.
 4353: @end defvar
 4354: 
 4355: @defvar global_symbol_to_cdecl
 4356: @var{global_symbol_pipe}の出力を厳密なC宣言に変換するパイプラインです.
 4357: HP/UXのような,リンカがコードとデータを区別するプラットフォームでは,デー
 4358: タシンボルはそのように宣言され,コードシンボルは関数として宣言されます.
 4359: 気にしないプラットフォームではすべてがデータと仮定されます.
 4360: @end defvar
 4361: 
 4362: @defvar hardcode_action
 4363: @samp{immediate}または@samp{relink}のいずれかで,共有ライブラリパスがイ
 4364: ンストールされる前に実行形式にハードコードされるか,または,再リンクする
 4365: 必要があるかに依存します.
 4366: @end defvar
 4367: 
 4368: @defvar hardcode_direct
 4369: @var{hardcode_libdir_flag_spec}が指定されたとき,
 4370: (@samp{@var{dir}/lib@var{name}.a}のような)コマンド行でライブラリが直接し
 4371: ていされる場合,リンカがディレクトリをハードコードするかどうかに依存し,
 4372: @samp{yes}または@samp{no}に設定します.
 4373: @end defvar
 4374: 
 4375: @defvar hardcode_into_libs
 4376: ライブラリ内の実行パスのハードコードをプラットフォームがサポートするかど
 4377: うかです.可能な場合,プログラムのリンクはより単純になりますが,ライブラ
 4378: リはインストール時に再リンクが必要です.@samp{yes}または@samp{no}に設定
 4379: します.
 4380: @end defvar
 4381: 
 4382: @defvar hardcode_libdir_flag_spec
 4383: 実行時に,共有ライブラリに対しダイナミックリンカが@var{libdir}を検索する
 4384: ために,バイナリに@var{libdir}変数をハードコードするためのフラグです.空
 4385: の場合,libtoolは他のハードコーディングメカニズムの使用を試みます.
 4386: @end defvar
 4387: 
 4388: @defvar hardcode_libdir_separator
 4389: コンパイラが単一の@var{hardcode_libdir_flag}のみ受け入れる場合,この変数
 4390: はそのフラグに対する複数の引数を分ける文字列を含みます.
 4391: @end defvar
 4392: 
 4393: @defvar hardcode_minus_L
 4394: @var{hardcode_libdir_flag_spec}が指定されたとき,結果として生じる実行形
 4395: 式に@samp{-L}フラグで指定されるディレクトリを,リンカがハードコードする
 4396: かどうかに依存し,@samp{yes}または@samp{no}に設定します.
 4397: @end defvar
 4398: 
 4399: @defvar hardcode_shlibpath_var
 4400: @var{hardcode_libdir_flag_spec}が指定されたとき,結果として生じる実行形
 4401: 式に@samp{$shlibpath_var}の内容を書き込むことで,リンカがディレクトリを
 4402: ハードコードするかどうかに依存し,@samp{yes}または@samp{no}に設定します.
 4403: @samp{$shlibpath_var}で指定されたディレクトリが,リンク時ではなく実行時
 4404: に検索される場合,@samp{unsupported}に設定します.
 4405: @end defvar
 4406: 
 4407: @defvar host
 4408: @defvarx host_alias
 4409: 情報を目的として,libtoolがコンフィグレーションされたシステムの指定され
 4410: た標準名に設定します.
 4411: @end defvar
 4412: 
 4413: @defvar include_expsyms
 4414: @var{export_symbols}の使用時に,常にエクスポートされる必要があるシンボル
 4415: のリストです.
 4416: @end defvar
 4417: 
 4418: @defvar libext
 4419: 標準的な,古いアーカイブの接尾子(通常は"a")です.
 4420: @end defvar
 4421: 
 4422: @defvar libname_spec
 4423: ライブラリ名の接頭辞の書式です.Unixシステムでは,スタティックライブラリ
 4424: は@samp{lib@var{name}.a}と呼ばれますが,(OS/2やMS-DOSのような)システムで
 4425: は,ライブラリは@samp{@var{name}.a}のみで呼ばれることもあります.
 4426: @end defvar
 4427: 
 4428: @defvar library_names_spec
 4429: 共有ライブラリ名のリストです.最初はファイル名で,残りはファイルへのシン
 4430: ボリックリンクです.リスト内の名前は,@samp{-l@var{name}}で与えられたと
 4431: きリンカが見つけるファイル名です.
 4432: @end defvar
 4433: 
 4434: @defvar link_all_deplibs
 4435: libtoolが,全ての依存するプログラムに対しプログラムをリンクする必要があ
 4436: るかどうかです.@samp{yes}または@samp{no}に設定します.デフォルトは
 4437: @samp{unknown}で,それは@samp{yes}と同じです.
 4438: @end defvar
 4439: 
 4440: @defvar link_static_flag
 4441: ダイナミックリンクを避けるために使用する(Cコンパイラに渡す)リンカフラグ
 4442: です.
 4443: @end defvar
 4444: 
 4445: @defvar need_lib_prefix
 4446: 自動的にモジュール名に'lib'接尾子を付けるかどうかです.@samp{yes}または
 4447: @samp{no}に設定します.デフォルトで,それは@samp{unknown}になり,それは
 4448: @samp{yes}と同じ意味ですが,本当に確かめたわけではないことを告げています.
 4449: @samp{yes}は@code{dlopen}と'lib'接頭辞がないライブラリにリンク可能なこと
 4450: を意味し,すなわち,それは@var{hardcode_direct}を@samp{yes}にすることを
 4451: 要求します.
 4452: @end defvar
 4453: 
 4454: @defvar need_version
 4455: バージョン管理がライブラリに必要とされるかどうかで,すなわち,ダイナミッ
 4456: クリンカが,すべてのライブラリに対しバージョンの接尾子を必要とするかどう
 4457: かです.@samp{yes}または@samp{no}に設定します.デフォルトで,それは
 4458: @samp{unknown}で,それは@samp{yes}と同じ意味を持ちますが,それを実際には
 4459: 確かめていないことを告げています.
 4460: @end defvar
 4461: 
 4462: @defvar need_locks
 4463: 同時にコンパイルするとき,衝突を避けるためにファイルをロックする必要があ
 4464: るかどうかです.@samp{yes}または@samp{no}に設定します.
 4465: @end defvar
 4466: 
 4467: @defvar no_builtin_flag
 4468: @code{char}として外部グローバルシンボルを宣言することと衝突する組み込み
 4469: 関数を,利用不可能にするコンパイラフラグです.
 4470: @end defvar
 4471: 
 4472: @defvar no_undefined_flag
 4473: 結果として生じる共有ライブラリに,未解決のシンボルがないことを宣言するた
 4474: めの,@samp{archive_cmds}で使用されるフラグです.
 4475: @end defvar
 4476: 
 4477: @defvar objdir
 4478: 一時的なlibtoolファイルが含まれるディレクトリ名です.
 4479: @end defvar
 4480: 
 4481: @defvar objext
 4482: 標準的なオブジェクトファイルの接尾子(通常は"o")です.
 4483: @end defvar
 4484: 
 4485: @defvar pic_flag
 4486: ライブラリオブジェクトファイルをビルドするための,あらゆる追加のコンパイ
 4487: ルフラグです.
 4488: @end defvar
 4489: 
 4490: @defvar postinstall_cmds
 4491: @defvarx old_postinstall_cmds
 4492: それぞれ,共有またはスタティックライブラリをインストールした後に実行する
 4493: コマンドです.
 4494: @end defvar
 4495: 
 4496: @defvar postuninstall_cmds
 4497: @defvarx old_postuninstall_cmds
 4498: それぞれ,共有またはスタティックライブラリをアンインストールした後に実行
 4499: するコマンドです.
 4500: @end defvar
 4501: 
 4502: @defvar reload_cmds
 4503: @defvarx reload_flag
 4504: リロード可能なオブジェクトを作成するコマンドです.
 4505: @end defvar
 4506: 
 4507: @defvar runpath_var
 4508: 結果として生じる実行形式内にハードコードするディレクトリをリンカに伝える
 4509: 環境変数です.
 4510: @end defvar
 4511: 
 4512: @defvar shlibpath_overrides_runpath
 4513: 環境変数でプログラムのハードコードされたライブラリ検索パスを優先可能かど
 4514: うかを示します.これが@samp{no}に設定されている場合,libtoolはビルドツリー
 4515: にプログラムのコピーを2つ作成する必要がある可能性があり,一つはインストー
 4516: ルされ,もう一つはビルドツリーのみで実行されます.これらのコピーのどちら
 4517: かが作成されるとき,@code{fast_install}の値に依存します.デフォルト値は
 4518: @samp{unknown}で,それは@samp{no}と同じです.
 4519: @end defvar
 4520: 
 4521: @defvar shlibpath_var
 4522: ダイナミックリンカに共有ライブラリを探す場所を伝える環境変数です.
 4523: @end defvar
 4524: 
 4525: @defvar soname_spec
 4526: 共有ライブラリがファイルの本当の名前と異なる場合,その中に符号化されたコー
 4527: ドされた名前です.
 4528: @end defvar
 4529: 
 4530: @defvar striplib
 4531: @defvarx old_striplib
 4532: 共有(@code{striplib})やスタティック(@code{old_striplib})のライブラリを
 4533: stripするコマンドです.これらの変数が空の場合,インストールモードのstrip
 4534: フラグは,ライブラリに対し無視されます(@pxref{Install mode}).
 4535: @end defvar
 4536: 
 4537: @defvar sys_lib_dlsearch_path_spec
 4538: 実行時にライブラリの検索パスを取得する式です.このリストに現れるディレク
 4539: トリが実行形式にハードコードされることは決してありません.
 4540: @end defvar
 4541: 
 4542: @defvar sys_lib_search_path_spec
 4543: コンパイル時にライブラリの検索パスを取得する式です.この変数は,特定のラ
 4544: イブラリが共有かスタティックかをテストする必要があるとき,libtoolが使用
 4545: します.@var{shlibpath_var}でリストアップされるディレクトリは,このリス
 4546: トに自動的に現れ,ライブラリ検索パスを拡張するためにこの変数を使用するリ
 4547: ンカもあるので,毎回(すなわち,コンフィグレーション時以外)libtoolは実行
 4548: します.リンカは@code{-L}のような検索パス引数も切り替えます.
 4549: @end defvar
 4550: 
 4551: @defvar thread_safe_flag_spec
 4552: スレッドセーフなライブラリを生成するために使用する(Cコンパイラに渡す)リ
 4553: ンカフラグです.
 4554: @end defvar
 4555: 
 4556: @defvar version_type
 4557: ライブラリバージョンナンバーの形式です.@samp{libtool},
 4558: @samp{freebsd-aout},@samp{freebsd-elf},@samp{irix},@samp{linux},
 4559: @samp{osf},@samp{sunos},@samp{windows},または@samp{none}の一つです.
 4560: @end defvar
 4561: 
 4562: @defvar whole_archive_flag_spec
 4563: 便利なアーカイバから共有ライブラリを生成するコンパイラフラグです.
 4564: @end defvar
 4565: 
 4566: @defvar wl
 4567: libtoolが直接リンカにフラグを渡すことを可能とするCコンパイラフラグです.
 4568: @code{$@{wl@}@var{some-flag}}として使用されます.
 4569: @end defvar
 4570: 
 4571: @samp{_cmds}や@samp{_eval}で終わる変数は,@samp{~}で分けられた,順番に
 4572: @code{eval}されるコマンドのリストを含みます.ゼロ以外の終了ステータスを
 4573: 返すコマンドがある場合,libtoolは一般的にエラーメッセージとともに終了し
 4574: ます.
 4575: 
 4576: @samp{_spec}で終わる変数は,libtoolで使用される前に@code{eval}されます.
 4577: 
 4578: 
 4579: @node Cheap tricks
 4580: @section 安っぽい手段
 4581: 
 4582: より簡単にメンテナーシップを作成するために使用することが可能な手段は以下
 4583: のようになっています.
 4584: 
 4585: @itemize @bullet
 4586: @item
 4587: 人々がバグを報告したとき,彼らを助けたいと思う場合は,@samp{--config},
 4588: @samp{--debug},または@samp{--features}フラグを使用したかどうかを尋ねて
 4589: ください.これらのフラグは,中古の調査を信頼しなければならない代わりに,
 4590: 情報を直接得る手助けとなるものです.
 4591: 
 4592: @item
 4593: @code{ltmain.in}を変更するたび毎に再コンフィグレーションする代わりに,
 4594: @var{PATH}に永久的な@code{libtool}スクリプトを保持し,それは直接
 4595: @code{ltmain.in}の元となります.
 4596: 
 4597: 以下のステップは,そのようなスクリプトを作成する方法を記述し,そこでは
 4598: @code{/home/src/libtool}はlibtoolソースツリーを含むディレクトリ,
 4599: @code{/home/src/libtool/libtool}はプラットフォームに対し以前にコンフィグ
 4600: レーションしたlibtooolスクリプト,そして@code{~/bin}は@var{PATH}にあるディ
 4601: レクトリになっています.
 4602: 
 4603: @example
 4604: trick$ cd ~/bin
 4605: trick$ sed '/^# ltmain\.sh/q' /home/src/libtool/libtool > libtool
 4606: trick$ echo '. /home/src/libtool/ltmain.in' >> libtool
 4607: trick$ chmod +x libtool
 4608: trick$ libtool --version
 4609: ltmain.sh (GNU @@PACKAGE@@) @@VERSION@@@@TIMESTAMP@@
 4610: trick$
 4611: @end example
 4612: @end itemize
 4613: 
 4614: @samp{libtool --version}コマンドの最終的な出力は,@code{ltmain.in}スクリ
 4615: プトが直接使用されていることを示します.@code{configure}を再実行する必要
 4616: なく新しい変更をテストするため,すぐに,@code{~/bin/libtool}や
 4617: @code{/home/src/libtool/ltmain.in}を編集してください.
 4618: 
 4619: @include fdl.texi
 4620: 
 4621: @page
 4622: @node Index
 4623: @unnumbered 索引
 4624: 
 4625: @printindex cp
 4626: 
 4627: @c summarycontents
 4628: @contents
 4629: @bye

FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>