Go to the first, previous, next, last section, table of contents.


存在の調査

以下のマクロは,パッケージが必要とする,あるいは使用する,特定のシステ ムの特徴をテストします.これらのマクロが調査しない特徴のテストが必要な 場合,適切な引数で基本のテストマクロを呼び出すことで,おそらく可能です (see section テストを書く).

これらのテストは,調査している特徴と見つかったものをユーザに伝えるメッ セージを出力します.将来,@command{configure}を実行するため,結果をキャッ シュします(see section 結果のキャッシュ).

これらのマクロには,出力変数を設定するものもあります.変数の取得方法は, See section Makefileへの代入. "nameを定義します"という文章は, "Cプリプロセッサのシンボルnameの値を1に定義します" という意味 を短縮したのもとして,以下で使用します.プログラムでシンボル定義を得る 方法は, See section Cプリプロセッサシンボルの定義.

一般的な動作

Autoconfの学習が簡単になるように努力してきました.このゴールに到達する ための最も明白な方法は,できるだけ例外を避けながら,単純に標準的なイン タフェースと動作を実施することです.残念ながら,歴史と慣性のため,多く の例外がAutoconfにはまだ存在しています.それにもかかわらず,このセクショ ンでは,一般的な規則を記述します.

標準的なシンボル

テストの結果,シンボルをAC_DEFINEする全ての一般的なマクロは,そ の引数を標準的なアルファベットに変換します.最初に,argumentは大 文字に変換され,あらゆるアスタリスク(`*')は,それぞれ`P'に変 換されます.アルファベットではない残りの全ての文字は,アンダースコアに 変換されます.

例えば以下のものを考えます.

AC_CHECK_TYPES(struct $Expensive*)

これは,調査が成功した場合,シンボル`HAVE_STRUCT__EXPENSIVEP'を定 義します.

デフォルトのインクルード

ヘッダファイルの設定に依存するテストもあります.これらのヘッダは例外無 く利用可能というわけではないので,テストは,以下のようなインクルードを 保護する(コードの)組を,実際に提供する必要があります.

#if TIME_WITH_SYS_TIME
# include <sys/time.h>
# include <time.h>
#else
# if HAVE_SYS_TIME_H
#  include <sys/time.h>
# else
#  include <time.h>
# endif
#endif

どうすれば良いか正確に知らない場合,無条件のインクルードの使用は避け, インクルードする前にヘッダの存在を調査すべきです(see section ヘッダファイル).

最も一般的なマクロは,以下のようなインクルードのデフォルトの組を提供し ています.

#include <stdio.h>
#if HAVE_SYS_TYPES_H
# include <sys/types.h>
#endif
#if HAVE_SYS_STAT_H
# include <sys/stat.h>
#endif
#if STDC_HEADERS
# include <stdlib.h>
# include <stddef.h>
#else
# if HAVE_STDLIB_H
#  include <stdlib.h>
# endif
#endif
#if HAVE_STRING_H
# if !STDC_HEADERS && HAVE_MEMORY_H
#  include <memory.h>
# endif
# include <string.h>
#endif
#if HAVE_STRINGS_H
# include <strings.h>
#endif
#if HAVE_INTTYPES_H
# include <inttypes.h>
#else
# if HAVE_STDINT_H
#  include <stdint.h>
# endif
#endif
#if HAVE_UNISTD_H
# include <unistd.h>
#endif

デフォルトのインクルードが使用される場合,Autoconfはこれらのヘッダの存 在とその互換性を自動的に調査します.すなわち,AC_HEADERS_STDCを 実行する必要も,`stdlib.h'などを調査する必要もありません.

これらのヘッダは,インクルードされる順番と同じ順番で調査されます.例え ば,`string.h'`strings.h'の両方があるシステムもありますが, 競合しません.そこでは,HAVE_STRING_Hは定義されますが, HAVE_STRINGS_Hは定義されません.

プログラムの選択

これらのマクロは,特定のプログラムとその動作を調査します.それらは,い くつかのプログラムからどれかを選択し,一旦選ばれると何をするのかを決定 するために使用されます.必要なプログラムを調査するために特別に定義され ているマクロが無い場合,一般的なプログラム調査のマクロの一つを使用する ことが可能です.

特定のプログラムの調査

以下のマクロは,特定のプログラムを調査します -- それは存在するかどう か,そして場合によっては特定の機能をサポートするかどうかです.

Macro: AC_PROG_AWK
gawkmawknawk,そしてawkを,この順番で 調査し,最初に見つかったものに出力変数AWKを設定します.最良の実 装と報告されているので,最初にgawkを調査します.

Macro: AC_PROG_EGREP
grep -Eegrepをこの順番で調査し,最初に見つかったもので 出力変数EGREPを設定します.

Macro: AC_PROG_FGREP
grep -Ffgrepをこの順番で調査し,最初に見つかったもので 出力変数FGREPを設定します.

Macro: AC_PROG_INSTALL
現在のPATHで@acronym{BSD}互換のinstallプログラムが見つかっ た場合,出力変数INSTALLをそのパスに設定します.それ以外では, INSTALL`dir/install-sh -c'に設定し, AC_CONFIG_AUX_DIRで指定されたディレクトリ(またはデフォルトディ レクトリ)を,dirを決定するために調査します(see section 出力ファイルを生成する).また, 変数INSTALL_PROGRAMINSTALL_SCRIPT`${INSTALL}' に,`${INSTALL}'INSTALL_DATA`${INSTALL}-m 644'に設定します.

このマクロは,動作しないことが知られているinstallの様々な実例を ふるい落とします.それは速度のため,シェルスクリプトよりCプログラムを 見付けようとします.`install-sh'の代わりに,`install.sh'を使 用することも可能ですが,@command{make}プログラムには, `Makefile' が無い場合,それから`install'を作成するルールを持っているものもある ので,その名前は時代遅れです.

使用可能な`install-sh'のコピーは,Autoconfでインストールされます. AC_PROG_INSTALLを使用する場合,配布物に`install-sh'`install.sh'を含める必要があり,そうしない場合, @command{configure} は見つからない旨,エラーメッセージを出力します -- たとえシステムに良い installがあってもそうなります.この調査は, そのファイルをたまたま入れ忘れることを阻止する安全対策で,それは @acronym{BSD}互換のinstallプログラムが無いシステムでパッケージ をインストールすることを妨げます.

標準的なinstallプログラムには見当たらない特徴があるために,独自 のインストールプログラムを使用する必要がある場合, AC_PROG_INSTALLを使用する理由はありません.`Makefile.in'ファ イルにプログラムのファイル名を書き込んでください.

Macro: AC_PROG_LEX
flexが見つかった場合,ライブラリが標準的な場所にあれば,出力変 数 LEX`flex'に,LEXLIB`-lfl'に設定します. それ以外の場合,LEX`lex'に,LEXLIB`-ll'に 設定します.

yytext`char []'ではなく`char *'の場合, YYTEXT_POINTERを定義します.また,出力変数 LEX_OUTPUT_ROOTをlexerが生成するファイル名のベースに設定します. 通常は`lex.yy'ですが異なることもあります.これらは,結果として lexflexのどちらが使用されているかに依存して変化します.

普通のLexとそれが生成するCソースを使用するより,移植性の面でより好まし いので,ソースでFlexを使用することを推奨します.しかし,移植性を確実に するために,関数yywrapを提供する,または,それを使用しない場合 (例えば,スキャナに`#include'のような機能が無い場合),単純にスキャ ナソースで`%noyywrap'文を含める必要があります.一旦このようにする ことで,スキャナは(あなたが移植性の無い構成物を使用しない限り) 移植性があり,ライブラリに依存しません.この場合,そしてこの場合のみ, 以下のようなAutoconfの断片を使用することを提案します.

AC_PROG_LEX
if test "$LEX" != flex; then
  LEX="$SHELL $missing_dir/missing flex"
  AC_SUBST(LEX_OUTPUT_ROOT, lex.yy)
  AC_SUBST(LEXLIB, '')
fi

シェルスクリプト@command{missing}は,Automakeの配布物で見つかるはずで す.

下位互換を確実にするため,AutomakeのAM_PROG_LEXは,(間接的に)こ のマクロを二回呼び出し,不快な"AC_PROG_LEX invoked multiple times" で始まる警告を生じます.将来のバージョンのAutomakeではこの症状 は修正されるでしょう.それまで,このメッセージを無視してください.

Macro: AC_PROG_LN_S
現在のファイルシステムで,`ln -s'が動作する(オペレーティングシス テムとファイルシステムがシンボリックリンクをサポートしている)場合,出 力変数LN_S`ln -s'に設定します.それ以外の場合は, `ln'が動作する場合は,LN_S`ln'に設定し,そうでもな ければ`cp -p'に設定します.

リンクをカレントディレクトリ以外のディレクトリに作成する場合,その方法 は,`ln'`ln -s'のどちらが使用されるかに依存します. `$(LN_S)'を使用して安全にリンクを作成するため,使用する書式と正し い引数を理解するか,リンクが作成されるディレクトリでlnを常に呼 び出すか,どちらかにしてください.

言い替えると,以下のものは動作しません.

$(LN_S) foo /x/bar

その代わりに,以下のようにします.

(cd /x && $(LN_S) foo bar)

Macro: AC_PROG_RANLIB
ranlibが見つかった場合,出力変数RANLIB`ranlib'に 設定し,それ以外では,`:'(何もしません)に設定します.

Macro: AC_PROG_YACC
bisonが見つかった場合,出力変数YACC`bison -y'に設 定します.それ以外で,byaccが見つかる場合,YACC`byacc'に設定します.それ以外では,YACC`yacc'に設定 します.

一般的なプログラムとファイルの調査

これらのマクロは,"特定の"テストマクロによってカバーされていないプロ グラムを見つけるに使用します.プログラムの存在を確認するだけでなく,そ の動作を調査する必要がある場合,そうするために独自のテストを書く必要が あります(see section テストを書く).デフォルトで,これらのマクロは環境変 数PATHを使用します.ユーザのPATHにない可能性があるプログ ラムを調査する必要がある場合,以下のようにして,パスを編集して渡すこと が可能です.

AC_PATH_PROG([INETD], [inetd], [/usr/libexec/inetd],
             [$PATH:/usr/libexec:/usr/sbin:/usr/etc:etc])

AC_CHECK_PROG等に渡すvariableを,正確に宣言することを強く 推奨します.詳細は,AC_ARG_VARとSee section 出力変数の設定.

Macro: AC_CHECK_PROG (variable, prog-to-check-for, value-if-found, @ovar{value-if-not-found}, @ovar{path}, @ovar{reject})
PATHに,プログラムprog-to-check-forが存在するかどうか調査 します.見つかった場合,variablevalue-if-foundに設定し, それ以外で,value-if-not-foundが与えられている場合は,それに設定 します.たとえreject(絶対パスのファイル名)が最初のサーチパスで見 つかった場合でも,それは候補から外します.この場合, prog-to-check-forが見つかったrejectではない絶対パスのファ イル名を使用し,variableを設定します.variableが既に設定さ れている場合,何もしません.variableに対してAC_SUBSTを呼 び出してください.

Macro: AC_CHECK_PROGS (variable, progs-to-check-for, @ovar{value-if-not-found}, @ovar{path})
空白で区切られたリストprogs-to-check-forのそれぞれのプログラムが PATHに存在するかどうかを調査します.見つかった場合, variableをプログラムの名前に設定します.それ以外の場合は引続き, リストの次にあるプログラムを調査します.リスト内のプログラムが全く見つ からない場合, variablevalue-if-not-foundに設定します. value-if-not-foundが指定されていない場合,variableは変更さ れません.variableに対してAC_SUBSTを呼び出してください.

Macro: AC_CHECK_TOOL (variable, prog-to-check-for, @ovar{value-if-not-found}, @ovar{path})
AC_CHECK_PROGに似ていますが,AC_CANONICAL_HOSTで定義され ているホストタイプにダッシュが続いているプレフィクスを持つ prog-to-check-forを,最初に探します(see section 標準的なシステムタイプの取得).例 えば,ユーザが`configure --host=i386-gnu'を実行している場合,以下 のように呼び出します.
AC_CHECK_TOOL(RANLIB, ranlib, :)

これで,PATH`i386-gnu-ranlib'というプログラムが存在する 場合,RANLIB`i386-gnu-ranlib'に設定し,それ以外で, PATH`ranlib'というプログラムがある場合,RANLIB`ranlib'に設定し,どちらも無い場合は `:'に設定します.

Macro: AC_CHECK_TOOLS (variable, progs-to-check-for, @ovar{value-if-not-found}, @ovar{path})
AC_CHECK_TOOLに似ていて,progs-to-check-forでリストアップ されているそれぞれのツールは,AC_CANONICAL_HOSTで決定されたホス トタイプを前置し,それにダッシュを続けたものを用いて調査されます (see section 標準的なシステムタイプの取得).プレフィクスを用いているツールが見つからない 場合,最初にプレフィクス無しのものが使用されます.ツールが見つかった場 合,variableをそのプログラム名に設定します.リストのツールが全く 見つからない場合,variablevalue-if-not-foundに設定します. value-if-not-foundが指定されていない場合,variableの値は変 更されません.variableに対してAC_SUBSTを呼び出してくださ い.

Macro: AC_PATH_PROG (variable, prog-to-check-for, @ovar{value-if-not-found}, @ovar{path})
AC_CHECK_PROGに似ていますが,見つかった場合,variableprog-to-check-forの完全なパスに設定します.

Macro: AC_PATH_PROGS (variable, progs-to-check-for, @ovar{value-if-not-found}, @ovar{path})
AC_CHECK_PROGSに似ていますが,progs-to-check-forのどれか が見つかった場合,variableをプログラムが見つかった完全なパスに設 定します.

Macro: AC_PATH_TOOL (variable, prog-to-check-for, @ovar{value-if-not-found}, @ovar{path})
AC_CHECK_TOOLに似ていますが,見つかった場合,variableをプ ログラムが見つかった完全なパスに設定します.

ファイル

ファイルの存在を調査する必要もあるでしょう.以下のマクロを使用する前に, 実行時の調査がより良い解決ではないかどうか自問してください.ほとんどの Autoconfマクロのように,それらはホストマシンの機能を調査するため,クロ スコンパイルでは意味が無いことを知っておいてください.

Macro: AC_CHECK_FILE (file, @ovar{action-if-found}, @ovar{action-if-not-found})
ネイティブシステムでfileが存在するかどうか調査します.見つかった 場合,action-if-foundを実行し,それ以外では,与えられていれば action-if-not-foundを実行します.

Macro: AC_CHECK_FILES (files, @ovar{action-if-found}, @ovar{action-if-not-found})
filesでリストアップされているそれぞれのファイルに対し, AC_CHECK_FILEを一度実行します.さらに,見つかったそれぞれのファ イルに対して`HAVEfile'を定義します(see section 標準的なシンボル).

ライブラリファイル

以下のマクロは,C,C++やFortran 77のライブラリアーカイブファイルの存在 を調査します.

Macro: AC_CHECK_LIB (library, function, @ovar{action-if-found}, @ovar{action-if-not-found}, @ovar{other-libraries})
現在の言語に依存して(see section 言語の選択),テストプログラムが関数 利用に必要なライブラリlibraryとリンク可能かどうかを調査すること で,C,C++やFortran 77の関数functionが利用可能であることを確認し ます.libraryは,ライブラリのベース名です.例えば,`-lmp'を 調査するために,libraryの引数として`mp'を使用します.

action-if-foundは,ライブラリとのリンクが成功した場合に実行する シェルコマンドのリストです.action-if-not-foundは,リンクが失敗 した場合に実行するシェルコマンドのリストです.action-if-foundが 指定されていない場合,デフォルトで`-llibrary'LIBS に加え, `HAVE_LIBlibrary'を(全て大文字で)定義します.この マクロは,ライブラリの依存が連続的なテストの自然な副作用で十分になるよ うに,右から左(最小依存から最大依存)の方法でLIBSのビルドサポー トを試みます.ライブラリの順序に注意が必要なリンカもあるので, LIBSが生成される順序は,ライブラリの信頼できる検出にとって重要 です.

libraryとのリンクの結果が,追加のライブラリとのリンクで解決され る未解決のシンボルとなる場合,これらのライブラリを,`-lXt -lX11' のように,スペースで区切られたother-libraries引数で与えてくださ い.そうしない場合,テストプログラムとのリンクが未解決のシンボルで常に 失敗するので,このマクロはlibraryの存在の検出に失敗します. other-libraries引数は,まだLIBSに無い,その他のライブラリ の一つを調査することが望ましい場合は制限があります.

Macro: AC_SEARCH_LIBS (function, search-libs, @ovar{action-if-found}, @ovar{action-if-not-found}, @ovar{other-libraries})
まだ利用可能ではない,functionを定義しているライブラリを探します. これは,最初にライブラリ無しで,その後でそれぞれのライブラリを search-libsにリストアップしている `AC_LINK_IFELSE([AC_LANG_CALL([], [function])])'の呼び出し と等価です.

functionが含まれている最初のライブラリに対して, @option{-llibrary}をLIBSに追加し,action-if-foundを 実行します.関数が見つからない場合,action-if-not-foundを実行し ます.

libraryとのリンクの結果が,未解決のシンボルで,追加のライブラリ とのリンクで解決できる場合,これらのライブラリを,`-lXt -lX11'の 様に,スペースで区切られたother-libraries引数で与えてください. そうしなければ,テストプログラムとのリンクが,常に未解決のシンボルで失 敗するので,このマクロはlibraryの存在の調査に失敗します.

ライブラリ関数

以下のマクロは,特定のCライブラリ関数を調査します.必要な関数を調査す るための特別に定義されたマクロがなく,その特別な特性を調査する必要がな い場合,一般的な関数調査のマクロを使用することが可能です.

C関数の移植性

ほとんどの通常の関数は,無くなっている,またはバグがある,またはアーキ テクチャによって制限があるはずです.このセクションでは,これらの移植性 の問題を目録にしようと思います.定義からすると,このリストは常に追加が 必要です.できるだけ完全なものを保つために,我々への手助けをお願いしま す.

exit
古いホストでは,exitintを返すものがあることを御存知で すか?これは,exitのほうがvoidより時代が古く,int を返すという伝統が長い間あったためです.
snprintf
ISO C99標準では,出力配列があまり大きくなくその他のエラーが無い場合, snprintfvsnprintfは出力を切捨て,生成された出力が必要 とするバイト数を返すことになっています.古いシステムでは切り捨てられた 長さを返したり(例えば,@acronym{GNU} Cライブラリ2.0.xやIRIX 6.5), 負の値を返したり(例えば,より古いバージョンの@acronym{GNU} Cライブラリ), 切り捨てられなかったバッファの長さを返したり(例えば32ビットのSolaris 7)します.また,バグの多い古いシステムにはバッファの長さとオーバーラン を無視するもの(例えば64ビットのSoraris 7)もあります.
sprintf
ISO Cの標準では,sprintfvsprintfは書き込まれたバイト数 を返すことになっていますが,古いシステム(例えばSunOS 4)ではその代わり にバッファへのポインタを返すものもあります.
sscanf
様々な古いシステム,例えばHP-UX 9では,sscanfは入力文字列が(た とえそれが実際には変更されなくても)書き込み可能であることを要求します. これは,@command{gcc}は通常,固定文字列を読み込み専用のメモリに書き込 むので(see section `Incompatibilities' in Using and Porting the @acronym{GNU Compiler Collection}),それを使用すると き問題になるはずです.場合によっては,フォーマット文字列が明らかに読み 込み専用であっても問題になるはずです.
strnlen
@acronym{AIX} 4.3は,以下の結果を生成する壊れたバージョンを提供してい ます.
strnlen ("foobar", 0) = 0
strnlen ("foobar", 1) = 3
strnlen ("foobar", 2) = 2
strnlen ("foobar", 3) = 1
strnlen ("foobar", 4) = 0
strnlen ("foobar", 5) = 6
strnlen ("foobar", 6) = 6
strnlen ("foobar", 7) = 6
strnlen ("foobar", 8) = 6
strnlen ("foobar", 9) = 6
unlink
@acronym{POSIX}の仕様では,unlinkは開かれているファイルへのハン ドルがなくなった後でファイルを削除するように述べられています.全てのOS がこの動作をサポートしているわけではありません.そのため,システムが unlinkを提供している場合でも,開いているファイルに対して呼び出 しても大丈夫だと仮定した移植は不可能です.例えば,Windows 9xとMEでは, そのような呼び出しは失敗します.@acronym{DOS}は可能ですが,OSが削除し た後にファイルへの書き込みが終了するので,ファイルシステムが駄目になり ます.
va_copy
ISO C99標準では,va_listをコピーするためva_copyを提供し ています.古い環境でも利用可能かもしれませんが,おそらくは __va_copy(例えば厳密なC89モード)でしょう.これらは#ifdef でテスト可能です.memcpy (&dst, &src, sizeof(va_list))で代替す ることで最大の移植性となるでしょう.
va_list
va_listはポインタである必要はありません.struct(例えば Alphaの@command{gcc})にすることが可能で,それはNULLでは移植性が 無いことを意味します.配列(例えばPowerPCでコンフィグレーションされた @command{gcc})も可能で,それは関数のパラメータとして効果的に参照呼び出 しが可能であり,ライブラリルーチンで呼び出しが返す値を修正する可能性が ある(例えば@acronym{GNU} Cライブラリ2.1のvsnprintf)ことを意味し ます.
Signed >>
通常,Cの符号付きの右シフト>>はハイビットを複製し,いわゆる"算 術"シフトになります.しかし,ISO Cの標準ではその動作を要求していない ので,注意すべきです.ネイティブの算術シフトが無いプロセッサ(例えば Crayベクターシステム)では,符号無しのシフトと同様に,ゼロビットがシフ トインされる可能性があります.

特定の関数の調査

これらのマクロは -- その存在にかかわらず -- 特定のC関数を調査し,場 合によっては,特定の引数が与えられたときの反応を調査します.

Macro: AC_FUNC_ALLOCA
allocaを使用する方法を調査します.`alloca.h'や,前もって定 義されているCプリプロセッサマクロの__GNUC___AIXを調査 することで,組み込みバージョンを取得しようとします.このマクロが `alloca.h'を見つけた場合,HAVE_ALLOCA_Hを定義します.

その試みが失敗する場合,標準Cライブラリで関数を探します.それらの手法 のいずれかが成功した場合,それはHAVE_ALLOCAを定義します.それ以 外の場合は,出力変数のALLOCA`alloca.o'に設定し, C_ALLOCAを定義します(それで,プログラムがガーベージコレクション のため定期的に`alloca(0)'を呼び出すことが可能になります.この変数 は, LIBOBJSとは別物なので,実際にライブラリを作成しなくても複 数のプログラムでALLOCAの値を共有することが可能ですが, LIBOBJSで使用する場合もわずかにあります.

このマクロは,System V R3 の`libPW'やSystem V R4の`libucb'allocaの使用を試みません.なぜなら,それらのライブラリには互換 性がない関数があり問題が生じるためです.allocaを含まないものや バグだらけのバージョンもあります.それでも,そのallocaを使用し たい場合,`alloca.c'をコンパイルする代わりに,ライブラリから `alloca.o'を抽出するため,arを使用してください.

allocaを使用するソースファイルでは,正確に宣言するために,以下 のようなコードで始めるべきです.@acronym{AIX}のバージョンによっては, allocaの宣言を,コメントとプリプロセッサディレクティブ以外の, 全ての行の前に書く必要があります.#pragmaディレクティブは, @acronym{ANSI} C以前のコンパイラが停止するのではなく無視するように,字 下げを行います.

/* AIX requires this to be the first thing in the file.  */
#ifndef __GNUC__
# if HAVE_ALLOCA_H
#  include <alloca.h>
# else
#  ifdef _AIX
 #pragma alloca
#  else
#   ifndef alloca /* predefined by HP cc +Olibcalls */
char *alloca ();
#   endif
#  endif
# endif
#endif

Macro: AC_FUNC_CHOWN
chown関数が利用可能で動作する場合(特に,uidgid に対する@option{-1}を受け入れるべきです),HAVE_CHOWNを定義しま す.

Macro: AC_FUNC_CLOSEDIR_VOID
closedir関数が意味のある値を返さない場合,CLOSEDIR_VOID を定義します.それ以外では,呼び出し側で,エラーを示す戻り値を調査する 必要があります.

Macro: AC_FUNC_ERROR_AT_LINE
error_at_line関数が見つからない場合,AC_LIBOBJ`error'で置換されることを要求します.

Macro: AC_FUNC_FNMATCH
fnmatch関数が@acronym{POSIX}準拠の場合,HAVE_FNMATCHを定 義します.例えば,Solaris 2.4のバグのような,一般的な実装上のバグを検 出します.

歴史的な理由のため,それ以外のAC_FUNCマクロとは反対に, AC_FUNC_FNMATCHは壊れていたり見つからなかったりする fnmatch を置換しません.以下のAC_REPLACE_FNMATCHを参照し てください.

Macro: AC_FUNC_FNMATCH_GNU
AC_REPLACE_FNMATCH(置換)のように動作しますが, fnmatchが@acronym{GNU}の拡張をサポートするかどうかも調査します. 例えば,@acronym{GNU} Cライブラリ2.1のバグのような,一般的な実装上のバ グを検出します.

Macro: AC_FUNC_FORK
このマクロは,forkvfork関数を調査します.動作する forkが見つかった場合,HAVE_WORKING_FORKを定義します.こ のマクロは,forkがスタブかどうかを実行してみることで調査します.

`vfork.h'が見つかった場合,HAVE_VFORK_Hを定義します.動作 するvforkが見つかった場合,HAVE_WORKING_VFORKを定義しま す.それ以外の場合,以前のバージョンの@command{autoconf}に対する下位互 換のため,vforkforkと定義します.このマクロは, vforkの実装のいくつかの既知のエラーを調査し,そのエラーのいずれ かを検出した場合,システムには動作するvforkが無いと考えます.子 プロセスは,シグナルハンドラを変えることがめったにないので,子プロセス のsignalの呼び出しが,親プロセスのシグナルハンドラを変更する場 合,実装エラーだとは考えられません.

このマクロは,以前のバージョンの@command{autoconf}への下位互換性のため だけにvforkを定義するので,コード内で独自に定義することを推奨し ます.

#if !HAVE_WORKING_VFORK
# define vfork fork
#endif

Macro: AC_FUNC_FSEEKO
fseeko関数が利用可能な場合,HAVE_FSEEKOを定義します.必 要があれば_LARGEFILE_SOURCEを定義します.

Macro: AC_FUNC_GETGROUPS
getgroups関数が利用可能で,(`getgroups (0, 0)'が常に失敗す るUltrix 4.3と異なり)動作する場合,HAVE_GETGROUPSを定義します. GETGROUPS_LIBSをその関数の使用に必要な全てのライブラリに定義し ます.このマクロは,AC_TYPE_GETGROUPSを実行します.

Macro: AC_FUNC_GETLOADAVG
システムのロードアベレージを取得する方法を調査します.適切に調査を実行 するため,このマクロはファイル`getloadavg.c'が必要です.このため, 適切な置換ディレクトリをAC_LIBOBJで確実に設定してください (section 一般の関数の調査と,AC_CONFIG_LIBOBJ_DIRを参照してくだ さい).

システムにgetloadavg関数がある場合,HAVE_GETLOADAVGを定 義し,その関数の使用に必要な全てのライブラリをGETLOADAVG_LIBSに 設定します.また,GETLOADAVG_LIBSLIBSに加えます.それ 以外の場合,AC_LIBOBJ`getloadavg'`dir/getloadavg.c' のソースコードで置換することを要求し,お そらく以下のようないくつかのCプリプロセッサのマクロと出力変数を定義し ます.

  1. C_GETLOADAVGを定義します.
  2. システムが,SVR4DGUXUMAX,または UMAX4_3の場合,それを定義します.
  3. `nlist.h'が見つかる場合,HAVE_NLIST_Hを定義します.
  4. `struct nlist'`n_un'メンバーを持つ場合, HAVE_STRUCT_NLIST_N_UN_N_NAMEを定義します.時代遅れのシンボル NLIST_NAME_UNIONも定義しますが,それに依存しないようにしてくだ さい.
  5. プログラムによっては,getloadavgが動作するために,setgid(または setuid)がインストールされていることを必要とするかもしれません.この場 合,GETLOADAVG_PRIVILEGEDを定義し,出力変数NEED_SETGID`true'に(それ以外では`false'に)設定し,そして KMEM_GROUP をインストールされているプログラムを所有するグループ の名前に設定します.

Macro: AC_FUNC_GETMNTENT
IRIX 4,PTXと,Unixwareに対し,`sun'`seq',そして `gen' のライブラリ内のgetmntentをそれぞれ調査します. getmntentが利用可能な場合,HAVE_GETMNTENTを定義します.

Macro: AC_FUNC_GETPGRP
getpgrpに0を渡すとエラーになる場合,GETPGRP_VOIDを定義し ます.これは@acronym{POSIX}の動作です.古い@acronym{BSD}システムでは, それは引数をとり@acronym{POSIX}のgetpgidのように動作するので, getpgrpに0を渡す必要があります.
#if GETPGRP_VOID
  pid = getpgrp ();
#else
  pid = getpgrp (0);
#endif

このマクロはgetpgrpが存在するかどうかを全く調査しません.そのよ うな状況で動作する必要がある場合,getpgrpに対して最初に AC_CHECK_FUNCを呼び出してください.

Macro: AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK
`link'がシンボリックリンクの場合,lstat`link/'`link/.'と同じものとして扱います.しかし,多くの古いlstat の実装では,後置されているスラッシュを間違って無視します.

lstatが後置されているスラッシュを間違って無視する場合,それ以外 のunlinkのようなsymbolic-link-aware関数も後置されているスラッシュ を間違って無視すると仮定した方が確実です.

lstatが正しく動作する場合,LSTAT_FOLLOWS_SLASHED_SYMLINK を定義し,それ以外の場合は,AC_LIBOBJlstatで置換するよ う要求します.

Macro: AC_FUNC_MALLOC
malloc関数が@acronym{GNU} Cライブラリのmallocと互換性が ある場合,(すなわち`malloc (0)'が有効なポインタを返す)場合, HAVE_MALLOCを1に定義します.それ以外では,HAVE_MALLOCを0 に定義し,AC_LIBOBJ`malloc'を置換し,ネイティブの mallocが中心的なプロジェクトで使用されないようにmallocrpl_mallocで定義するかどうかを尋ねます.

通常,ファイル`malloc.c'の置換は以下のようになります(`#undef malloc'に注意してください).

@verbatim #if HAVE_CONFIG_H # include <config.h> #endif #undef malloc

#include <sys/types.h>

void *malloc ();

/* Allocate an N-byte block of memory from the heap. If N is zero, allocate a 1-byte block. */

void * rpl_malloc (size_t n) { if (n == 0) n = 1; return malloc (n); }

Macro: AC_FUNC_MEMCMP
memcmp関数が利用不可能,または(SunOS 4.1.3のように)8ビットデー タで動作しない,または(NeXT x86 OpenStepのように)16バイトかそれ以上で 少なくとも一つのバッファが4バイト境界で始まらないものの比較時に失敗す る場合,AC_LIBOBJ`memcmp'を置換することを要求します.

Macro: AC_FUNC_MBRTOWC
関数mbrtowcと型mbstate_tが正しく宣言されている場合, HAVE_MBRTOWCを1に設定します.

Macro: AC_FUNC_MKTIME
mktime関数が利用不可能,または正しく動作しない場合, AC_LIBOBJ`mktime'を置換することを要求します.

Macro: AC_FUNC_MMAP
mmap関数が存在して正しく動作する場合,HAVE_MMAPを定義し ます.すでにマップされたメモリの,プライベートな固定したマッピングのみ 調査します.

Macro: AC_FUNC_OBSTACK
obstackが見つかった場合,HAVE_OBSTACKを定義し,そうでない場合は AC_LIBOBJ`obstack'を置換することを要求します.

Macro: AC_FUNC_REALLOC
realloc関数が@acronym{GNU} Cライブラリのreallocと互換性 がある場合,(すなわち`realloc (0, 0)'が有効なポインタを返す)場合, HAVE_REALLOCを1に定義します.それ以外では,HAVE_REALLOC を0に定義し,AC_LIBOBJ`realloc'を置換し,ネイティブの reallocが中心的なプロジェクトで使用されないようにreallocrpl_reallocで定義するかどうかを尋ねます.詳細は AC_FUNC_MALLOCを参照してください.

Macro: AC_FUNC_SELECT_ARGTYPES
select関数の引数それぞれに渡される正しい型を決定し,それらの型 をSELECT_TYPE_ARG1SELECT_TYPE_ARG234,そして SELECT_TYPE_ARG5にそれぞれ定義します.SELECT_TYPE_ARG1の デフォルトは`int'で,SELECT_TYPE_ARG234のデフォルトは `int *'で,そしてSELECT_TYPE_ARG5のデフォルトは `struct timeval *' です.

Macro: AC_FUNC_SETPGRP
setpgrpが引数を持たない(@acronym{POSIX}バージョンの)場合, SETPGRP_VOIDを定義します.それ以外では,@acronym{BSD}バージョン で,二つのプロセスIDを引数とします.このマクロはsetpgrpの存在を 全く調査しません.その状況で動作する必要がある場合,setpgrpに対 して最初にAC_CHECK_FUNCを呼び出してください.

Macro: AC_FUNC_STAT
Macro: AC_FUNC_LSTAT
statlstatに,長さが0のファイル名を引数で与えたときに成 功するというバグがあるかどうかを決定します.SunOS 4.1.4と Hurd(1998-11-01)のstatlstatではこうなります.

その場合,HAVE_STAT_EMPTY_STRING_BUG(または HAVE_LSTAT_EMPTY_STRING_BUG)を定義し,AC_LIBOBJでそれを 置換することを要求します.

Macro: AC_FUNC_SETVBUF_REVERSED
setvbufが他とは異なり,第二引数でバッファの型,第三引数でバッファ ポインタをとる場合,SETVBUF_REVERSEDを定義します.

Macro: AC_FUNC_STRCOLL
strcoll関数が存在して,正しく動作する場合,HAVE_STRCOLL を定義します.使用すべきではないstrcollの間違った定義を持つシス テムもあるので,`AC_CHECK_FUNCS(strcoll)'より多少ましです.

Macro: AC_FUNC_STRTOD
strtod関数が存在していない,または正しく動作しない場合, AC_LIBOBJ`strtod'を置換するよう要求します.この場合, `strtod.c'`pow'を必要とすることもあり得るので,出力変数 POW_LIBを必要な外部ライブラリに設定します.

Macro: AC_FUNC_STRERROR_R
strerror_rが利用可能な場合はHAVE_STRERROR_Rを定義し,そ れが宣言されている場合,HAVE_DECL_STRERROR_Rを定義します.それ がchar *のメッセージを返す場合,STRERROR_R_CHAR_Pを定義 します.それ以外ではintのエラーナンバーを返します. @acronym{POSIX}ではstrerror_rintを返すように要求してい ますが,多くのシステムのスレッドセーフな関数のオプション(例えば @acronym{GNU} Cライブラリのバージョン2.2.4を含む)は,バッファ引数に等 しい必要が無いchar * の値を返します.

Macro: AC_FUNC_STRFTIME
`intl'ライブラリ内で,SCO UNIXに対するstrftimeを調査 します.strftimeが利用可能な場合,HAVE_STRFTIMEを定義し ます.

Macro: AC_FUNC_STRNLEN
strnlenが利用不可能な場合や(@acronym{AIX} 4.3のように)バグが多 い場合,AC_LIBOBJで置換することを要求します.

Macro: AC_FUNC_UTIME_NULL
`utime(file, NULL)'fileのタイムスタンプを現在のもの に設定する場合,HAVE_UTIME_NULLを定義します.

Macro: AC_FUNC_VPRINTF
vprintfが見つかった場合,HAVE_VPRINTFを定義します.それ 以外で,_doprntが見つかった場合,HAVE_DOPRNTを定義します. (vprintfが利用可能な場合,vfprintfvsprintfも利 用可能だと仮定できるでしょう.)

Macro: AC_REPLACE_FNMATCH
fnmatch関数が@acronym{POSIX}準拠でない場合 (AC_FUNC_FNMATCHを参照してください),それをAC_LIBOBJで置 換するかどうかを尋ねます.

AC_LIBOBJの置換用ディレクトリのファイル`fnmatch.c'`fnmatch_loop.c',そして`fnmatch_.h'が,@acronym{GNU} fnmatchのソースコードをのコピーを含んでいると想定されます.必要 な場合,このソースコードはAC_LIBOBJでの置換物としてコンパイルさ れ,システムの<fnmatch.h>でインクルードできるように, `fnmatch_.h'`fnmatch.h'にリンクされます.

一般の関数の調査

これらのマクロは,"特定の"テストマクロによってカバーていない関数を見 つけるために使用されます.関数が,デフォルトのCライブラリ以外のライブ ラリにある場合,最初にそれらのライブラリに対してAC_CHECK_LIBを 呼び出してください.存在の確認だけでなく動作も調査したい場合,独自のテ ストを書く必要があります(see section テストを書く).

Macro: AC_CHECK_FUNC (function, @ovar{action-if-found}, @ovar{action-if-not-found})
Cの関数functionが利用可能な場合,シェルコマンド action-if-foundを,それ以外ではaction-if-not-foundを実行し ます.関数が利用可能な場合にシンボルを定義したいだけならば,代わりに AC_CHECK_FUNCSを使用してください.このマクロは, CのほうがC++よ り標準化されているので,AC_LANG_CPLUSPLUSが呼び出された場合でも, C にリンクされる関数を調査します.(言語の選択の調査ついての詳細は, see section 言語の選択.)

Macro: AC_CHECK_FUNCS (function..., @ovar{action-if-found}, @ovar{action-if-not-found})
空白で区切られた引数のリストで与えられているそれぞれのfunctionに 対し,利用可能な場合はHAVE_functionを(全て大文字で)定義し ます.action-if-foundが与えられている場合,関数の一つが見つかっ たとき実行する,追加のシェルコードになります.最初に一致したループでブ レイクするためには,`break'を与えることで可能になります. action-if-not-foundが与えられている場合,それは関数が一つでも見 つからないときに実行されます.

Autoconfは,移植性について苦心してきた人々によって,何年もかけて形作ら れてきた哲学に従います.特定のファイルの移植性の問題と, @acronym{POSIX}環境にいるかのような問題とは別物です.関数によっては, 無いものがあったり修正不可能だったりするものもあり,パッケージではそれ らを置き換える準備が必要になります.

Macro: AC_LIBOBJ (function)
無かったり壊れたりしているfunctionの実装を置換するために,実行形 式に含める必要がある`function.c'を指定します.

技術的には,それは`function.$ac_objext'を出力変数 LIBOBJSに追加し,`function.c'に対し AC_LIBSOURCEを呼び出します.LIBOBJSは追跡不可能なので, 直接LIBOBJSを変更すべきではありません.

Macro: AC_LIBSOURCE (file)
プロジェクトをコンパイルするために必要になるfileを指定します. `configure.ac'で必要になるファイルを知る必要がある場合, AC_LIBSOURCEを追跡調査してください.fileはリテラルにする 必要があります.

このマクロは,自動的にAC_LIBOBJから呼び出されますが,シェル変数 にAC_LIBOBJを渡す場合,明示的に指定する必要があります.この場合, シェル変数は静的な追跡調査ができないので,AC_LIBOBJを生成するた めに必要になりそうなあらゆるシェル変数を,AC_LIBSOURCEに渡す必 要があります.例えば,"foo"または"bar"を保持している AC_LIBOBJに変数$foo_or_barを渡したい場合は,以下のように すべきでしょう.

AC_LIBSOURCE(foo.c)
AC_LIBSOURCE(bar.c)
AC_LIBOBJ($foo_or_bar)

しかし,これを避ける一般的な方法もあり,それには単純にリテラルの引数で AC_LIBOBJを呼び出すことを推奨します.

このマクロは,時代遅れのAC_LIBOBJ_DECLを若干異なる意味で置換す ることに注意してください.古いマクロは,ファイル名ではなく関数名,例え ばfooを引数としてとります.

Macro: AC_LIBSOURCES (files)
AC_LIBSOURCEに似ていますが,カンマで分けられているM4リストに, 一つ以上のfilesを受け入れます.このため,上記の例は以下のように 書き換えられるでしょう.
AC_LIBSOURCES([foo.c, bar.c])
AC_LIBOBJ($foo_or_bar)

Macro: AC_CONFIG_LIBOBJ_DIR (directory)
AC_LIBOBJで置換するファイルがdirectoryで見つかるように, ソースツリーのトップレベルから始まる相対パスを指定します.置換ディレク トリのデフォルトはトップレベルディレクトリの`.'で,最も一般的な値 は`lib'で,`AC_CONFIG_LIBOBJ_DIR(lib)'で対応します.

@command{configure}は以下の理由で,置換ディレクトリを知る必要がないか もしれません.(i)置換ファイルを使用する調査もあります.(ii)置換ヘッダ のリンクを導入することで,壊れたシステムヘッダをバイパスするマクロもあ ります.等々.

AC_LIBOBJが無い場合,単に関数の存在を調査し,置換するかどうか尋 ねるだけのことは一般的です.以下のマクロは,便利で手短なものです.

Macro: AC_REPLACE_FUNCS (function...)
AC_CHECK_FUNCSに似ていますが,action-if-not-found として `AC_LIBOBJ(function)'を使用します.`#if !HAVE_function'にプロトタイプを含めることで,置換する関数を宣言 することが可能です.システムに関数が存在する場合,おそらくインクルード しているヘッダファイルで宣言されているので,宣言が衝突しないように,そ れを再定義すべきではありません.

ヘッダファイル

以下のマクロは,ある特定のCヘッダファイルの存在を調査します.必要とし ているヘッダファイルを調査するために特に定義されたマクロがなく,その特 別な特性を調査する必要がない場合,一般的なヘッダファイルチェックマクロ の一つを使用することが可能です.

ヘッダの移植性

このセクションでは,一般的なヘッダとそれらの問題に関する知識を正しくし てみたいと思います.定義上,以下のリストは常なる追加を必要とします.可 能な限り完全に保つ手助けをお願いします.

`inttypes.h'`stdint.h'
Paul Eggertのメモ:ISO C 1999では,`inttypes.h'`stdint.h' をインクルードするので,標準的な環境では`stdint.h'を個別にインク ルードする必要な無いことになっています.多くの実装では, `inttypes.h'はありますが`stdint.h'はありませんし(例えば, Solaris 7),`stdint.h'があって`inttypes.h'が無いと言う実装は 知りません.また,`stdint.h'をインクルードしているフリーソフトウェ アも知りません.`stdint.h'は,委員会で作成されたようです.

特定のヘッダの調査

これらのマクロは,特定のシステムヘッダファイルを調査します -- それら が存在しているか,そして場合によっては,特定のシンボルを宣言しているか を調査します.

Macro: AC_HEADER_DIRENT
以下のヘッダファイルを調査します.最初に見つかった`DIR'を定義して いるものに対して,リストアップされているCプリプロセッサマクロを定義し ます.
  • `dirent.h' HAVE_DIRENT_H
  • `sys/ndir.h' HAVE_SYS_NDIR_H
  • `sys/dir.h' HAVE_SYS_DIR_H
  • `ndir.h' HAVE_NDIR_H ソースコード内のディレクトリライブラリの宣言は,以下のようにすべきでしょ う.
    #if HAVE_DIRENT_H
    # include <dirent.h>
    # define NAMLEN(dirent) strlen((dirent)->d_name)
    #else
    # define dirent direct
    # define NAMLEN(dirent) (dirent)->d_namlen
    # if HAVE_SYS_NDIR_H
    #  include <sys/ndir.h>
    # endif
    # if HAVE_SYS_DIR_H
    #  include <sys/dir.h>
    # endif
    # if HAVE_NDIR_H
    #  include <ndir.h>
    # endif
    #endif
    
    上記の宣言を使用している場合,プログラムは型をstruct directでは なくstruct direntとして変数を宣言し,struct direntへのポ インタを渡すことによって,NAMLENマクロまでのディレクトリエント リ名の長さにアクセスします. このマクロは,SCO Xenix `dir'`x'ライブラリも調査します.
  • Macro: AC_HEADER_MAJOR
    `sys/types.h'majorminor,そしてmakedevを 定義していないが,`sys/mkdev.h'が定義している場合, MAJOR_IN_MKDEVを定義します.それ以外の場合で, `sys/sysmacros.h'が定義している場合は,MAJOR_IN_SYSMACROS を定義します.
    Macro: AC_HEADER_STAT
    `sys/stat.h'で定義されているS_ISDIRS_ISREG等のマ クロが正確に動作しない(間違った正の値を返す)場合, STAT_MACROS_BROKEN を定義します.Tektronix UTekV,Amdahl UTS, そしてMotorola System V/88の場合がそうです.
    Macro: AC_HEADER_STDBOOL
    `stdbool.h'が存在し,それがC99に準拠している場合, HAVE_STDBOOL_Hを1に定義します.型_Boolが定義されている場 合,HAVE__BOOLを1に定義します.C99の要求を満たすため, `system.h'には以下のコードを含めるべきです. @verbatim #if HAVE_STDBOOL_H # include <stdbool.h> #else # if ! HAVE__BOOL # ifdef __cplusplus typedef bool _Bool; # else typedef unsigned char _Bool; # endif # endif # define bool _Bool # define false 0 # define true 1 # define __bool_true_false_are_defined 1 #endif
    Macro: AC_HEADER_STDC
    システムに@acronym{ANSI} Cヘッダファイルが存在する場合, STDC_HEADERSを定義します.特にこのマクロは,`stdlib.h'`stdarg.h'`string.h',そして`float.h'を調査し,システ ムにそれらが存在している場合は,おそらく@acronym{ANSI} Cヘッダーファイ ルの残りも存在します.同様に,このマクロは`string.h'memchrを宣言(他のmem関数もおそらく存在)しているかどうか, `stdlib.h'freeを宣言(mallocや他の関連する関数もお そらく存在)しているかどうか,そして,`ctype.h'マクロが, @acronym{ANSI} Cが要求するハイビットセット文字でも動作するかどうかを調 査します. GCCがあるシステムの多くは@acronym{ANSI} Cヘッダファイルが存在していな いので,システムに@acronym{ANSI}対応のヘッダファイル(そして,おそらくC ライブラリ関数) が存在していることを決定するために,__STDC__の 代わりにSTDC_HEADERSを使用してください. @acronym{ANSI} Cヘッダが無いシステムには多くの変種が存在していて,そこ では,システムヘッダファイルが宣言しているものを正確に理解するより,使 用する関数を宣言する方がより容易でしょう.@acronym{ANSI}と @acronym{BSD}の関数が混在しているシステムもあります.ほとんど @acronym{ANSI}だが`memmove'が無いものもあります.@acronym{BSD}関 数が`string.h'`strings.h' でマクロで定義されているものもあ ります.@acronym{BSD}関数しか持っていないが `string.h'が存在する ものもあります.メモリ関数が`memory.h'で定義されていて, `string.h'でも定義されているものもあります.等々いろいろなシステ ムがあります.一つの文字列関数と一つのメモリ関数を調査すれば恐らく十分 です.ライブラリに@acronym{ANSI}バージョンのものが存在する場合,他のも のもほとんど存在します.以下を`configure.ac'に書き込む場合を考え ます.
    AC_HEADER_STDC
    AC_CHECK_FUNCS(strchr memcpy)
    
    コード内に,以下のような宣言を使用することが可能です.
    #if STDC_HEADERS
    # include <string.h>
    #else
    # if !HAVE_STRCHR
    #  define strchr index
    #  define strrchr rindex
    # endif
    char *strchr (), *strrchr ();
    # if !HAVE_MEMCPY
    #  define memcpy(d, s, n) bcopy ((s), (d), (n))
    #  define memmove(d, s, n) bcopy ((s), (d), (n))
    # endif
    #endif
    
    @acronym{BSD}とは異なるmemchrmemsetstrtok,ま たは strspnの様な関数を使用する場合,マクロは不十分でしょう.そ れぞれの関数を実装する必要があります.(システムのCライブラリのものが, 手動で最適化されているかもしれないので)必要なときだけ実装を組み込む簡 単な方法として,例えばmemchrを使用する場合は,それを `memchr.c'に書き込み,`AC_REPLACE_FUNCS(memchr)'を使用するこ とです.
    Macro: AC_HEADER_SYS_WAIT
    `sys/wait.h'が存在して,@acronym{POSIX}と互換性がある場合, HAVE_SYS_WAIT_Hを定義します.非互換性は,`sys/wait.h'が存 在しない場合や,ステータスの値を保存するため,intの代わりに古い @acronym{BSD}のunion wait使用する場合に生じます. `sys/wait.h'が@acronym{POSIX}と互換性がない場合,それをインクルー ドする代わりに,それらの通常の解釈を用いて@acronym{POSIX}のマクロを定 義してください.例えば以下のようにします.
    #include <sys/types.h>
    #if HAVE_SYS_WAIT_H
    # include <sys/wait.h>
    #endif
    #ifndef WEXITSTATUS
    # define WEXITSTATUS(stat_val) ((unsigned)(stat_val) >> 8)
    #endif
    #ifndef WIFEXITED
    # define WIFEXITED(stat_val) (((stat_val) & 255) == 0)
    #endif
    
    `unistd.h'が@acronym{POSIX}システムに含まれている場合, _POSIX_VERSIONが定義されます.`unistd.h'が無い場合,明らか に@acronym{POSIX}システムではありません.しかし,`unistd.h'を持つ @acronym{POSIX}ではないシステムもあります. システムが@acronym{POSIX}をサポートしているかどうか調査する方法は以下 のようにします.
    #if HAVE_UNISTD_H
    # include <sys/types.h>
    # include <unistd.h>
    #endif
    
    #ifdef _POSIX_VERSION
    /* Code for POSIX systems.  */
    #endif
    
    Macro: AC_HEADER_TIME
    プログラムが,`time.h'`sys/time.h'の両方をインクルードする 可能性がある場合,TIME_WITH_SYS_TIMEを定義します.古いシステム では,`sys/time.h'`time.h'をインクルードするものもあります が,`time.h'は複数回のインクルードに対して保護されていないので, プログラムで明示的に両方のファイルをインクルードすべきではありません. このマクロは,例えば,struct tmと同様,struct timevalを 使用するプログラムで役に立ちます. AC_CHECK_HEADERS(sys/time.h) を使用していることを調査可能にするHAVE_SYS_TIME_Hと一緒に使用す るのが最善の方法です.
    #if TIME_WITH_SYS_TIME
    # include <sys/time.h>
    # include <time.h>
    #else
    # if HAVE_SYS_TIME_H
    #  include <sys/time.h>
    # else
    #  include <time.h>
    # endif
    #endif
    
    Macro: AC_HEADER_TIOCGWINSZ
    TIOCGWINSZの使用が`<sys/ioctl.h>'を要求する場合, GWINSZ_IN_SYS_IOCTLを定義します.それ以外では, TIOCGWINSZ`<termios.h>'で見つかるはずです. 以下のようにして使用します.
    #if HAVE_TERMIOS_H
    # include <termios.h>
    #endif
    
    #if GWINSZ_IN_SYS_IOCTL
    # include <sys/ioctl.h>
    #endif
    

    一般的なヘッダの調査

    これらのマクロは,"特定の"テストマクロでカバーされていない,システム ヘッダファイルを見つけるために使用されます.その存在を見つけるだけでな く,ヘッダの内容を調査する必要がある場合,そのために独自のテストを書く 必要があります(see section テストを書く).

    Macro: AC_CHECK_HEADER (header-file, @ovar{action-if-found}, @ovar{action-if-not-found}, @dvar{includes, default-includes})
    システムヘッダファイルheader-fileがコンパイル可能な場合,シェル コマンドaction-if-foundを,それ以外ではaction-if-not-found を実行します.ヘッダファイルが利用可能な場合で,シンボルを定義したいだ けの場合は,代わりに,AC_CHECK_HEADERSを使用を考えてみてくださ い.

    古いバージョンのAutoconfとの互換性の問題は,以下を読んでください.

    Macro: AC_CHECK_HEADERS (header-file..., @ovar{action-if-found}, @ovar{action-if-not-found}, @dvar{includes, default-includes})
    空白で区切られた引数のリストで与えられているシステムヘッダファイル header-fileが存在しているものに対し, HAVE_header-file を(全て大文字で)定義します. action-if-foundが与えられている場合,それはヘッダファイルの一つ が見つかったときに実行する追加のシェルコードになります.最初に一致した ループでブレイクするために`break'を与えることが可能です. action-if-not-foundが与えられている場合,ヘッダファイルが一つで も見つからないとき実行されます.

    古いバージョンのAutoconfとの互換性の問題は,以下を読んでください.

    以前のバージョンのAutoconfは,ヘッダがプリプロセッサに適合しているかど うかを,単純に調査していました.古いテストは,代表的な使用に対して不適 切であるため変更されました.ヘッダは通常コンパイルで使用され,プリプロ セスでは滅多に使用されませんし,古い動作では,コンパイル時にだめになる ヘッダを受け入れることもありました.ヘッダがプリプロセス可能かどうかを 調査する必要がある場合,AC_PREPROC_IFELSEを使用することが可能で す(see section プリプロセッサの実行).

    このテストの耐性を高める手法は,header-fileの前にインクルードす る必要があるヘッダが,includesにあることも要求します (see section デフォルトのインクルード).`foo.h'が存在する場合,その前でインク ルードされる必要がある`bar.h'を探す場合,以下の手法を提案します.

    @verbatim AC_CHECK_HEADERS([foo.h]) AC_CHECK_HEADERS([bar.h], [], [], [#if HAVE_FOO_H # include <foo.h> # endif ])

    宣言

    以下のマクロは,変数と関数の宣言を調査します.必要なシンボルを調査する ために特別なマクロが定義されていない場合,一般的なマクロ (see section 一般的な宣言の調査を使用することが可能で,より複雑なテスト に対しては,AC_COMPILE_IFELSEを使用してもかまいません (see section コンパイラの実行).

    特定の宣言の調査

    宣言を調査する特別なマクロはありません.

    一般的な宣言の調査

    これらのマクロは,"特定の"テストマクロでカバーされていない宣言を調査 するために使用します.

    Macro: AC_CHECK_DECL (symbol, @ovar{action-if-found}, @ovar{action-if-not-found}, @dvar{includes, default-includes})
    symbol(関数や変数)がincludesで定義されていなくて宣言が必要 な場合,シェルコマンドaction-if-not-foundを実行し,それ以外では action-if-foundを実行します.includesが宣言されていない場 合,デフォルトのインクルードが使用されます(see section デフォルトのインクルード).

    このマクロは,必要でないときに余分な宣言を導入することを避けた方が安全 なので,symbolがr-valueとして有効かどうかを実際にテストし,実際 に宣言されているかどうかはテストしません.

    Macro: AC_CHECK_DECLS (symbols, @ovar{action-if-found}, @ovar{action-if-not-found}, @dvar{includes, default-includes})
    それぞれの(カンマで分けられているリスト)symbolsに対し, symbolが宣言されれいる場合はHAVE_DECL_symbolを(全て 大文字で)`1'に定義し,それ以外では`0'に定義します. action-if-not-foundが与えられている場合,関数宣言の一つが必要な とき実行するシェルコードを追加し,それ以外ではaction-if-foundが 実行されます.

    このマクロは,最初の引数としてM4のリストを使用します.

    AC_CHECK_DECLS(strdup)
    AC_CHECK_DECLS([strlen])
    AC_CHECK_DECLS([malloc, realloc, calloc, free])
    

    他の`AC_CHECK_*S'マクロと異なり,symbolが宣言されていないと き,HAVE_DECL_symbolを宣言しないままにする代わりに, HAVE_DECL_symbol`0'で定義されます.調査の実行を 確かめているときは,HAVE_DECL_symbolをAutoconfの他 の結果と同じように,以下のように使用してください.

    #if !HAVE_DECL_SYMBOL
    extern char *symbol;
    #endif
    

    しかし,テストが実行されていない場合,システムのものと衝突するような宣 言を使用するより,シンボルを宣言しない方が安全なので,以下のよ うに使用すべきでしょう.

    #if defined HAVE_DECL_MALLOC && !HAVE_DECL_MALLOC
    void *malloc (size_t *s);
    #endif
    

    究極の状態でのみ二番目のカテゴリに分類されます.ファイルがコンフィグレー ションされずに使用されている場合か,コンフィグレーション時に使用されて いる場合のいずれかです.ほとんどの場合はこれまでの方法で十分です.

    構造体

    以下のマクロは,特定のCの構造体の存在を調査します.必要なメンバーの調 査するために定義されている特定のマクロが無い場合,一般的な構造体メンバー のマクロを使用したり(see section 一般的な構造体の調査),より複雑なテストに対 しては,AC_COMPILE_IFELSEを使用してもかまいません (see section コンパイラの実行).

    特定の構造体の調査

    以下のマクロは,特定の構造体と構造体のメンバーを調査します.

    Macro: AC_STRUCT_ST_BLKSIZE
    struct statst_blksizeメンバーを含んでいる場合, HAVE_STRUCT_STAT_ST_BLKSIZEを定義します.これまでの名前 HAVE_ST_BLKSIZEは,将来サポートを中止するので避けてください.こ のマクロは時代遅れで,以下のもので置換すべきです.
    AC_CHECK_MEMBERS([struct stat.st_blksize])
    

    Macro: AC_STRUCT_ST_BLOCKS
    struct statst_blocksメンバーを含んでいる場合, HAVE_STRUCT STAT_ST_BLOCKSを定義します.それ以外では,出力変数 AC_LIBOBJS`fileblocks'の置換を要求します.これまでの名前 HAVE_ST_BLOCKSは,将来サポートを中止するので避けてください.

    Macro: AC_STRUCT_ST_RDEV
    struct statst_rdevメンバーを含んでいる場合, HAVE_STRUCT_STAT_ST_RDEVを定義します.これまでの名前 HAVE_ST_RDEVは,将来サポートを中止するので避けてください.実際 には新しいマクロでさえ時代遅れで,以下のもので置換すべきです.
    AC_CHECK_MEMBERS([struct stat.st_rdev])
    

    Macro: AC_STRUCT_TM
    `time.h'struct tmを定義しない場合,TM_IN_SYS_TIME を定義し,それは,`sys/time.h'をインクルードすることで struct tmを定義した方が良いことを意味します.

    Macro: AC_STRUCT_TIMEZONE
    現在のタイムゾーンの取得法を判別します.struct tmtm_zoneメンバーが存在する場合,HAVE_STRUCT_TM_TM_ZONE (と時代遅れのHAVE_TM_ZONE)を定義します.それ以外では,外部配列 のtznameが見つかる場合,HAVE_TZNAMEを定義します.

    一般的な構造体の調査

    これらのマクロは,"特定の"テストマクロでカバーされていない構造体のメ ンバーを検索するために使用します.

    Macro: AC_CHECK_MEMBER (aggregate.member, @ovar{action-if-found}, @ovar{action-if-not-found}, @dvar{includes, default-includes})
    memberが集合体aggregateのメンバーかどうかを調査します. includesが指定されていない場合,デフォルトのインクルードが使用さ れます(see section デフォルトのインクルード).
    AC_CHECK_MEMBER(struct passwd.pw_gecos,,
                    [AC_MSG_ERROR([We need `passwd.pw_gecos'!])],
                    [#include <pwd.h>])
    

    このマクロはサブメンバーに対して使用可能です.

    AC_CHECK_MEMBER(struct top.middle.bot)
    

    Macro: AC_CHECK_MEMBERS (members, @ovar{action-if-found}, @ovar{action-if-not-found}, @dvar{includes, default-includes})
    直前のマクロで使用されているmembersのそれぞれの `aggregate.member'の存在を調査します.memberaggregateに属しているとき, HAVE_aggregate_member を(全て大文字で,スペースとドッ トをアンダースコアで置換しながら)定義します.

    このマクロはM4のリストを使用します.

    AC_CHECK_MEMBERS([struct stat.st_rdev, struct stat.st_blksize])
    

    以下のマクロは,組み込みまたはtypedefになっている,Cの型を調査します. 必要な型を調査するための特別に定義されたマクロがなく,その特別な特性を 調査する必要がない場合,一般的な型調査マクロを使用することが可能です.

    特定の型の調査

    これらのマクロは,`sys/types.h'`stdlib.h',そして存在する 場合はその他の,特定のCの型を調査します.

    Macro: AC_TYPE_GETGROUPS
    gid_tintのどちらかを,getgroupsへの配列引数の基 本の型にするため,GETGROUPS_Tを定義します.

    Macro: AC_TYPE_MBSTATE_T
    <wchar.h>mbstate_t型が宣言されている場合, HAVE_MBSTATE_Tを定義します.また,<wchar.h>で宣言されて いない場合,型としてmbstate_tを定義します.

    Macro: AC_TYPE_MODE_T
    `AC_CHECK_TYPE(mode_t, int)'と同じです.

    Macro: AC_TYPE_OFF_T
    `AC_CHECK_TYPE(off_t, long)'と同じです.

    Macro: AC_TYPE_PID_T
    `AC_CHECK_TYPE(pid_t, int)'と同じです.

    Macro: AC_TYPE_SIGNAL
    `signal.h'が,signalvoid返す関数へのポインタを返 すものと宣言されている場合,RETSIGTYPEvoidと定義します. それ以外ではintと定義します.

    シグナルハンドラが返す型をRETSIGTYPEと定義してください.

    RETSIGTYPE
    hup_handler ()
    {
    ...
    }
    

    Macro: AC_TYPE_SIZE_T
    `AC_CHECK_TYPE(size_t, unsigned)'と同じです.

    Macro: AC_TYPE_UID_T
    uid_tが定義されていない場合,uid_tintに,そして gid_tintに定義します.

    一般的な型の調査

    これらのマクロは,"特定の"テストマクロがカバーしない型を調査するため に使用されます.

    Macro: AC_CHECK_TYPE (type, @ovar{action-if-found}, @ovar{action-if-not-found}, @dvar{includes, default-includes})
    typeが定義されているかどうかを調査します.コンパイラ組み込みの型 や,includes(see section デフォルトのインクルード)で定義されている可能性があ ります.

    Macro: AC_CHECK_TYPES (types, @ovar{action-if-found}, @ovar{action-if-not-found}, @dvar{includes, default-includes})
    定義されているtypesのそれぞれのtypeに対し, HAVE_typeを(全て大文字で)定義します.includesが定義 されていない場合,デフォルトのインクルードが使用されます (see section デフォルトのインクルード).action-if-foundが与えられている場合, 型の一つが見つかったときに実行する追加のシェルコードとなります. action-if-not-found が与えられている場合,型の一つでも見つからな いときに実行されます.

    このマクロはM4のリストを使用します.

    AC_CHECK_TYPES(ptrdiff_t)
    AC_CHECK_TYPES([unsigned long long, uintmax_t])
    

    2.13までのAutoconfは,設計に問題がある他のバージョンの AC_CHECK_TYPEを提供するために使用されていました.単純な経験則と して,全体的ではないが全く安全なので,下位互換性のため,実装されました. 疑うのなら,以前のAC_CHECK_TYPEのドキュメントを読んでください. section 時代遅れのマクロを参照してください.

    コンパイラとプリプロセッサ

    コンパイラ(AC_PROG_CCAC_PROG_CXXAC_PROG_F77) に対する全てのテストは,コンパイラの出力のベースとなる出力変数 EXEEXTを定義し,通常,Unixでは空の文字列でWin32やOS/2では `.exe'に定義されます.

    それらは,`.c'ファイルが除外された後で,コンパイラ出力のベースと なる出力変数OBJEXTも定義し,通常,Unixでは`o'でWin32では `obj'に定義されますます.

    使用しているコンパイラが実行形式を生成しない場合,テストは失敗します. 実行形式が実行不可能な場合で,クロスコンパイルが利用できない場合も失敗 します.クロスコンパイルのサポートの詳細は,See section 手動のコンフィグレーション.

    特定のコンパイラの特徴

    コンパイラによっては異なる動作を示すものもあります.

    Static/Dynamic Expressions
    Autoconfは,Cコンパイラからの情報の1ビットを抽出するトリックをあてにし ます.負の配列の大きさを使用します.例えば,以下のCソースの引用で, `int'が4バイト長かどうかをテストする方法を説明します.
    int
    main (void)
    {
      static int test_array [sizeof (int) == 4 ? 1 : -1];
      test_array [0] = 0
      return 0;
    }
    
    知っている限りでは,このトリックをサポートしないコンパイラは一つです. それはHP-UX 11.00のHPのCコンパイラです("バンドル"されているものだけ ではなく,実際のものもそうです).
    $ cc -c -Ae +O2 +Onolimit conftest.c
    cc: "conftest.c": error 1879: Variable-length arrays cannot \
        have static storage.
    
    Autoconfは,比較する前にsizeof (int)longにキャストする ことで,この問題を解決します.

    一般的なコンパイラの特徴

    Macro: AC_CHECK_SIZEOF (type, @ovar{unused}, @dvar{includes, default-includes})
    SIZEOF_type(see section 標準的なシンボル)をtypeのバイト サイズに定義します.`type'が分からない場合,そのサイズは0になりま す.includesが指定されていない場合,デフォルトのインクルードが使 用されます(see section デフォルトのインクルード).includeを与える場合,この マクロを実行するために必要な`stdio.h'を必ずインクルードしてくださ い.

    このマクロは,現在クロスコンパイル時にも動作します.unused引数は, クロスコンパイル時に使用します.

    例えば,以下のように呼び出します.

    AC_CHECK_SIZEOF(int *)
    

    これは,DEC Alpha AXPシステムではSIZEOF_INT_Pを8に定義します.

    Cコンパイラの特徴

    以下のマクロは,Cコンパイラを探し使用する方法を提供します.避けたほう が良い構成物もいくつかありますが,それらは容易に回避可能なので,調査に 使用しているなら無くしてしまうこともないでしょう.

    単一のバックスラッシュを含んでいる行を使用しないでください
    それらは,HP-UX Cコンパイラにあるバグにはめられます(HP-UXの10.20, 11.00,そして11iで調査しました).以下のソースをコンパイラで実行します.
    #ifdef __STDC__
    /\
    * A comment with backslash-newlines in it. %{ %} *\
    \
    /
    char str[] = "\\
    " A string with backslash-newlines in it %{ %} \\
    "";
    char apostrophe = '\\
    \
    '\
    ';
    #endif
    
    以下のようになります.
    error-->cpp: "foo.c", line 13: error 4048: Non-terminating comment at end of file.
    error-->cpp: "foo.c", line 13: error 4033: Missing #endif at end of file.
    
    単一のバックスラッシュを用いた行を削除することで,問題を解決できます.
    出力が問題になる場合,一度に複数のファイルをコンパイルしないでください
    HPのようにコンパイラには,ファイルが複数のとき,コンパイルして いるファイル名を報告するものもあります.例えば以下のものです.
    $ cc a.c b.c
    a.c:
    b.c:
    
    失敗を検出するために,コンパイラの出力を観察する場合,これは問題になる はずです.`cc -c a.c -o a.o; cc -c b.c -o b.o; cc a.o b.o -o c'で 呼び出すことで問題を解決します.

    Macro: AC_PROG_CC (@ovar{compiler-search-list})
    使用するCコンパイラを決定します.CCが環境変数で設定されていない 場合,gccccを調査し,その後で他のCコンパイラを調査しま す.出力変数CCを,見つかったコンパイラの名前に設定します.

    しかし,このマクロはオプションで最初の引数を用いて呼び出すことも可能で, それが指定されている場合,それをスペースで区切られている検索するCコン パイラのリストにする必要があります.これは,別のCコンパイラの検索リス トを指定する機会をユーザに与えます.例えば,デフォルトの順序が好きでは ない場合,以下のようなAC_PROG_CCを呼び出すことが可能です.

    AC_PROG_CC(cl egcs gcc cc)
    

    Cコンパイラがデフォルトで@acronym{ANSI} Cモードでない場合,そうするた めのオプションを出力変数CCに追加します.このマクロは,様々なシ ステムで@acronym{ANSI} Cを選択するように,様々なオプションを試します. 関数のプロトタイプを正しく処理する場合,コンパイラが@acronym{ANSI} Cモー ドだと考えます.

    このマクロを呼び出した後,Cコンパイラが@acronym{ANSI} Cを受け入れるよ うに設定されているかどうかを調査することが可能です.そうでない場合,シェ ル変数ac_cv_prog_cc_stdc`no'に設定されます.ソースコード を@acronym{ANSI} Cで書いている場合,Automake附属のプログラム ansi2knr を使用して,非@acronym{ANSI}fiedされたコピーを作成する ことが可能です.AC_C_PROTOTYPES以下も参照してください.

    @acronym{GNU} Cコンパイラを使用する場合,シェル変数のGCC`yes'に設定します.出力変数CFLAGSがいまだ設定されていない 場合,@acronym{GNU} Cコンパイラに対しては@option{-g -O2}に設定し(GCCが `-g'を受け入れないシステムは`-O2'),それ以外のコンパイラに対 しては@option{-g}に設定します.

    Macro: AC_PROG_CC_C_O
    Cコンパイラが`-c'`-o'オプションを同時に受け入れない場合, NO_MINUS_C_MINUS_Oを定義します.このマクロは,AC_PROG_CC で見つかったコンパイラと,パスの最初のccがそれと異なっている場 合はその両方を,実際にテストします.一つでも失敗した場合,テストは失敗 します.このマクロは,@acronym{GNU} Makeがデフォルトのコンパイルルール を選択するように作成されました.

    Macro: AC_PROG_CPP
    出力変数CPPを,Cプリプロセッサを実行するコマンドに設定ます. `$CC -E'が動作しない場合,`/lib/cpp'を使用します.拡張子が `.c'のファイルでCPPを実行することは移植性のためだけです.

    プロセッサによっては,足りないインクルードファイルをエラーステータスで 示さないものもあります.そのようなプロセッサに対する内部変数は,プリプ ロセッサからの標準エラーを調査するための他のマクロを設定し,警告が報告 された場合はテストに失敗したと判断します.

    以下のマクロは,Cコンパイラやマシンアーキテクチャの特徴を調査します. ここでリストアップされない特徴を調査するために, AC_COMPILE_IFELSE (see section コンパイラの実行)や AC_RUN_IFELSE (see section 実行時の動作の調査)を使用してください.

    Macro: AC_C_BACKSLASH_A
    Cコンパイラが`\a'を理解する場合,`HAVE_C_BACKSLASH_A'を1に定 義します.

    Macro: AC_C_BIGENDIAN (@ovar{action-if-true}, @ovar{action-if-false}, @ovar{action-if-unknown})
    (MotorolaとSPARCのCPUのように)wordが最上位バイトに最初に保存される場合, action-if-trueを実行します.(IntelとVAXのCPUのように)wordが最下 位バイトに最初に保存される場合,action-if-falseを実行します.

    システムヘッダファイルからエンディアンを決定不可能な場合,このマクロは テストケースを実行します.クロスコンパイル時に,テストケースは実行され ませんが,いくつかのマジック変数を検索します.後者の状況でホストシステ ムのバイト特性の決定に失敗した場合,action-if-unknownが実行され ます.

    action-if-trueのデフォルトは`WORDS_BIGENDIAN'を定義すること です.action-if-falseのデフォルトは何もしないことです.そして最 後に,action-if-unknownのデフォルトは,コンフィグレーションを中 断し,インストールしている人に,このテストをバイパスさせるために変数を 前もって定義するよう伝えます.

    Macro: AC_C_CONST
    Cコンパイラが@acronym{ANSI} Cの修飾子constを完全にサポートしな い場合, constを空で定義します.__STDC__を定義しないCコ ンパイラには,constをサポートするものもあります. __STDC__を定義するCコンパイラには,constを完全にサポート しないものもあります.全てのCコンパイラがconstをサポートするか のように,プログラムはそれを使用することができます.サポートしないもの のために`Makefile'やコンフィグレーションヘッダファイルは,それを 空で定義します.

    Cコンパイラが無いために,インストールしている人がCコードをコンパイルす るためにC++コンパイラを使用することもあります.CとC++はconstを 異なる方法で処理するので,これはconstの問題が生じます.例えば, 以下のようにします.

    const int foo;
    

    Cでは有効ですがC++ではそうではありません.残念ながら,これらの違いを constを空で定義することで誤魔化すことは不可能です.

    @command{autoconf}がこの状況を検出した場合,一般的に実際問題としてより 良い結果になるので,それはconstのままにしておきます.しかし,C コードコンパイルするためにC++コンパイラを使用することは推奨されていま せんし,サポートもしていません.そして,この状況で問題が生じたインストー ル者は,CコードをコンパイルするためにGCCのようなCコンパイラを入手すべ きです.

    Macro: AC_C_VOLATILE
    Cコンパイラがキーワードvolatileを理解しない場合, volatile を空で定義します.プログラムではvolatileをサポー トしているコンパイラのように単純に使用することが可能です.サポートしな いものに対しては,`Makefile'やコンフィグレーションヘッダで,それ を空として定義されます.

    プログラムの正当性がvolatileの意味に依存している場合,単純に空 で定義するとある意味ではコードが壊れます.しかし,volatileをサ ポートしていないコンパイラでは,自分で何とかしてください.少なくともプ ログラムはコンパイルされますが,多分駄目でしょう.

    一般的に,volatileキーワードは@acronym{ANSI} Cの機能なので, __STDC__が定義されているときだけ,volatileが利用可能だと 期待するかもしれません.しかし,Ultrix 4.3のネイティブコンパイラは volatileをサポートとしていますが,__STDC__を定義しません.

    Macro: AC_C_INLINE
    Cコンパイラがキーワードinlineをサポートする場合,何もしません. それ以外では,受け入れられるものによって,inline__inline____inlineに定義し,それ以外ではinline を空で定義します.

    Macro: AC_C_CHAR_UNSIGNED
    Cの型charがunsignedの場合,Cコンパイラが前もって定義していない 限り,__CHAR_UNSIGNED__を定義します.

    Macro: AC_C_LONG_DOUBLE
    Cコンパイラが,doubleの型以上の範囲で動作するlong double の型をサポートしている場合,HAVE_LONG_DOUBLEを定義します.

    Macro: AC_C_STRINGIZE
    Cプリプロセッサが文字列作成オペレータをサポートする場合, HAVE_STRINGIZEを定義します.文字列作成オペレータは`#'と, 以下のようなマクロで見つかります.
    #define x(y) #y
    

    Macro: AC_C_PROTOTYPES
    関数のプロトタイプをコンパイラが理解する場合(AC_PROG_CCで決定さ れます),`PROTOTYPES'__PROTOTYPESを定義します.コンパイ ラがプロトタイプを処理しない場合,関数定義のプロトタイプを止めるために, Automake配布物でインストールされるansi2knrを使用すべきです.関 数のプロトタイプに対して,最初にPARAMSを定義すべきです.
    #ifndef PARAMS
    # if PROTOTYPES
    #  define PARAMS(protos) protos
    # else /* no PROTOTYPES */
    #  define PARAMS(protos) ()
    # endif /* no PROTOTYPES */
    #endif
    

    そして,以下のように使用してください.

    size_t my_strlen PARAMS ((const char *));
    

    このマクロは,__PROTOTYPESも定義します.これは,ユーザの名前空 間を侵害するマクロが使用不可能なヘッダファイルの利便性ためです.

    Macro: AC_PROG_GCC_TRADITIONAL
    使用している@acronym{GNU} Cコンパイラとioctlが, `-traditional'無しでは正確に動作しない場合,出力変数CC`-traditional'を加えます.それは通常,修正されたヘッダファイルが 古いシステムにインストールされていないときに発生します.@acronym{GNU} Cコンパイラの最近のバージョンは,インストール時に,自動的にヘッダファ イルを修正するので,これはほとんど問題になりません.

    C++コンパイラの特徴

    Macro: AC_PROG_CXX (@ovar{compiler-search-list})
    使用するC++コンパイラを定義します.環境変数CXXCCCが設 定されているかどうか(この順番で)調査します.その場合,出力変数をその値 に設定します.

    それ以外でマクロが引数無しで呼び出されている場合,以下のような名前の C++ コンパイラを探します(最初がg++c++その後でそれ以外 の名前です).これらの調査がすべて失敗した場合,最後の手段でCXXg++に設定します.

    しかし,このマクロはオプション引数を用いて呼び出すことが可能で,指定す る場合は,検索するC++コンパイラをスペースで区切ったリストにする必要が あります.これで,ユーザがC++コンパイラに対する代わりの検索リストを指 定する機会が与えられます.例えば,デフォルトの順序がいやな場合は,以下 のようにしてAC_PROG_CXXを呼び出すことが可能です.

    AC_PROG_CXX(cl KCC CC cxx cc++ xlC aCC c++ g++ egcs gcc)
    

    @acronym{GNU} C++コンパイラを使用している場合,シェル変数GXX`yes'に設定します.出力変数CXXFLAGSがまだ設定されていない 場合,@acronym{GNU} C++コンパイラに対しては@option{-g -O2}(`-g'を 受け入れないG++のシステムでは`-O2')を設定し,他のコンパイラでは `-g'を設定します.

    Macro: AC_PROG_CXXCPP
    出力変数CXXCPPを,C++プリプロセッサを実行するコマンドに設定しま す.`$CXX -E'が動作しない場合,`/lib/cpp'を使用します. `.c'`.C',または`.cc'の拡張子を持つファイルで CXXCPPを実行するのは移植性のためだけです.

    プリプロセッサによっては,足りないインクルードファイルをエラーステータ スで示さないものもあります.そのようなプリプロセッサに対して,内部変数 は,プリプロセッサからの標準エラー出力を調査する他のマクロに設定され, 警告が報告されない場合はテストに失敗したと考えます.しかし,C++に対し てそのような壊れ方をしているプリプロセッサがあるかどうかは知りません.

    Fortran 77コンパイラの特徴

    Macro: AC_PROG_F77 (@ovar{compiler-search-list})
    使用するFortran 77コンパイラを決定します.F77が環境変数でまだ設 定されていない場合,g77f77,そしてその他の名前を調査し ます.見つかったコンパイラ名を,出力変数F77に設定します.

    しかし,このマクロはオプション引数を用いて呼び出すことが可能で,指定す る場合は,検索するFortran 77コンパイラをスペースで区切ったリストにする 必要があります.これで,ユーザがFortran 77コンパイラに対する代わりの検 索リストを指定する機会が与えられます.例えば,デフォルトの順序がいやな 場合は,以下のようにしてAC_PROG_F77を呼び出すことが可能です.

    AC_PROG_F77(fl32 f77 fort77 xlf g77 f90 xlf90)
    

    g77(@acronym{GNU} Fortran 77コンパイラ)を使用している場合, AC_PROG_F77はシェル変数G77`yes'に設定します.出力 変数FFLAGSが環境変数で設定されていない場合,g77に対して `-g -O2'(`-g'を受け入れないg77では`-O2')を設定し, 他のFortran 77コンパイラでは`-g'を設定します.

    Macro: AC_PROG_F77_C_O
    Fortran 77コンパイラが,オプション`-c'`-o'を同時にを受け入 れるかどうかテストし,そうでない場合はF77_NO_MINUS_C_MINUS_Oを 定義します.

    以下のマクロは,Fortran 77コンパイラの特徴を調査します.ここでリストアッ プされていない特徴を調査するために,現在の言語がFortran 77AC_LANG_FORTRAN77(see section 言語の選択)に設定されているこ とを最初に確認し,AC_COMPILE_IFELSE (see section コンパイラの実行)やAC_RUN_IFELSE (see section 実行時の動作の調査)を使用してください.

    Macro: AC_F77_LIBRARY_LDFLAGS
    Fortran 77プログラムや共有ライブラリをうまくリンクするために必要な Fortran 77のイントリンシックとランタイムライブラリ(Fortran 77 intrinsic and run-time libraries)に対して,リンカフラグ(例えば `-L'`-l')を決定します.出力変数 FLIBSには,これらの フラグが設定されます.

    このマクロは,単一のプログラムや共有ライブラリに,例えば,C++とFortran 77のソースコードを混在させる必要があるとき利用されます(see section `Mixing Fortran 77 With C and C++' in @acronym{GNU Automake}).

    例えば,C++とFortran 77コンパイラで生成されるオブジェクトファイルを, お互いにリンクする必要があるとき,リンクにはC++コンパイラ/リンカが使用 されるはずです(C++特有のものは,リンク時にグローバルコンストラクタ,イ ンスタンステンプレート,例外処理等を呼び出す必要が生じるためです).

    しかし,Fortran 77のイントリンシックとランタイムライブラリもリンクする 必要がありますが,C++コンパイラ/リンカは,Fortran 77ライブラリを追加す る方法をデフォルトでは知っていません.そのため,マクロ AC_F77_LIBRARY_LDFLAGSは,これらのFortran 77ライブラリを決定す るために作成されました.

    このマクロAC_F77_DUMMY_MAINAC_F77_MAINは,Fortranで C/C++ にリンクする必要があるときもおそらく必要です.以下を参照してくだ さい.

    Macro: AC_F77_DUMMY_MAIN (@ovar{action-if-found}, @ovar{action-if-not-found})
    多くのコンパイラでは,AC_F77_LIBRARY_LDFLAGSで見つかるFortranラ イブラリは,Fortran I/Oのようなものを初期化したり,ユーザプログラムを 実行するために,(いわゆる)MAIN__のような名前を持つユーザ提供の エントリー関数を呼び出す,独自のmainエントリー関数を提供してい ます.AC_F77_DUMMY_MAINAC_F77_MAINマクロは,この相互作 用を扱う方法を理解します.

    (I/Oなどではない)純粋な数値関数に対してFortranを使用しているとき,独自 のmainを提供し,Fortranライブラリの初期化を停止したいこともよく あります.しかしこの場合は,いくつかのシステムでのリンクエラーを避ける ため,ダミーのMAIN__ルーチンを提供する必要があるかもしれません. シェル変数F77_DUMMY_MAINは,解決方法が見つからないときは unknown,そのようなダミーのmainが不要なときはnone という値を保持します.

    デフォルトで,必要な場合は,action-if-foundF77_DUMMY_MAINをこのルーチン名(例えばMAIN__)に定義します. @ovar{action-if-not-found}はデフォルトでエラーで終了します.

    Fortranとリンクするために,必要な場合はダミーのmainを定義するた めに,userのC/C++プログラムで以下のようなコードをインクルードすべきで す.

    #ifdef F77_DUMMY_MAIN
    #  ifdef __cplusplus
         extern "C"
    #  endif
       int F77_DUMMY_MAIN() { return 1; }
    #endif
    

    AC_F77_DUMMY_MAINAC_F77_WRAPPERSから自動的に呼び出され ることに注意してください.一般的にデフォルトの動作を変更したくない限り, 明示的にに呼び出す必要はありません.

    Macro: AC_F77_MAIN
    上記のAC_F77_DUMMY_MAINで議論したように,Fortranライブラリには, 通常のmainの代わりに,(いわゆる)MAIN__と呼ばれるエントリー ポイントを提供することが可能なものも多く,それは,Fortran I/Oのような ものを初期化するために,Fortranライブラリのmain関数で呼び出され ます.AC_F77_MAINは,そのような代理のmain関数の利用が 可能かどうかを検出し,F77_MAINを関数の名前に定義します. (代理のmain関数の名前が見つからない場合,F77_MAINは単純 にmainに定義します.)

    このため,Fortranルーチンが,I/Oのようなものを実行するためにCから呼び 出されるとき,このマクロを使用し,"main"関数をmainではなく F77_MAINの名前にすべきです.

    Macro: AC_F77_WRAPPERS
    名前がmangleされる方法をFortran 77コンパイラで使用されているものに一致 させるため,mangleされているC/C++の識別子とアンダースコアが付いた識別 子の名前を正しくするために,CマクロのF77_FUNC(name,NAME)F77_FUNC_(name,NAME)をそれぞれ定義します.

    Fortran 77は大文字小文字の区別が無く,このために,Fortran 77コンパイラ は全ての識別子を標準的な文字と書式に変換します.CからFortran 77のサブ ルーチンを呼び出したり,Fortran 77から呼び出し可能なC関数を書いたりす るために,CプログラムではFortran 77コンパイラが期待する書式で,識別子 を明示的に使用する必要があります.こうするために,全てのC識別子を AC_F77_WRAPPERSで提供されるマクロの一つで,単純にラッパー関数に します.例えば,以下のようなFortran 77のサブルーチンがあるとします.

          subroutine foobar(x,y)
          double precision x, y
          y = 3.14159 * x
          return
          end
    

    CやC++のプロトタイプで,以下のように宣言します.

    #define FOOBAR_F77 F77_FUNC(foobar,FOOBAR)
    #ifdef __cplusplus
    extern "C"  /* prevent C++ name mangling */
    #endif
    void FOOBAR_F77(double *x, double *y);
    

    正しいものが選択できるように,関数名の大文字と小文字の両方のバージョン をF77_FUNCに渡していることに注意してください.また,Fortran 77 のルーチンへの全てのパラメータを,ポインタとして渡していることにも注意 してください(see section `Mixing Fortran 77 With C and C++' in @acronym{GNU Automake}).

    AutoconfはFortran 77が名前をmangleする手法を検出するために知的な手法で 試みていますが,Fortran 77コンパイラはそれをまだサポートしていないかも しれません.この場合,上記のコードはコンパイル時にエラーとなりますが, それ以外の動作(例えば,Fortranに関連する機能の停止)は,F77_FUNC マクロが定義されているかどうかを調査することで引き起こされます.

    さて,そのようなルーチンをCプログラムから呼び出すために,以下のように してみます.

    {
        double x = 2.7183, y;
        FOOBAR_F77(&x, &y);
    }
    

    Fortran 77の識別子がアンダースコアを含んでいる(例えばfoo_barの) 場合,F77_FUNCの代わりにF77_FUNC_を(同じ引数で)使用すべ きです.これは,アンダースコアを含んでいる場合,Fortran 77コンパイラに よっては異なる名前にmangleするものもあるからです.

    Macro: AC_F77_FUNC (name, @ovar{shellvar})
    識別子nameが与えられている場合,シェル変数shellvarを Fortran 77リンカの規則(AC_F77_WRAPPERSも参照してください)によっ て,mangleされるバージョンのnameを保持するように設定します. shellvarはオプションです.提供されていない場合シェル変数は単純に nameになります.このマクロの目的は,上記のようにCプリプロセッサ を通じてではなく,呼び出し側に名前のmangleに関する情報にアクセスする方 法を与えることで,例えば,C/C++以外の言語からFortranルーチンを呼び出す ためです.

    システムサービス

    以下のマクロはオペレーティングシステムのサービスや機能を調査します.

    Macro: AC_PATH_X
    X Window Systemのインクルードファイルとライブラリの場所を調査します. ユーザがコマンドラインオプションで,`--x-includes=dir'`--x-libraries=dir'を与えている場合,そのディレクトリを使用 します.どちらか一つまたは両方とも与えられない場合,xmkmfを平凡 な`Imakefile'で実行し,生成された`Makefile'を調査し,足りな い値を取得します.(xmkmfが存在しない等のように)失敗した場合,配 置されることが多いディレクトリ等でファイルを検索します.いずれかの手法 で成功した場合,コンパイラがデフォルトで検索するディレクトリに無い限り, シェル変数x_includesx_librariesをその場所に設定します.

    両方の方法が失敗する,またはユーザがコマンドラインオプションの `--without-x'を与えている場合,シェル変数のno_x`yes' に設定し,それ以外では空の文字列に設定します.

    Macro: AC_PATH_XTRA
    AC_PATH_Xの拡張バージョンです.Xが必要とするCコンパイラフラグを 出力変数X_CFLAGSに,XリンカフラグをX_LIBSに追加します.X が利用可能でない場合,X_DISPLAY_MISSINGを定義します.

    また,このマクロは,Xプログラムをコンパイルするためにシステムが必要と する特別なライブラリも調査します.それは,システムが必要とするあらゆる ものを出力変数X_EXTRA_LIBSに追加します.そして,`-lX11'の 前にリンクする必要がある特別なX11R6ライブラリを調査し,見つかったもの は全て出力変数X_PRE_LIBSに追加します.

    Macro: AC_SYS_INTERPRETER
    スクリプトを使用するためのインタプリタを選択するため,`#! /bin/csh'の形式の行を用いたスクリプトをサポートするかどうかを調査しま す.このマクロを実行した後で,`configure.ac'のシェルコードは,シェ ル変数の interpvalを調査することが可能になります.システムで `#!'がサポートされている場合は`yes',そうでなければ`no' を設定します.

    Macro: AC_SYS_LARGEFILE
    @href{http://www.sas.com/standards/large.file/x_open.20Mar96.html, large-file support}のために用意しています.ホストによっては,大きなファ イルにアクセスできるプログラムをビルドするため,特別なコンパイラオプショ ンが必要になります.そのようなオプションを出力変数CCに,全て追 加します.必要な場合は,_FILE_OFFSET_BITS_LARGE_FILES を定義します.

    大きなファイルのサポートは,@option{--disable-largefile}オプションを用 いてコンフィグレーションすることで利用不可能にすることが可能です.

    このマクロを使用する場合,大きなファイルのサポートが利用可能なときは, off_tlongより長いときが一般的なので,それでもプログラ ムが動作するかどうかを調査してください.例えば,printf ("%ld", (long) X)で任意のoff_tの値Xを出力しても正しくなくなりま す.

    Macro: AC_SYS_LONG_FILE_NAMES
    システムが14文字より長いファイル名をサポートする場合, HAVE_LONG_FILE_NAMESを定義します.

    Macro: AC_SYS_POSIX_TERMIOS
    @acronym{POSIX} termiosヘッダと関数がシステムで利用可能かどうかを調査 します.その場合は,シェル変数ac_cv_sys_posix_termios`yes'に設定します.それ以外ではその変数を`no'に設定します.

    様々なUNIX

    以下のマクロは,ヘッダファイルやライブラリが例外的に特異なため,プログ ラムに対して特別な処理が必要なオペレーティングシステムを調査します.こ れらのマクロは不要なものです.利用可能にする関数や,供給する環境に基づ き,より規則正しい手法で置換されるでしょう.

    Macro: AC_AIX
    @acronym{AIX}の場合,_ALL_SOURCEを定義します.いくつかの @acronym{BSD}関数の使用を許可します.Cコンパイラを実行するあらゆるマク ロの前に呼び出すべきです.

    Macro: AC_GNU_SOURCE
    @acronym{GNU} Cライブラリを使用している場合,_GNU_SOURCEを定義 します.いくつかの@acronym{GNU}の関数が使用可能になります.Cコンパイラ を実行するマクロの前で呼び出すべきです.

    Macro: AC_ISC_POSIX
    INTERACTIVE UNIX (@acronym{ISC})に対して,@acronym{POSIX}の機能が 必要な場合,出力変数LIBSに@option{-lcposix}を追加します.これは AC_PROG_CCの後で,@acronym{POSIX}インターフェースを使用するその 他のマクロの前で呼び出してください.INTERACTIVE UNIXはすでに販売 されておらず,Sunは2006-07-23でサポートを終了することを告げているので, このマクロは時代遅れになっています.

    Macro: AC_MINIX
    Minixの場合,_MINIX_POSIX_SOURCEを定義し, _POSIX_1_SOURCEを2と定義します.これで@acronym{POSIX}の機能が使 用可能になります.Cコンパイラを実行するあらゆるマクロの前で呼び出すべ きです.


    Go to the first, previous, next, last section, table of contents.