以下のマクロは,パッケージが必要とする,あるいは使用する,特定のシステ ムの特徴をテストします.これらのマクロが調査しない特徴のテストが必要な 場合,適切な引数で基本のテストマクロを呼び出すことで,おそらく可能です (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
は定義されません.
これらのマクロは,特定のプログラムとその動作を調査します.それらは,い くつかのプログラムからどれかを選択し,一旦選ばれると何をするのかを決定 するために使用されます.必要なプログラムを調査するために特別に定義され ているマクロが無い場合,一般的なプログラム調査のマクロの一つを使用する ことが可能です.
以下のマクロは,特定のプログラムを調査します -- それは存在するかどう か,そして場合によっては特定の機能をサポートするかどうかです.
gawk
,mawk
,nawk
,そしてawk
を,この順番で
調査し,最初に見つかったものに出力変数AWK
を設定します.最良の実
装と報告されているので,最初にgawk
を調査します.
grep -E
とegrep
をこの順番で調査し,最初に見つかったもので
出力変数EGREP
を設定します.
grep -F
とfgrep
をこの順番で調査し,最初に見つかったもので
出力変数FGREP
を設定します.
PATH
で@acronym{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'を使
用することも可能ですが,@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'ファ
イルにプログラムのファイル名を書き込んでください.
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
シェルスクリプト@command{missing}は,Automakeの配布物で見つかるはずで す.
下位互換を確実にするため,AutomakeのAM_PROG_LEX
は,(間接的に)こ
のマクロを二回呼び出し,不快な"AC_PROG_LEX
invoked multiple
times" で始まる警告を生じます.将来のバージョンのAutomakeではこの症状
は修正されるでしょう.それまで,このメッセージを無視してください.
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)
ranlib
が見つかった場合,出力変数RANLIB
を`ranlib'に
設定し,それ以外では,`:'(何もしません)に設定します.
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 出力変数の設定.
PATH
に,プログラムprog-to-check-forが存在するかどうか調査
します.見つかった場合,variableをvalue-if-foundに設定し,
それ以外で,value-if-not-foundが与えられている場合は,それに設定
します.たとえreject(絶対パスのファイル名)が最初のサーチパスで見
つかった場合でも,それは候補から外します.この場合,
prog-to-check-forが見つかったrejectではない絶対パスのファ
イル名を使用し,variableを設定します.variableが既に設定さ
れている場合,何もしません.variableに対してAC_SUBST
を呼
び出してください.
PATH
に存在するかどうかを調査します.見つかった場合,
variableをプログラムの名前に設定します.それ以外の場合は引続き,
リストの次にあるプログラムを調査します.リスト内のプログラムが全く見つ
からない場合, variable をvalue-if-not-foundに設定します.
value-if-not-foundが指定されていない場合,variableは変更さ
れません.variableに対してAC_SUBST
を呼び出してください.
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'に設定し,どちらも無い場合は `:'に設定します.
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
を呼び出してくださ
い.
AC_CHECK_PROG
に似ていますが,見つかった場合,variableを
prog-to-check-forの完全なパスに設定します.
AC_CHECK_PROGS
に似ていますが,progs-to-check-forのどれか
が見つかった場合,variableをプログラムが見つかった完全なパスに設
定します.
AC_CHECK_TOOL
に似ていますが,見つかった場合,variableをプ
ログラムが見つかった完全なパスに設定します.
ファイルの存在を調査する必要もあるでしょう.以下のマクロを使用する前に, 実行時の調査がより良い解決ではないかどうか自問してください.ほとんどの Autoconfマクロのように,それらはホストマシンの機能を調査するため,クロ スコンパイルでは意味が無いことを知っておいてください.
AC_CHECK_FILE
を一度実行します.さらに,見つかったそれぞれのファ
イルに対して`HAVEfile'を定義します(see section 標準的なシンボル).
以下のマクロは,C,C++やFortran 77のライブラリアーカイブファイルの存在 を調査します.
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
に無い,その他のライブラリ
の一つを調査することが望ましい場合は制限があります.
functionが含まれている最初のライブラリに対して,
@option{-llibrary}をLIBS
に追加し,action-if-foundを
実行します.関数が見つからない場合,action-if-not-foundを実行し
ます.
libraryとのリンクの結果が,未解決のシンボルで,追加のライブラリ とのリンクで解決できる場合,これらのライブラリを,`-lXt -lX11'の 様に,スペースで区切られたother-libraries引数で与えてください. そうしなければ,テストプログラムとのリンクが,常に未解決のシンボルで失 敗するので,このマクロはlibraryの存在の調査に失敗します.
以下のマクロは,特定のCライブラリ関数を調査します.必要な関数を調査す るための特別に定義されたマクロがなく,その特別な特性を調査する必要がな い場合,一般的な関数調査のマクロを使用することが可能です.
ほとんどの通常の関数は,無くなっている,またはバグがある,またはアーキ テクチャによって制限があるはずです.このセクションでは,これらの移植性 の問題を目録にしようと思います.定義からすると,このリストは常に追加が 必要です.できるだけ完全なものを保つために,我々への手助けをお願いしま す.
exit
exit
がint
を返すものがあることを御存知で
すか?これは,exit
のほうがvoid
より時代が古く,int
を返すという伝統が長い間あったためです.
snprintf
snprintf
とvsnprintf
は出力を切捨て,生成された出力が必要
とするバイト数を返すことになっています.古いシステムでは切り捨てられた
長さを返したり(例えば,@acronym{GNU} Cライブラリ2.0.xやIRIX 6.5),
負の値を返したり(例えば,より古いバージョンの@acronym{GNU} Cライブラリ),
切り捨てられなかったバッファの長さを返したり(例えば32ビットのSolaris
7)します.また,バグの多い古いシステムにはバッファの長さとオーバーラン
を無視するもの(例えば64ビットのSoraris 7)もあります.
sprintf
sprintf
とvsprintf
は書き込まれたバイト数
を返すことになっていますが,古いシステム(例えばSunOS 4)ではその代わり
にバッファへのポインタを返すものもあります.
sscanf
sscanf
は入力文字列が(た
とえそれが実際には変更されなくても)書き込み可能であることを要求します.
これは,@command{gcc}は通常,固定文字列を読み込み専用のメモリに書き込
むので(see section `Incompatibilities' in Using and Porting the @acronym{GNU Compiler Collection}),それを使用すると
き問題になるはずです.場合によっては,フォーマット文字列が明らかに読み
込み専用であっても問題になるはずです.
strnlen
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
unlink
は開かれているファイルへのハン
ドルがなくなった後でファイルを削除するように述べられています.全てのOS
がこの動作をサポートしているわけではありません.そのため,システムが
unlink
を提供している場合でも,開いているファイルに対して呼び出
しても大丈夫だと仮定した移植は不可能です.例えば,Windows 9xとMEでは,
そのような呼び出しは失敗します.@acronym{DOS}は可能ですが,OSが削除し
た後にファイルへの書き込みが終了するので,ファイルシステムが駄目になり
ます.
va_copy
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
)ことを意味し
ます.
>>
>>
はハイビットを複製し,いわゆる"算
術"シフトになります.しかし,ISO Cの標準ではその動作を要求していない
ので,注意すべきです.ネイティブの算術シフトが無いプロセッサ(例えば
Crayベクターシステム)では,符号無しのシフトと同様に,ゼロビットがシフ
トインされる可能性があります.
これらのマクロは -- その存在にかかわらず -- 特定のC関数を調査し,場 合によっては,特定の引数が与えられたときの反応を調査します.
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
chown
関数が利用可能で動作する場合(特に,uid
とgid
に対する@option{-1}を受け入れるべきです),HAVE_CHOWN
を定義しま
す.
closedir
関数が意味のある値を返さない場合,CLOSEDIR_VOID
を定義します.それ以外では,呼び出し側で,エラーを示す戻り値を調査する
必要があります.
error_at_line
関数が見つからない場合,AC_LIBOBJ
が
`error'で置換されることを要求します.
fnmatch
関数が@acronym{POSIX}準拠の場合,HAVE_FNMATCH
を定
義します.例えば,Solaris 2.4のバグのような,一般的な実装上のバグを検
出します.
歴史的な理由のため,それ以外のAC_FUNC
マクロとは反対に,
AC_FUNC_FNMATCH
は壊れていたり見つからなかったりする
fnmatch
を置換しません.以下のAC_REPLACE_FNMATCH
を参照し
てください.
AC_REPLACE_FNMATCH
(置換)のように動作しますが,
fnmatch
が@acronym{GNU}の拡張をサポートするかどうかも調査します.
例えば,@acronym{GNU} Cライブラリ2.1のバグのような,一般的な実装上のバ
グを検出します.
fork
とvfork
関数を調査します.動作する
fork
が見つかった場合,HAVE_WORKING_FORK
を定義します.こ
のマクロは,fork
がスタブかどうかを実行してみることで調査します.
`vfork.h'が見つかった場合,HAVE_VFORK_H
を定義します.動作
するvfork
が見つかった場合,HAVE_WORKING_VFORK
を定義しま
す.それ以外の場合,以前のバージョンの@command{autoconf}に対する下位互
換のため,vfork
をfork
と定義します.このマクロは,
vfork
の実装のいくつかの既知のエラーを調査し,そのエラーのいずれ
かを検出した場合,システムには動作するvfork
が無いと考えます.子
プロセスは,シグナルハンドラを変えることがめったにないので,子プロセス
のsignal
の呼び出しが,親プロセスのシグナルハンドラを変更する場
合,実装エラーだとは考えられません.
このマクロは,以前のバージョンの@command{autoconf}への下位互換性のため
だけにvfork
を定義するので,コード内で独自に定義することを推奨し
ます.
#if !HAVE_WORKING_VFORK # define vfork fork #endif
fseeko
関数が利用可能な場合,HAVE_FSEEKO
を定義します.必
要があれば_LARGEFILE_SOURCE
を定義します.
getgroups
関数が利用可能で,(`getgroups (0, 0)'が常に失敗す
るUltrix 4.3と異なり)動作する場合,HAVE_GETGROUPS
を定義します.
GETGROUPS_LIBS
をその関数の使用に必要な全てのライブラリに定義し
ます.このマクロは,AC_TYPE_GETGROUPS
を実行します.
AC_LIBOBJ
で確実に設定してください
(section 一般の関数の調査と,AC_CONFIG_LIBOBJ_DIR
を参照してくだ
さい).
システムにgetloadavg
関数がある場合,HAVE_GETLOADAVG
を定
義し,その関数の使用に必要な全てのライブラリをGETLOADAVG_LIBS
に
設定します.また,GETLOADAVG_LIBS
をLIBS
に加えます.それ
以外の場合,AC_LIBOBJ
で`getloadavg'を
`dir/getloadavg.c' のソースコードで置換することを要求し,お
そらく以下のようないくつかのCプリプロセッサのマクロと出力変数を定義し
ます.
C_GETLOADAVG
を定義します.
SVR4
,DGUX
,UMAX
,または
UMAX4_3
の場合,それを定義します.
HAVE_NLIST_H
を定義します.
HAVE_STRUCT_NLIST_N_UN_N_NAME
を定義します.時代遅れのシンボル
NLIST_NAME_UNION
も定義しますが,それに依存しないようにしてくだ
さい.
getloadavg
が動作するために,setgid(または
setuid)がインストールされていることを必要とするかもしれません.この場
合,GETLOADAVG_PRIVILEGED
を定義し,出力変数NEED_SETGID
を
`true'に(それ以外では`false'に)設定し,そして
KMEM_GROUP
をインストールされているプログラムを所有するグループ
の名前に設定します.
getmntent
をそれぞれ調査します.
getmntent
が利用可能な場合,HAVE_GETMNTENT
を定義します.
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
を呼び出してください.
lstat
は`link/'を
`link/.'と同じものとして扱います.しかし,多くの古いlstat
の実装では,後置されているスラッシュを間違って無視します.
lstat
が後置されているスラッシュを間違って無視する場合,それ以外
のunlink
のようなsymbolic-link-aware関数も後置されているスラッシュ
を間違って無視すると仮定した方が確実です.
lstat
が正しく動作する場合,LSTAT_FOLLOWS_SLASHED_SYMLINK
を定義し,それ以外の場合は,AC_LIBOBJ
をlstat
で置換するよ
う要求します.
malloc
関数が@acronym{GNU} Cライブラリのmalloc
と互換性が
ある場合,(すなわち`malloc (0)'が有効なポインタを返す)場合,
HAVE_MALLOC
を1に定義します.それ以外では,HAVE_MALLOC
を0
に定義し,AC_LIBOBJ
で`malloc'を置換し,ネイティブの
malloc
が中心的なプロジェクトで使用されないようにmalloc
を
rpl_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); }
memcmp
関数が利用不可能,または(SunOS 4.1.3のように)8ビットデー
タで動作しない,または(NeXT x86 OpenStepのように)16バイトかそれ以上で
少なくとも一つのバッファが4バイト境界で始まらないものの比較時に失敗す
る場合,AC_LIBOBJ
で`memcmp'を置換することを要求します.
mbrtowc
と型mbstate_t
が正しく宣言されている場合,
HAVE_MBRTOWC
を1に設定します.
mktime
関数が利用不可能,または正しく動作しない場合,
AC_LIBOBJ
で`mktime'を置換することを要求します.
mmap
関数が存在して正しく動作する場合,HAVE_MMAP
を定義し
ます.すでにマップされたメモリの,プライベートな固定したマッピングのみ
調査します.
HAVE_OBSTACK
を定義し,そうでない場合は
AC_LIBOBJ
で`obstack'を置換することを要求します.
realloc
関数が@acronym{GNU} Cライブラリのrealloc
と互換性
がある場合,(すなわち`realloc (0, 0)'が有効なポインタを返す)場合,
HAVE_REALLOC
を1に定義します.それ以外では,HAVE_REALLOC
を0に定義し,AC_LIBOBJ
で`realloc'を置換し,ネイティブの
realloc
が中心的なプロジェクトで使用されないようにrealloc
をrpl_realloc
で定義するかどうかを尋ねます.詳細は
AC_FUNC_MALLOC
を参照してください.
select
関数の引数それぞれに渡される正しい型を決定し,それらの型
をSELECT_TYPE_ARG1
,SELECT_TYPE_ARG234
,そして
SELECT_TYPE_ARG5
にそれぞれ定義します.SELECT_TYPE_ARG1
の
デフォルトは`int'で,SELECT_TYPE_ARG234
のデフォルトは
`int *'で,そしてSELECT_TYPE_ARG5
のデフォルトは
`struct timeval *' です.
setpgrp
が引数を持たない(@acronym{POSIX}バージョンの)場合,
SETPGRP_VOID
を定義します.それ以外では,@acronym{BSD}バージョン
で,二つのプロセスIDを引数とします.このマクロはsetpgrp
の存在を
全く調査しません.その状況で動作する必要がある場合,setpgrp
に対
して最初にAC_CHECK_FUNC
を呼び出してください.
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
でそれを
置換することを要求します.
setvbuf
が他とは異なり,第二引数でバッファの型,第三引数でバッファ
ポインタをとる場合,SETVBUF_REVERSED
を定義します.
strcoll
関数が存在して,正しく動作する場合,HAVE_STRCOLL
を定義します.使用すべきではないstrcoll
の間違った定義を持つシス
テムもあるので,`AC_CHECK_FUNCS(strcoll)'より多少ましです.
strtod
関数が存在していない,または正しく動作しない場合,
AC_LIBOBJ
で`strtod'を置換するよう要求します.この場合,
`strtod.c'は`pow'を必要とすることもあり得るので,出力変数
POW_LIB
を必要な外部ライブラリに設定します.
strerror_r
が利用可能な場合はHAVE_STRERROR_R
を定義し,そ
れが宣言されている場合,HAVE_DECL_STRERROR_R
を定義します.それ
がchar *
のメッセージを返す場合,STRERROR_R_CHAR_P
を定義
します.それ以外ではint
のエラーナンバーを返します.
@acronym{POSIX}ではstrerror_r
がint
を返すように要求してい
ますが,多くのシステムのスレッドセーフな関数のオプション(例えば
@acronym{GNU} Cライブラリのバージョン2.2.4を含む)は,バッファ引数に等
しい必要が無いchar *
の値を返します.
strftime
を調査
します.strftime
が利用可能な場合,HAVE_STRFTIME
を定義し
ます.
strnlen
が利用不可能な場合や(@acronym{AIX} 4.3のように)バグが多
い場合,AC_LIBOBJ
で置換することを要求します.
HAVE_UTIME_NULL
を定義します.
vprintf
が見つかった場合,HAVE_VPRINTF
を定義します.それ
以外で,_doprnt
が見つかった場合,HAVE_DOPRNT
を定義します.
(vprintf
が利用可能な場合,vfprintf
とvsprintf
も利
用可能だと仮定できるでしょう.)
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 テストを書く).
AC_CHECK_FUNCS
を使用してください.このマクロは, CのほうがC++よ
り標準化されているので,AC_LANG_CPLUSPLUS
が呼び出された場合でも,
C にリンクされる関数を調査します.(言語の選択の調査ついての詳細は,
see section 言語の選択.)
HAVE_function
を(全て大文字で)定義し
ます.action-if-foundが与えられている場合,関数の一つが見つかっ
たとき実行する,追加のシェルコードになります.最初に一致したループでブ
レイクするためには,`break'を与えることで可能になります.
action-if-not-foundが与えられている場合,それは関数が一つでも見
つからないときに実行されます.
Autoconfは,移植性について苦心してきた人々によって,何年もかけて形作ら れてきた哲学に従います.特定のファイルの移植性の問題と, @acronym{POSIX}環境にいるかのような問題とは別物です.関数によっては, 無いものがあったり修正不可能だったりするものもあり,パッケージではそれ らを置き換える準備が必要になります.
技術的には,それは`function.$ac_objext'を出力変数
LIBOBJS
に追加し,`function.c'に対し
AC_LIBSOURCE
を呼び出します.LIBOBJS
は追跡不可能なので,
直接LIBOBJS
を変更すべきではありません.
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
を引数としてとります.
AC_LIBSOURCE
に似ていますが,カンマで分けられているM4リストに,
一つ以上のfilesを受け入れます.このため,上記の例は以下のように
書き換えられるでしょう.
AC_LIBSOURCES([foo.c, bar.c]) AC_LIBOBJ($foo_or_bar)
AC_LIBOBJ
で置換するファイルがdirectoryで見つかるように,
ソースツリーのトップレベルから始まる相対パスを指定します.置換ディレク
トリのデフォルトはトップレベルディレクトリの`.'で,最も一般的な値
は`lib'で,`AC_CONFIG_LIBOBJ_DIR(lib)'で対応します.
@command{configure}は以下の理由で,置換ディレクトリを知る必要がないか もしれません.(i)置換ファイルを使用する調査もあります.(ii)置換ヘッダ のリンクを導入することで,壊れたシステムヘッダをバイパスするマクロもあ ります.等々.
AC_LIBOBJ
が無い場合,単に関数の存在を調査し,置換するかどうか尋
ねるだけのことは一般的です.以下のマクロは,便利で手短なものです.
AC_CHECK_FUNCS
に似ていますが,action-if-not-found として
`AC_LIBOBJ(function)'を使用します.`#if
!HAVE_function'にプロトタイプを含めることで,置換する関数を宣言
することが可能です.システムに関数が存在する場合,おそらくインクルード
しているヘッダファイルで宣言されているので,宣言が衝突しないように,そ
れを再定義すべきではありません.
以下のマクロは,ある特定のCヘッダファイルの存在を調査します.必要とし ているヘッダファイルを調査するために特に定義されたマクロがなく,その特 別な特性を調査する必要がない場合,一般的なヘッダファイルチェックマクロ の一つを使用することが可能です.
このセクションでは,一般的なヘッダとそれらの問題に関する知識を正しくし てみたいと思います.定義上,以下のリストは常なる追加を必要とします.可 能な限り完全に保つ手助けをお願いします.
これらのマクロは,特定のシステムヘッダファイルを調査します -- それら が存在しているか,そして場合によっては,特定のシンボルを宣言しているか を調査します.
HAVE_DIRENT_H
HAVE_SYS_NDIR_H
HAVE_SYS_DIR_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'ライブラリも調査します.
major
,minor
,そしてmakedev
を
定義していないが,`sys/mkdev.h'が定義している場合,
MAJOR_IN_MKDEV
を定義します.それ以外の場合で,
`sys/sysmacros.h'が定義している場合は,MAJOR_IN_SYSMACROS
を定義します.
S_ISDIR
,S_ISREG
等のマ
クロが正確に動作しない(間違った正の値を返す)場合,
STAT_MACROS_BROKEN
を定義します.Tektronix UTekV,Amdahl UTS,
そしてMotorola System V/88の場合がそうです.
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
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}とは異なる
memchr
,memset
,strtok
,ま
たは strspn
の様な関数を使用する場合,マクロは不十分でしょう.そ
れぞれの関数を実装する必要があります.(システムのCライブラリのものが,
手動で最適化されているかもしれないので)必要なときだけ実装を組み込む簡
単な方法として,例えばmemchr
を使用する場合は,それを
`memchr.c'に書き込み,`AC_REPLACE_FUNCS(memchr)'を使用するこ
とです.
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
_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
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
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 テストを書く).
AC_CHECK_HEADERS
を使用を考えてみてくださ
い.
古いバージョンのAutoconfとの互換性の問題は,以下を読んでください.
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 コンパイラの実行).
宣言を調査する特別なマクロはありません.
これらのマクロは,"特定の"テストマクロでカバーされていない宣言を調査 するために使用します.
このマクロは,必要でないときに余分な宣言を導入することを避けた方が安全 なので,symbolがr-valueとして有効かどうかを実際にテストし,実際 に宣言されているかどうかはテストしません.
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 コンパイラの実行).
以下のマクロは,特定の構造体と構造体のメンバーを調査します.
struct stat
がst_blksize
メンバーを含んでいる場合,
HAVE_STRUCT_STAT_ST_BLKSIZE
を定義します.これまでの名前
HAVE_ST_BLKSIZE
は,将来サポートを中止するので避けてください.こ
のマクロは時代遅れで,以下のもので置換すべきです.
AC_CHECK_MEMBERS([struct stat.st_blksize])
struct stat
がst_blocks
メンバーを含んでいる場合,
HAVE_STRUCT STAT_ST_BLOCKS
を定義します.それ以外では,出力変数
AC_LIBOBJS
で`fileblocks'の置換を要求します.これまでの名前
HAVE_ST_BLOCKS
は,将来サポートを中止するので避けてください.
struct stat
がst_rdev
メンバーを含んでいる場合,
HAVE_STRUCT_STAT_ST_RDEV
を定義します.これまでの名前
HAVE_ST_RDEV
は,将来サポートを中止するので避けてください.実際
には新しいマクロでさえ時代遅れで,以下のもので置換すべきです.
AC_CHECK_MEMBERS([struct stat.st_rdev])
struct tm
を定義しない場合,TM_IN_SYS_TIME
を定義し,それは,`sys/time.h'をインクルードすることで
struct tm
を定義した方が良いことを意味します.
struct tm
に
tm_zone
メンバーが存在する場合,HAVE_STRUCT_TM_TM_ZONE
(と時代遅れのHAVE_TM_ZONE
)を定義します.それ以外では,外部配列
のtzname
が見つかる場合,HAVE_TZNAME
を定義します.
これらのマクロは,"特定の"テストマクロでカバーされていない構造体のメ ンバーを検索するために使用します.
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)
HAVE_aggregate_member
を(全て大文字で,スペースとドッ
トをアンダースコアで置換しながら)定義します.
このマクロはM4のリストを使用します.
AC_CHECK_MEMBERS([struct stat.st_rdev, struct stat.st_blksize])
以下のマクロは,組み込みまたはtypedefになっている,Cの型を調査します. 必要な型を調査するための特別に定義されたマクロがなく,その特別な特性を 調査する必要がない場合,一般的な型調査マクロを使用することが可能です.
これらのマクロは,`sys/types.h',`stdlib.h',そして存在する 場合はその他の,特定のCの型を調査します.
<wchar.h>
でmbstate_t
型が宣言されている場合,
HAVE_MBSTATE_T
を定義します.また,<wchar.h>
で宣言されて
いない場合,型としてmbstate_t
を定義します.
signal
をvoid
返す関数へのポインタを返
すものと宣言されている場合,RETSIGTYPE
をvoid
と定義します.
それ以外ではint
と定義します.
シグナルハンドラが返す型をRETSIGTYPE
と定義してください.
RETSIGTYPE hup_handler () { ... }
これらのマクロは,"特定の"テストマクロがカバーしない型を調査するため に使用されます.
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_CC
,AC_PROG_CXX
,AC_PROG_F77
)
に対する全てのテストは,コンパイラの出力のベースとなる出力変数
EXEEXT
を定義し,通常,Unixでは空の文字列でWin32やOS/2では
`.exe'に定義されます.
それらは,`.c'ファイルが除外された後で,コンパイラ出力のベースと
なる出力変数OBJEXT
も定義し,通常,Unixでは`o'でWin32では
`obj'に定義されますます.
使用しているコンパイラが実行形式を生成しない場合,テストは失敗します. 実行形式が実行不可能な場合で,クロスコンパイルが利用できない場合も失敗 します.クロスコンパイルのサポートの詳細は,See section 手動のコンフィグレーション.
コンパイラによっては異なる動作を示すものもあります.
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
にキャストする
ことで,この問題を解決します.
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コンパイラを探し使用する方法を提供します.避けたほう が良い構成物もいくつかありますが,それらは容易に回避可能なので,調査に 使用しているなら無くしてしまうこともないでしょう.
#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.単一のバックスラッシュを用いた行を削除することで,問題を解決できます.
$ 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'で 呼び出すことで問題を解決します.
CC
が環境変数で設定されていない
場合,gcc
とcc
を調査し,その後で他の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}に設定します.
NO_MINUS_C_MINUS_O
を定義します.このマクロは,AC_PROG_CC
で見つかったコンパイラと,パスの最初のcc
がそれと異なっている場
合はその両方を,実際にテストします.一つでも失敗した場合,テストは失敗
します.このマクロは,@acronym{GNU} Makeがデフォルトのコンパイルルール
を選択するように作成されました.
CPP
を,Cプリプロセッサを実行するコマンドに設定ます.
`$CC -E'が動作しない場合,`/lib/cpp'を使用します.拡張子が
`.c'のファイルでCPP
を実行することは移植性のためだけです.
プロセッサによっては,足りないインクルードファイルをエラーステータスで 示さないものもあります.そのようなプロセッサに対する内部変数は,プリプ ロセッサからの標準エラーを調査するための他のマクロを設定し,警告が報告 された場合はテストに失敗したと判断します.
以下のマクロは,Cコンパイラやマシンアーキテクチャの特徴を調査します.
ここでリストアップされない特徴を調査するために,
AC_COMPILE_IFELSE
(see section コンパイラの実行)や
AC_RUN_IFELSE
(see section 実行時の動作の調査)を使用してください.
システムヘッダファイルからエンディアンを決定不可能な場合,このマクロは テストケースを実行します.クロスコンパイル時に,テストケースは実行され ませんが,いくつかのマジック変数を検索します.後者の状況でホストシステ ムのバイト特性の決定に失敗した場合,action-if-unknownが実行され ます.
action-if-trueのデフォルトは`WORDS_BIGENDIAN'を定義すること です.action-if-falseのデフォルトは何もしないことです.そして最 後に,action-if-unknownのデフォルトは,コンフィグレーションを中 断し,インストールしている人に,このテストをバイパスさせるために変数を 前もって定義するよう伝えます.
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コンパイラを入手すべ
きです.
volatile
を理解しない場合,
volatile
を空で定義します.プログラムではvolatile
をサポー
トしているコンパイラのように単純に使用することが可能です.サポートしな
いものに対しては,`Makefile'やコンフィグレーションヘッダで,それ
を空として定義されます.
プログラムの正当性がvolatile
の意味に依存している場合,単純に空
で定義するとある意味ではコードが壊れます.しかし,volatile
をサ
ポートしていないコンパイラでは,自分で何とかしてください.少なくともプ
ログラムはコンパイルされますが,多分駄目でしょう.
一般的に,volatile
キーワードは@acronym{ANSI} Cの機能なので,
__STDC__
が定義されているときだけ,volatile
が利用可能だと
期待するかもしれません.しかし,Ultrix 4.3のネイティブコンパイラは
volatile
をサポートとしていますが,__STDC__
を定義しません.
inline
をサポートする場合,何もしません.
それ以外では,受け入れられるものによって,inline
を
__inline__
や__inline
に定義し,それ以外ではinline
を空で定義します.
HAVE_STRINGIZE
を定義します.文字列作成オペレータは`#'と,
以下のようなマクロで見つかります.
#define x(y) #y
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
も定義します.これは,ユーザの名前空
間を侵害するマクロが使用不可能なヘッダファイルの利便性ためです.
ioctl
が,
`-traditional'無しでは正確に動作しない場合,出力変数CC
に
`-traditional'を加えます.それは通常,修正されたヘッダファイルが
古いシステムにインストールされていないときに発生します.@acronym{GNU}
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)
@acronym{GNU} C++コンパイラを使用している場合,シェル変数GXX
を
`yes'に設定します.出力変数CXXFLAGS
がまだ設定されていない
場合,@acronym{GNU} C++コンパイラに対しては@option{-g -O2}(`-g'を
受け入れないG++のシステムでは`-O2')を設定し,他のコンパイラでは
`-g'を設定します.
CXXCPP
を,C++プリプロセッサを実行するコマンドに設定しま
す.`$CXX -E'が動作しない場合,`/lib/cpp'を使用します.
`.c',`.C',または`.cc'の拡張子を持つファイルで
CXXCPP
を実行するのは移植性のためだけです.
プリプロセッサによっては,足りないインクルードファイルをエラーステータ スで示さないものもあります.そのようなプリプロセッサに対して,内部変数 は,プリプロセッサからの標準エラー出力を調査する他のマクロに設定され, 警告が報告されない場合はテストに失敗したと考えます.しかし,C++に対し てそのような壊れ方をしているプリプロセッサがあるかどうかは知りません.
F77
が環境変数でまだ設
定されていない場合,g77
,f77
,そしてその他の名前を調査し
ます.見つかったコンパイラ名を,出力変数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'を設定します.
F77_NO_MINUS_C_MINUS_O
を
定義します.
以下のマクロは,Fortran 77コンパイラの特徴を調査します.ここでリストアッ
プされていない特徴を調査するために,現在の言語がFortran
77AC_LANG_FORTRAN77
(see section 言語の選択)に設定されているこ
とを最初に確認し,AC_COMPILE_IFELSE
(see section コンパイラの実行)やAC_RUN_IFELSE
(see section 実行時の動作の調査)を使用してください.
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_MAIN
やAC_F77_MAIN
は,Fortranで
C/C++ にリンクする必要があるときもおそらく必要です.以下を参照してくだ
さい.
AC_F77_LIBRARY_LDFLAGS
で見つかるFortranラ
イブラリは,Fortran I/Oのようなものを初期化したり,ユーザプログラムを
実行するために,(いわゆる)MAIN__
のような名前を持つユーザ提供の
エントリー関数を呼び出す,独自のmain
エントリー関数を提供してい
ます.AC_F77_DUMMY_MAIN
やAC_F77_MAIN
マクロは,この相互作
用を扱う方法を理解します.
(I/Oなどではない)純粋な数値関数に対してFortranを使用しているとき,独自
のmain
を提供し,Fortranライブラリの初期化を停止したいこともよく
あります.しかしこの場合は,いくつかのシステムでのリンクエラーを避ける
ため,ダミーのMAIN__
ルーチンを提供する必要があるかもしれません.
シェル変数F77_DUMMY_MAIN
は,解決方法が見つからないときは
unknown
,そのようなダミーのmain
が不要なときはnone
という値を保持します.
デフォルトで,必要な場合は,action-if-foundは
F77_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_MAIN
はAC_F77_WRAPPERS
から自動的に呼び出され
ることに注意してください.一般的にデフォルトの動作を変更したくない限り,
明示的にに呼び出す必要はありません.
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
の名前にすべきです.
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するものもあるからです.
AC_F77_WRAPPERS
も参照してください)によっ
て,mangleされるバージョンのnameを保持するように設定します.
shellvarはオプションです.提供されていない場合シェル変数は単純に
nameになります.このマクロの目的は,上記のようにCプリプロセッサ
を通じてではなく,呼び出し側に名前のmangleに関する情報にアクセスする方
法を与えることで,例えば,C/C++以外の言語からFortranルーチンを呼び出す
ためです.
以下のマクロはオペレーティングシステムのサービスや機能を調査します.
xmkmf
を平凡
な`Imakefile'で実行し,生成された`Makefile'を調査し,足りな
い値を取得します.(xmkmf
が存在しない等のように)失敗した場合,配
置されることが多いディレクトリ等でファイルを検索します.いずれかの手法
で成功した場合,コンパイラがデフォルトで検索するディレクトリに無い限り,
シェル変数x_includes
とx_libraries
をその場所に設定します.
両方の方法が失敗する,またはユーザがコマンドラインオプションの
`--without-x'を与えている場合,シェル変数のno_x
を
`yes' に設定し,それ以外では空の文字列に設定します.
AC_PATH_X
の拡張バージョンです.Xが必要とするCコンパイラフラグを
出力変数X_CFLAGS
に,XリンカフラグをX_LIBS
に追加します.X
が利用可能でない場合,X_DISPLAY_MISSING
を定義します.
また,このマクロは,Xプログラムをコンパイルするためにシステムが必要と
する特別なライブラリも調査します.それは,システムが必要とするあらゆる
ものを出力変数X_EXTRA_LIBS
に追加します.そして,`-lX11'の
前にリンクする必要がある特別なX11R6ライブラリを調査し,見つかったもの
は全て出力変数X_PRE_LIBS
に追加します.
interpval
を調査することが可能になります.システムで
`#!'がサポートされている場合は`yes',そうでなければ`no'
を設定します.
CC
に,全て追
加します.必要な場合は,_FILE_OFFSET_BITS
と_LARGE_FILES
を定義します.
大きなファイルのサポートは,@option{--disable-largefile}オプションを用 いてコンフィグレーションすることで利用不可能にすることが可能です.
このマクロを使用する場合,大きなファイルのサポートが利用可能なときは,
off_t
がlong
より長いときが一般的なので,それでもプログラ
ムが動作するかどうかを調査してください.例えば,printf ("%ld",
(long) X)
で任意のoff_t
の値X
を出力しても正しくなくなりま
す.
ac_cv_sys_posix_termios
を
`yes'に設定します.それ以外ではその変数を`no'に設定します.
以下のマクロは,ヘッダファイルやライブラリが例外的に特異なため,プログ ラムに対して特別な処理が必要なオペレーティングシステムを調査します.こ れらのマクロは不要なものです.利用可能にする関数や,供給する環境に基づ き,より規則正しい手法で置換されるでしょう.
_ALL_SOURCE
を定義します.いくつかの
@acronym{BSD}関数の使用を許可します.Cコンパイラを実行するあらゆるマク
ロの前に呼び出すべきです.
_GNU_SOURCE
を定義
します.いくつかの@acronym{GNU}の関数が使用可能になります.Cコンパイラ
を実行するマクロの前で呼び出すべきです.
LIBS
に@option{-lcposix}を追加します.これは
AC_PROG_CC
の後で,@acronym{POSIX}インターフェースを使用するその
他のマクロの前で呼び出してください.INTERACTIVE UNIXはすでに販売
されておらず,Sunは2006-07-23でサポートを終了することを告げているので,
このマクロは時代遅れになっています.
_MINIX
と_POSIX_SOURCE
を定義し,
_POSIX_1_SOURCE
を2と定義します.これで@acronym{POSIX}の機能が使
用可能になります.Cコンパイラを実行するあらゆるマクロの前で呼び出すべ
きです.
Go to the first, previous, next, last section, table of contents.