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

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