5. 存在の調査

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

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

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

5.1 共通の動作

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

5.1.1 標準的なシンボル

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

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

AC_CHECK_TYPES(struct $Expensive*)

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

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

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

#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 ヘッダファイル)．

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

Macro: AC_DEFAULT_INCLUDES ([include-directives])

include-directivesが定義されている場合はそれを展開し，そうでなけれ ば以下のようになります．

#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

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

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

5.2 プログラムの選択

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

5.2.1 特定のプログラムの調査

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

Macro: AC_PROG_AWK

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

Macro: AC_PROG_EGREP

grep -Eとegrepをこの順番で調査し，最初に見つかったもので出 力変数EGREPを設定します．

Macro: AC_PROG_FGREP

grep -Fとfgrepをこの順番で調査し，最初に見つかったもので出 力変数FGREPを設定します．

Macro: AC_PROG_INSTALL

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

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

使用可能な`install-sh'のコピーは，Autoconfでインストールされます． AC_PROG_INSTALLを使用する場合，配布物に`install-sh'か `install.sh'を含める必要があり，そうしない場合，configure は見つからない旨，エラーメッセージを出力します -- たとえシステムに良い installがあってもそうなります．この調査は，そのファイルをたまたま 入れ忘れることを阻止する安全対策で，それは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'です が異なることもあります．これらは，結果としてlexとflexのど ちらが使用されているかに依存して変化します．

普通の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

シェルスクリプト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'に設定し ます．

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

これらのマクロは，"特定の"テストマクロによってカバーされていないプログ ラムを見つけるに使用します．プログラムの存在を確認するだけでなく，その動 作を調査する必要がある場合，そうするために独自のテストを書く必要がありま す(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, [value-if-not-found], [path], [reject])

PATHに，プログラムprog-to-check-forが存在するかどうか調査し ます．見つかった場合，variableをvalue-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, [value-if-not-found], [path])

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

Macro: AC_CHECK_TOOL (variable, prog-to-check-for, [value-if-not-found], [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, [value-if-not-found], [path])

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

Macro: AC_PATH_PROG (variable, prog-to-check-for, [value-if-not-found], [path])

AC_CHECK_PROGに似ていますが，見つかった場合，variableを prog-to-check-forの完全なパスに設定します．

Macro: AC_PATH_PROGS (variable, progs-to-check-for, [value-if-not-found], [path])

AC_CHECK_PROGSに似ていますが，progs-to-check-forのどれかが 見つかった場合，variableをプログラムが見つかった完全なパスに設定し ます．

Macro: AC_PATH_TOOL (variable, prog-to-check-for, [value-if-not-found], [path])

AC_CHECK_TOOLに似ていますが，見つかった場合，variableをプロ グラムが見つかった完全なパスに設定します．

5.3 ファイル

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

Macro: AC_CHECK_FILE (file, [action-if-found], [action-if-not-found])

ネイティブシステムにfileが存在するかどうか調査します．見つかった場 合，action-if-foundを実行し，それ以外では，与えられていれば action-if-not-foundを実行します．

Macro: AC_CHECK_FILES (files, [action-if-found], [action-if-not-found])

filesでリストアップされているそれぞれのファイルに対し， AC_CHECK_FILEを一度実行します．さらに，見つかったそれぞれのファイ ルに対して`HAVEfile'を定義します(see section 標準的なシンボル)．

5.4 ライブラリファイル

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

Macro: AC_CHECK_LIB (library, function, [action-if-found], [action-if-not-found], [other-libraries])

現在の言語に依存して(see section 言語の選択)，テストプログラムが関数利 用に必要なライブラリlibraryとリンク可能かどうかを調査することで，C， C++やFortranの関数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, [action-if-found], [action-if-not-found], [other-libraries])

まだ利用可能ではない，functionを定義しているライブラリを探します． これは，最初にライブラリ無しで，その後でそれぞれのライブラリを search-libsにリストアップしている `AC_LINK_IFELSE([AC_LANG_CALL([], [function])])'の呼び出しと 等価です．

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

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

5.5 ライブラリ関数

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

5.5.1 C関数の移植性

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

exit

古いホストでは，exitがintを返すものがあることを御存知です か？これは，exitのほうがvoidより時代が古く，int を 返すという伝統が長い間あったためです．

putenv

POSIXでは，putenvは与えられた文字列を直接environに書き込む ように指定していますが，システムによってはその代わりにコピーするものもあ ります(例えば，glibc 2.0やBSD)．そして，コピーが作成されたとき， unsetenvはそれを解放し，メモリリークの原因になります(例えば， FreeBSD 4がそうです)．

POSIXでは，putenv("FOO")は`FOO'を環境変数から削除するように 指定していますが，システムによっては(例えばFreeBSD 4)，こうならないので， 代わりにunsetenvを使用して下さい．

MINGWでは，putenv("FOO=")の呼び出しで，空の値を挿入する代わりに， `FOO'を環境変数から削除します．

signalハンドラ

通常，signalはvoidの型を返す関数へのハンドルを受け取ります が，古いシステムには，代わりにintを要求するものもあります．実際に 返されるintの値を利用しませんが，これは関数のプロトタイプの要求が 異なるだけです．

現在知っているシステムはすべてvoidを受け取ります．おそらく， intがK&R Cでサポートされていたのですが，もちろんvoidは利用 可能ではありませんでした．AC_TYPE_SIGNAL (see section 特定の型の調査)は，すべての状況で正しい型を構築するために使用することが可能です．

snprintf

ISO C99標準では，出力配列があまり大きくなくその他のエラーが無い場合， snprintfとvsnprintfは出力を切捨て，生成された出力が必要と するバイト数を返すことになっています．古いシステムでは切り捨てられた長さ を返したり(例えば，GNU Cライブラリ2.0.xやIRIX 6.5)，負の 値を返したり(例えば，より古いバージョンのGNU Cライブラリ)，切 り捨てられなかったバッファの長さを返したり(例えば32ビットのSolaris 7)し ます．また，バグの多い古いシステムにはバッファの長さとオーバーランを無視 するもの(例えば64ビットのSoraris 7)もあります．

sprintf

ISO Cの標準では，sprintfとvsprintfは書き込まれたバイト数を 返すことになっていますが，古いシステム(例えばSunOS 4)ではその代わりにバッ ファへのポインタを返すものもあります．

sscanf

様々な古いシステム，例えばHP-UX 9では，sscanfは入力文字列が(たと えそれが実際には変更されなくても)書き込み可能であることを要求します．こ れは，gccは通常，固定文字列を読み込み専用のメモリに書き込むの で(see Incompatibilities of GCC: (gcc)Incompatibilities section `Incompatibilities' in Using and Porting the GNU Compiler Collection)，それを使用するとき問題 になるはずです．場合によっては，フォーマット文字列が明らかに読み込み専用 であっても問題になるはずです．

strnlen

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

sysconf

_SC_PAGESIZEは標準ですが，古いシステム(例えばHP-UX 9)には，代わり に_SC_PAGE_SIZEが存在します．これは#ifdefでテスト可能です．

unlink

POSIXの仕様では，unlinkは開かれているファイルへのハンド ルがなくなった後でファイルを削除するように述べられています．全てのOS が この動作をサポートしているわけではありません．そのため，システムが unlinkを提供している場合でも，開いているファイルに対して呼び出し ても大丈夫だと仮定した移植は不可能です．例えば，Windows 9xとMEでは，その ような呼び出しは失敗します．DOSは可能ですが，OSが削除した後に ファイルへの書き込みが終了するので，ファイルシステムが駄目になります．

unsetenv

MINGWでは，unsetenvが利用不可能ですが，putenvで上述したよ うに，変数`FOO'はputenv("FOO=")の呼び出しで削除可能です．

va_copy

ISO C99標準では，va_listをコピーするためva_copyを提供して います．古い環境でも利用可能かもしれませんが，おそらくは __va_copy(例えば厳密なC89モード)でしょう．これらは#ifdef でテスト可能です．memcpy (&dst, &src, sizeof(va_list))で代替する ことで最大の移植性となるでしょう．

va_list

va_listはポインタである必要はありません．struct(例えば Alphaのgcc)にすることが可能で，それはNULLでは移植性が無 いことを意味します．配列(例えばPowerPCでコンフィグレーションされた gcc)も可能で，それは関数のパラメータとして効果的に参照呼び出し が可能であり，ライブラリルーチンで呼び出しが返す値を修正する可能性がある (例えばGNU Cライブラリ2.1のvsnprintf)ことを意味します．

符合付の>>

通常，Cの符号付きの右シフト>>はハイビットを複製し，いわゆる"算術" シフトになります．しかし，ISO Cの標準ではその動作を要求していないので， 注意すべきです．ネイティブの算術シフトが無いプロセッサ(例えばCrayベクター システム)では，符号無しのシフトと同様に，ゼロビットがシフトインされる可 能性があります．

5.5.2 特定の関数の調査

これらのマクロは -- その存在にかかわらず -- 特定の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を使用するソースファイルでは，正確に宣言するために，以下の ようなコードで始めるべきです．AIXのバージョンによっては， allocaの宣言を，コメントとプリプロセッサディレクティブ以外の，全 ての行の前に書く必要があります．#pragmaディレクティブは， 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関数が利用可能で動作する場合(特に，uidとgid に 対する`-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関数がPOSIX準拠の場合，HAVE_FNMATCHを定義 します．例えば，Solaris 2.4のバグのような，一般的な実装上のバグを検出し ます．

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

Macro: AC_FUNC_FNMATCH_GNU

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

Macro: AC_FUNC_FORK

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

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

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

#if !HAVE_WORKING_VFORK # define vfork fork #endif

Macro: AC_FUNC_FSEEKO

fseeko関数が利用可能な場合，HAVE_FSEEKOを定義します．必要 があれば，プロトタイプがいくつかのシステム上で(例えばglibc 2.2)見て分か るように，_LARGEFILE_SOURCEを定義します．それ以外では， AC_SYS_LARGEFILEを用いてコンパイルするとき，off_tがデフォ ルトで64bitになっていないラージファイルに問題があるシステム上で，リンク の問題が発生する可能性があります．

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で確実に設定してください (一般の関数の調査と，AC_CONFIG_LIBOBJ_DIRを参照してくださ い)．

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

1. C_GETLOADAVGを定義します．

2. システムが，SVR4，DGUX，UMAX，または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を定義しま す．これはPOSIXの動作です．古いBSDシステムでは，それ は引数をとり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_LIBOBJをlstatで置換するよう 要求します．

Macro: AC_FUNC_MALLOC

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

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

#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'を置換することを要求します．このテストの 目的に対して，mktimeはPOSIXに準拠すべきで， localtimeの反対になっているべきです．

Macro: AC_FUNC_MMAP

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

Macro: AC_FUNC_OBSTACK

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

Macro: AC_FUNC_REALLOC

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

Macro: AC_FUNC_SELECT_ARGTYPES

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

Macro: AC_FUNC_SETPGRP

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

Macro: AC_FUNC_STAT

Macro: AC_FUNC_LSTAT

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

その場合，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のエラーナンバーを返します．POSIXで はstrerror_rがintを返すように要求していますが，多くのシス テムのスレッドセーフな関数のオプション(例えばGNU Cライブラリの バージョン2.2.4を含む)は，バッファ引数に等しい必要が無いchar * の 値を返します．

Macro: AC_FUNC_STRFTIME

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

Macro: AC_FUNC_STRNLEN

strnlenが利用不可能な場合や(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が利用可能な場合，vfprintfとvsprintfも利用 可能だと仮定できるでしょう．)

Macro: AC_REPLACE_FNMATCH

fnmatch関数がPOSIX準拠でない場合(AC_FUNC_FNMATCH を参照してください)，それをAC_LIBOBJで置換するかどうかを尋ねます．

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

5.5.3 一般の関数の調査

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

Macro: AC_CHECK_FUNC (function, [action-if-found], [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…, [action-if-found], [action-if-not-found])

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

Autoconfは，移植性について苦心してきた人々によって，何年もかけて形作られ てきた哲学に従います．特定のファイルの移植性の問題と，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)'で対応します．

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

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

Macro: AC_REPLACE_FUNCS (function…)

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

5.6 ヘッダファイル

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

5.6.1 ヘッダの移植性

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

`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'は，委員会で作成されたようです．

`linux/irda.h'

それは，`linux/types.h'と`sys/socket.h'を要求します．

`linux/random.h'

それは，`linux/types.h'を要求します．

`net/if.h'

Darwin上では，このファイルは`sys/socket.h'がそれ以前にインクルード されていることを要求します．以下のように実行すべきです．

AC_CHECK_HEADERS([sys/socket.h]) AC_CHECK_HEADERS([net/if.h], [], [], [#include <stdio.h> #if STDC_HEADERS # include <stdlib.h> # include <stddef.h> #else # if HAVE_STDLIB_H # include <stdlib.h> # endif #endif #if HAVE_SYS_SOCKET_H # include <sys/socket.h> #endif ])

`netinet/if_ether.h'

Darwin上では，このファイルは`stdio.h'と`sys/socket.h'がそれ以 前にインクルードされていることを要求します．以下のように実行すべきです．

AC_CHECK_HEADERS([sys/socket.h]) AC_CHECK_HEADERS([netinet/if_ether.h], [], [], [#include <stdio.h> #if STDC_HEADERS # include <stdlib.h> # include <stddef.h> #else # if HAVE_STDLIB_H # include <stdlib.h> # endif #endif #if HAVE_SYS_SOCKET_H # include <sys/socket.h> #endif ])

`stdint.h'

上記の`inttypes.h'対`stdint.h'を参照して下さい．

`stdlib.h'

多くのシステム上で(例えばDarwin)，`stdio.h'が必須になります．

`sys/mount.h'

ia32のFreeBSD 4.8と，gccのバージョン2.95.4を使用しているシステムでは， `sys/params.h'が必須になります．

`sys/socket.h'

Darwin上では，`stdlib.h'が必須になります．

`sys/ucred.h'

HP Tru64 5.1上では，`sys/types.h'が必須になります．

`X11/extensions/scrnsaver.h'

XFree86を使用している場合は，このヘッダは`X11/Xlib.h'を要求し，おそ らくそれを探すことを考えなくても良いでしょう．

AC_CHECK_HEADERS([X11/extensions/scrnsaver.h], [], [], [[#include <X11/Xlib.h> ]])

5.6.2 特定のヘッダの調査

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

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'がmajor，minor，そしてmakedevを定 義していないが，`sys/mkdev.h'が定義している場合， MAJOR_IN_MKDEVを定義します．それ以外の場合で， `sys/sysmacros.h'が定義している場合は，MAJOR_IN_SYSMACROS を 定義します．

Macro: AC_HEADER_STAT

`sys/stat.h'で定義されているS_ISDIR，S_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' には以下のコードを含めるべきです．

#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

システムにANSI Cヘッダファイルが存在する場合， STDC_HEADERSを定義します．特にこのマクロは，`stdlib.h'， `stdarg.h'，`string.h'，そして`float.h'を調査し，システム にそれらが存在している場合は，おそらくANSI Cヘッダーファイルの 残りも存在します．同様に，このマクロは`string.h'がmemchrを宣 言(他のmem関数もおそらく存在)しているかどうか，`stdlib.h'が freeを宣言(mallocや他の関連する関数もおそらく存在)している かどうか，そして，`ctype.h'マクロが，ANSI Cが要求するハイ ビットセット文字でも動作するかどうかを調査します．

GCCがあるシステムの多くはANSI Cヘッダファイルが存在していない ので，システムにANSI対応のヘッダファイル(そして，おそらくC ラ イブラリ関数) が存在していることを決定するために，__STDC__の代わ りにSTDC_HEADERSを使用してください．

ANSI Cヘッダが無いシステムには多くの変種が存在していて，そこで は，システムヘッダファイルが宣言しているものを正確に理解するより，使用す る関数を宣言する方がより容易でしょう．ANSIとBSDの関 数が混在しているシステムもあります．ほとんどANSIだが `memmove'が無いものもあります．BSD関数が`string.h'や `strings.h' でマクロで定義されているものもあります．BSD関 数しか持っていないが `string.h'が存在するものもあります．メモリ関数 が`memory.h'で定義されていて，`string.h'でも定義されているもの もあります．等々いろいろなシステムがあります．一つの文字列関数と一つのメ モリ関数を調査すれば恐らく十分です．ライブラリに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

BSDとは異なるmemchr，memset，strtok，また は strspnの様な関数を使用する場合，マクロは不十分でしょう．それぞ れの関数を実装する必要があります．(システムのCライブラリのものが，手動で 最適化されているかもしれないので)必要なときだけ実装を組み込む簡単な方法 として，例えばmemchrを使用する場合は，それを`memchr.c'に書き 込み，`AC_REPLACE_FUNCS(memchr)'を使用することです．

Macro: AC_HEADER_SYS_WAIT

`sys/wait.h'が存在して，POSIXと互換性がある場合， HAVE_SYS_WAIT_Hを定義します．非互換性は，`sys/wait.h'が存在 しない場合や，ステータスの値を保存するため，intの代わりに古い BSDのunion wait使用する場合に生じます． `sys/wait.h'がPOSIXと互換性がない場合，それをインクルード する代わりに，それらの通常の解釈を用いて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'がPOSIXシステムに含まれている場合， _POSIX_VERSIONが定義されます．`unistd.h'が無い場合，明らかに POSIXシステムではありません．しかし，`unistd.h'を持つ POSIXではないシステムもあります．

システムが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

5.6.3 一般的なヘッダの調査

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

Macro: AC_CHECK_HEADER (header-file, [action-if-found], [action-if-not-found], [includes = `default-includes'])

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

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

Macro: AC_CHECK_HEADERS (header-file…, [action-if-found], [action-if-not-found], [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'を探す場合，以下の手法を提案します．

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

5.7 宣言

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

5.7.1 特定の宣言の調査

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

5.7.2 一般的な宣言の調査

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

Macro: AC_CHECK_DECL (symbol, [action-if-found], [action-if-not-found], [includes = `default-includes'])

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

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

Macro: AC_CHECK_DECLS (symbols, [action-if-found], [action-if-not-found], [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

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

5.8 構造体

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

5.8.1 特定の構造体の調査

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

Macro: AC_STRUCT_ST_BLKSIZE

struct statがst_blksizeメンバーを含んでいる場合， HAVE_STRUCT_STAT_ST_BLKSIZEを定義します．これまでの名前 HAVE_ST_BLKSIZEは，将来サポートを中止するので避けてください．この マクロは時代遅れで，以下のもので置換すべきです．

AC_CHECK_MEMBERS([struct stat.st_blksize])

Macro: AC_STRUCT_ST_BLOCKS

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

Macro: AC_STRUCT_ST_RDEV

struct statがst_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 tmにtm_zone メンバーが存在する場合，HAVE_STRUCT_TM_TM_ZONE (と時代遅れの HAVE_TM_ZONE)を定義します．それ以外では，外部配列のtzname が見つかる場合，HAVE_TZNAMEを定義します．

5.8.2 一般的な構造体の調査

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

Macro: AC_CHECK_MEMBER (aggregate.member, [action-if-found], [action-if-not-found], [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, [action-if-found], [action-if-not-found], [includes = `default-includes'])

直前のマクロで使用されているmembersのそれぞれの `aggregate.member'の存在を調査します．memberが aggregateに属しているとき， HAVE_aggregate_member を(全て大文字で，スペースとドッ トをアンダースコアで置換しながら)定義します．action-if-foundが与え られている場合，メンバーが見つかるたびにそれを実行します． action-if-not-foundが与えられている場合，メンバーが見つからないた びに実行されます．

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

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

5.9 型

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

5.9.1 特定の型の調査

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

Macro: AC_TYPE_GETGROUPS

gid_tとintのどちらかを，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'が，signalをvoid返す関数へのポインタを返す ものと宣言されている場合，RETSIGTYPEをvoidと定義します．そ れ以外ではintと定義します．

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

RETSIGTYPE hup_handler () { … }

Macro: AC_TYPE_SIZE_T

`AC_CHECK_TYPE(size_t, unsigned)'と同じです．

Macro: AC_TYPE_UID_T

uid_tが定義されていない場合，uid_tをintに，そして gid_tをintに定義します．

5.9.2 一般的な型の調査

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

Macro: AC_CHECK_TYPE (type, [action-if-found], [action-if-not-found], [includes = `default-includes'])

typeが定義されているかどうかを調査します．コンパイラ組み込みの型や， includes(see section デフォルトのインクルード)で定義されている可能性があります．

Macro: AC_CHECK_TYPES (types, [action-if-found], [action-if-not-found], [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のドキュメントを読んでください． 時代遅れのマクロを参照してください．

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

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

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

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

5.10.1 特定のコンパイラの特徴

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

スタティック/ダイナミックな式

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にキャストするこ とで，この問題を解決します．

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

Macro: AC_CHECK_SIZEOF (type, [unused], [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に定義します．

Macro: AC_LANG_WERROR

通常，Autoconfはコンパイラ，リンカ，そしてプリプロセッサが生成する警告を 無視します．このマクロが使用されている場合，現在の言語に対し，警告は重大 なエラーとして処理されます．このマクロは，コンフィグレーションの結果が， 予期せぬ警告が生じる場所で使用されるとき役に立ちます．例えば，プログラム の一部を`-Werror'オプションでビルドしている場合があてはまります．プ ログラム全体を`-Werror'を使用してビルドしている場合，コンパイラフラ グに単純に(CFLAGSなどで)`-Werror'を追加したほうがより単純で しょう．

5.10.3 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'で呼び 出すことで問題を解決します．

正しい#lineのサポートに依存しないで下さい

Solaris 8上で，c89(Sun WorkShop 6 update 2 C 5.3 Patch 111679-08 2002/05/09))は行番号全体で32767より大きな#line指示語を 拒絶します．さらにPOSIXでは，これは有効になっていません．これは， Autoconfが#line指示語の生成を停止した理由です．

Macro: AC_PROG_CC ([compiler-search-list])

使用するCコンパイラを決定します．CCが環境変数で設定されていない場 合，gccとccを調査し，その後で他のCコンパイラを調査します． 出力変数CCを，見つかったコンパイラの名前に設定します．

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

AC_PROG_CC(cl egcs gcc cc)

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

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

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

Macro: AC_PROG_CC_C_O

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

Macro: AC_PROG_CPP

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

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

Macro: AC_PROG_CPP_WERROR

これはAC_PROG_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 ([action-if-true], [action-if-false], [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コンパイラが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を空で定義することで誤魔化すことは不可能です．

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

Macro: AC_C_RESTRICT

Cコンパイラがrestrictキーワードを認識する場合は何もしません． (__restrict，__restrict__，または_Restrict)という， かわったつづりだけを認識する場合，restrictをそれに定義します．そ れ以外では，restrictを空で定義します．このため，プログラムでは restrictをすべてのCコンパイラがサポートしているかのように，単純に 使用してかまいません．そうしない人は，`Makefile'やコンフィグレーショ ンヘッダで頑張って定義して下さい．

C++でのrestrictキーワードサポートは要求されていませんが，いくつか のC++コンパイラはそのキーワードを受け入れます．このマクロは，そこでも動 作します．

Macro: AC_C_VOLATILE

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

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

一般的に，volatileキーワードは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

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

5.10.4 C++コンパイラの特徴

Macro: AC_PROG_CXX ([compiler-search-list])

使用するC++コンパイラを定義します．環境変数CXXやCCCが設定 されているかどうか(この順番で)調査します．その場合，出力変数をその値に設 定します．

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

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

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

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

Macro: AC_PROG_CXXCPP

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

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

5.10.5 Fortranコンパイラの特徴

AutoconfのFortranサポートは，二つのカテゴリに分けられました．これまでの Fortran 77マクロ(F77)と，現在のFortramマクロ(FC)です．前者 は伝統的なFortram 77コードを想定していて，F77，FFLAGS，そ してFLIBSといった出力変数があります．後者は，より新しいFortranの 標準の元でコンパイル可能(または必須)である，より新しいプログラムを想定し ていて，FC，FCFLAGS，そしてFCLIBSといった出力変数が あります．

二つの新しいマクロAC_FC_SRCEXTとAC_FC_FREEFORM(以下を参照) 以外では，FCとF77のマクロの動作はほとんど同じなので，この セクションでまとめて説明しています．

Macro: AC_PROG_F77 ([compiler-search-list])

使用するFortran 77コンパイラを決定します．F77が環境変数でまだ設定 されていない場合，g77，f77，そしてその他の名前を調査します． 見つかったコンパイラ名を，出力変数F77に設定します．

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

AC_PROG_F77(fl32 f77 fort77 xlf g77 f90 xlf90)

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

Macro: AC_PROG_FC ([compiler-search-list], [dialect])

使用するFortranコンパイラを決定します．FCが環境変数でまだ設定され ていない場合，dialectが検索しているFortran dialect何かを示すヒン トになります．デフォルトとして，利用可能なdialectの最も新しいものを検索 します．見つかったコンパイラ名を出力変数FCに設定します．

デフォルトで，より新しいdialectがより古いdialectに代わって選択されますが， dialectが指定されている場合，指定されているdialectで始まる，より 古いdialectが選択されます．dialectは，現在Fortran 77，Fortran 90， またはFortran 95が可能です．しかし，これは選択されるコンパイラの名 前のヒント(例えば，f90またはf95)になるだけで，特定の言語 の標準を実際にサポートしていることへの保証は試みません．このため， dialectオプションを避け，AC_PROG_FCだけを最も新しいFortran 標準に互換性のあるコード対して使用した方が良いでしょう．

また，このマクロは，最初のオプション引数を指定して呼び出される場合，それ は，AC_PROG_F77と同様に，検索するFortranコンパイラをスペースで分 離したリストにする必要があります．

出力変数FCFLAGSが環境変数で設定されていない場合，GNU g77に 対してはそれを`-g -02'に(または，g77が`-g'を受け入 れないところでは`-O2'に)設定します．それ以外では，すべてのFortran コンパイラに対し，FCFLAGSを`-g'に設定します．

Macro: AC_PROG_F77_C_O

Macro: AC_PROG_FC_C_O

Fortranコンパイラが，オプション`-c'と`-o'を同時にを受け入れる かどうかテストし，そうでない場合は，それぞれ F77_NO_MINUS_C_MINUS_OまたはFC_NO_MINUS_C_MINUS_Oを定義し ます．

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

Macro: AC_F77_LIBRARY_LDFLAGS

Macro: AC_FC_LIBRARY_LDFLAGS

Fortranプログラムや共有ライブラリをうまくリンクするために必要な Fortranのイントリンシックとランタイムライブラリ(Fortran intrinsic and run-time libraries)に対して，リンカフラグ(例えば`-L' と `-l')を決定します．出力変数 FLIBSやFCLIBSには，これら のフラグが設定されます(それらはリンク時にLIBSの後に含めるべきです)．

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

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

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

マクロAC_F77_DUMMY_MAIN/AC_FC_DUMMY_MAINや AC_F77_MAIN/AC_FC_MAINは，FortranでC/C++にリンクする必要が あるときもおそらく必要です．以下を参照してください．

Macro: AC_F77_DUMMY_MAIN ([action-if-found], [action-if-not-found])

Macro: AC_FC_DUMMY_MAIN ([action-if-found], [action-if-not-found])

多くのコンパイラでは，AC_F77_LIBRARY_LDFLAGSや AC_FC_LIBRARY_LDFLAGSで見つかるFortranライブラリは，Fortran I/Oの ようなものを初期化したり，ユーザプログラムを実行するために，(いわゆる) MAIN__のような名前を持つユーザ提供のエントリー関数を呼び出す，独 自のmainエントリー関数を提供しています． AC_F77_DUMMY_MAIN/AC_FC_DUMMY_MAINや AC_F77_MAIN/AC_FC_MAINマクロは，この相互作用を扱う方法を理 解します．

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

デフォルトで，必要な場合は，action-if-foundは F77_DUMMY_MAINやFC_DUMMY_MAINをこのルーチン名(例えば MAIN__)に定義します．[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

(Fortran 77ではなくFortranに対しては，F77をFCで置換して下 さい．)

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

Macro: AC_F77_MAIN

Macro: AC_FC_MAIN

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

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

Macro: AC_F77_WRAPPERS

Macro: AC_FC_WRAPPERS

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

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

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 (automake)Mixing Fortran 77 With C and C++ section `Mixing Fortran 77 With C and C++' in GNU Automake)．

(Fortran 77の代わりに，Fortranに対してはF77はFCで置換して 下さい．)

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

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

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

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

Macro: AC_F77_FUNC (name, [shellvar])

Macro: AC_FC_FUNC (name, [shellvar])

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

Macro: AC_FC_SRCEXT (ext, [action-if-success], [action-if-failure])

デフォルトで，FCマクロは，ソースコードファイルを`.f'の拡張子 を使用しているテストを実行します．しかし，コンパイラによっては，適切なファ イル名に対してのみ，より新しい言語の機能を利用可能にし，例えば，Fortran 90の機能は`.f90'ファイルだけになります．一方，すべてのソースファイ ルが`.f'で終わることを期待していて，他のファイル名の拡張子をサポー トするためには特殊なフラグが必要になります．AC_FC_SRCEXTマクロは 両方の問題を扱います．

AC_FC_SRCEXTは，拡張子ext(すなわち，extにはドットは含 まれません)で終わるファイルを受け入れるFCコンパイラの取得 を試みます．こうするために特定のコンパイラフラグが必要な場合，それを出力 変数FCFLAGS_extに保存します．この拡張子とこのフラグは (AC_FC_SRCEXTが再び呼び出されるまで)，それ以降に呼び出されるすべ てのFCで使用されます．

例えば，機能テストで`.f90'の拡張子を用いるため， AC_FC_SRCEXT(f90)を使用し，そのようなファイルをコンパイルするため に必要な追加フラグがあれば，FCFLAGS_f90出力変数を設定します．

FCFLAGS_extを単純にFCFLAGSに書き込むことは不可 能で，それにはコンパイラの制限に起因する二つの理由があります．最初のも のは，一度に一つのFCFLAGS_extが使用可能なので，ことなる拡張 子を持つファイルは別々にコンパイルする必要があるためです．二番目のものは， FCFLAGS_extはコンパイル時のソースコードのファイル名の 直前に書く必要があるためです．そのため，上記の例を続けると，以下 のコマンドを持つMakefileで`foo.f90'ファイルがコンパイルされるでしょ う．

foo.o: foo.f90 $(FC) -c $(FCFLAGS) $(FCFLAGS_f90) foo.f90

extの拡張子を持つファイルのコンパイルでAC_FC_SRCEXTが成功す る場合，それは[action-if-success](デフォルトでは何もしません)を呼び 出します．失敗した場合と，FCコンパイラにそのようなファイルを受け 入れさせる方法が見つからない場合，[action-if-failure](デフォルトは エラーメッセージとともに終了します)を呼び出します．

Macro: AC_FC_FREEFORM ([action-if-success], [action-if-failure])

AC_FC_FREEFORMは，Fortranコンパイラ($FC)でフリーフォーマッ トのソースコードが可能であることの確認を試みます(逆に，Fortran 77はより 古い固定フォーマット形式です)．必要な場合，FCFLAGSに追加フラグを 加えてもかまいません．

デフォルトの`.f'拡張子を使用している場合，追加のフラグが提供されて いない限り，多くのコンパイラがこの拡張子を固定フォーマットのソースコード であると解釈するので，このマクロが最も重要です．`.f90'や`.f95' のように，異なる拡張子をAC_FC_SRCEXTで指定している場合， AC_FC_FREEFORMは，通常，FCFLAGSを編集することなく成功しま す．

AC_FC_FREEFORMはフリーフォームのソースのコンパイルで成功する場合， それは[action-if-success](デフォルトでは何もしません)を呼び出します． 失敗した場合，[action-if-failure](デフォルトはエラーメッセージとと もに終了します)を呼び出します．

5.11 システムサービス

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

Macro: AC_PATH_X

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

large-file supportのために用意しています．ホストによっては，大きなファ イルにアクセスできるプログラムをビルドするため，特別なコンパイラオプショ ンが必要になります．そのようなオプションを出力変数CCに，全て追加 します．必要な場合は，_FILE_OFFSET_BITSと_LARGE_FILES を定 義します．

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

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

LFSはfseekoとftello関数を，Cのoff_tを使用していない fseekとftellに相当するものを置き換えるために導入しました． それらの関数を使用しているときで，大きなファイルのサポートが利用可能になっ ているときに，利用可能なプロトタイプを作成するために AC_FUNC_FSEEKOを注意して使用して下さい．

Macro: AC_SYS_LONG_FILE_NAMES

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

Macro: AC_SYS_POSIX_TERMIOS

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

5.12 様々なUNIX

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

Macro: AC_AIX

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

Macro: AC_GNU_SOURCE

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

Macro: AC_ISC_POSIX

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

Macro: AC_MINIX

Minixの場合，_MINIXと_POSIX_SOURCEを定義し， _POSIX_1_SOURCEを2と定義します．これでPOSIXの機能が使用 可能になります．Cコンパイラを実行するあらゆるマクロの前で呼び出すべきで す．

This document was generated by Akihiro Sagawa on June, 15 2005 using texi2html 1.70.