[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
以下のマクロは,パッケージが必要とする,あるいは使用する,特定のシステム の特徴をテストします.これらのマクロが調査しない特徴のテストが必要な場合, 適切な引数で基本のテストマクロを呼び出すことで,おそらく可能です (see section テストを書く).
これらのテストは,調査している特徴と見つかったものをユーザに伝えるメッセー
ジを出力します.将来,configure
を実行するため,結果をキャッシュ
します(see section 結果のキャッシュ).
これらのマクロには,出力変数を設定するものもあります.変数の取得方法は, See section Makefileへの代入. "nameを定義します"という文章は, "Cプリプロセッサのシンボルnameの値を1に定義します" という意味を 短縮したのもとして,以下で使用します.プログラムでシンボル定義を得る方法 は, See section Cプリプロセッサシンボルの定義.
5.1 共通の動作 | Macros' standard schemes | |
5.2 プログラムの選択 | Selecting between alternative programs | |
5.3 ファイル | Checking for the existence of files | |
5.4 ライブラリファイル | Library archives that might be missing | |
5.5 ライブラリ関数 | C library functions that might be missing | |
5.6 ヘッダファイル | Header files that might be missing | |
5.7 宣言 | Declarations that may be missing | |
5.8 構造体 | Structures or members that might be missing | |
5.9 型 | Types that might be missing | |
5.10 コンパイラとプリプロセッサ | Checking for compiling programs | |
5.11 システムサービス | Operating system services | |
5.12 様々なUNIX | Special kludges for specific UNIX variants |
Autoconfの学習が簡単になるように努力してきました.このゴールに到達するた めの最も明白な方法は,できるだけ例外を避けながら,単純に標準的なインタ フェースと動作を実施することです.残念ながら,歴史と慣性のため,多くの例 外がAutoconfにはまだ存在しています.それにもかかわらず,このセクションで は,一般的な規則を記述します.
5.1.1 標準的なシンボル | Symbols defined by the macros | |
5.1.2 デフォルトのインクルード | Includes used by the generic macros |
テストの結果,シンボルを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-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.1 特定のプログラムの調査 | Special handling to find certain programs | |
5.2.2 一般的なプログラムとファイルの調査 | How to find other programs |
以下のマクロは,特定のプログラムを調査します -- それは存在するかどうか, そして場合によっては特定の機能をサポートするかどうかです.
gawk
,mawk
,nawk
,そしてawk
を,この順番で調
査し,最初に見つかったものに出力変数AWK
を設定します.最良の実装と
報告されているので,最初にgawk
を調査します.
grep -E
とegrep
をこの順番で調査し,最初に見つかったもので出
力変数EGREP
を設定します.
grep -F
とfgrep
をこの順番で調査し,最初に見つかったもので出
力変数FGREP
を設定します.
現在の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'ファイルにプログラムのファイ
ル名を書き込んでください.
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ではこの症状は
修正されるでしょう.それまで,このメッセージを無視してください.
現在のファイルシステムで,`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) |
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
を呼び出してください.
空白で区切られたリストprogs-to-check-forのそれぞれのプログラムが
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マクロのように,それらはホストマシンの機能を調査するため,クロス コンパイルでは意味が無いことを知っておいてください.
ネイティブシステムにfileが存在するかどうか調査します.見つかった場 合,action-if-foundを実行し,それ以外では,与えられていれば action-if-not-foundを実行します.
filesでリストアップされているそれぞれのファイルに対し,
AC_CHECK_FILE
を一度実行します.さらに,見つかったそれぞれのファイ
ルに対して`HAVEfile'を定義します(see section 標準的なシンボル).
以下のマクロは,C,C++やFortranのライブラリアーカイブファイルの存在を調 査します.
現在の言語に依存して(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
に無い,その他のライブラリの
一つを調査することが望ましい場合は制限があります.
まだ利用可能ではない,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の存在の調査に失敗します.
以下のマクロは,特定のCライブラリ関数を調査します.必要な関数を調査する ための特別に定義されたマクロがなく,その特別な特性を調査する必要がない場 合,一般的な関数調査のマクロを使用することが可能です.
5.5.1 C関数の移植性 | Pitfalls with usual functions | |
5.5.2 特定の関数の調査 | Special handling to find certain functions | |
5.5.3 一般の関数の調査 | How to find other functions |
ほとんどの通常の関数は,足りない,またはバグがある,またはアーキテクチャ によって制限があるはずです.このセクションでは,これらの移植性の問題を目 録にしようと思います.定義からすると,このリストは常に追加が必要です.で きるだけ完全なものを保つために,我々への手助けをお願いします.
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ベクター
システム)では,符号無しのシフトと同様に,ゼロビットがシフトインされる可
能性があります.
これらのマクロは -- その存在にかかわらず -- 特定の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
を使用するソースファイルでは,正確に宣言するために,以下の
ようなコードで始めるべきです.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 |
chown
関数が利用可能で動作する場合(特に,uid
とgid
に
対する`-1'を受け入れるべきです),HAVE_CHOWN
を定義します.
closedir
関数が意味のある値を返さない場合,CLOSEDIR_VOID
を
定義します.それ以外では,呼び出し側で,エラーを示す戻り値を調査する必要
があります.
error_at_line
関数が見つからない場合,AC_LIBOBJ
が
`error'で置換されることを要求します.
fnmatch
関数がPOSIX準拠の場合,HAVE_FNMATCH
を定義
します.例えば,Solaris 2.4のバグのような,一般的な実装上のバグを検出し
ます.
歴史的な理由のため,それ以外のAC_FUNC
マクロとは反対に,
AC_FUNC_FNMATCH
は壊れていたり見つからなかったりするfnmatch
を置換しません.以下のAC_REPLACE_FNMATCH
を参照してください.
AC_REPLACE_FNMATCH
(置換)のように動作しますが,
fnmatch
がGNUの拡張をサポートするかどうかも調査します.
例えば,GNU Cライブラリ2.1のバグのような,一般的な実装上のバ
グを検出します.
このマクロは,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 |
fseeko
関数が利用可能な場合,HAVE_FSEEKO
を定義します.必要
があれば,プロトタイプがいくつかのシステム上で(例えばglibc 2.2)見て分か
るように,_LARGEFILE_SOURCE
を定義します.それ以外では,
AC_SYS_LARGEFILE
を用いてコンパイルするとき,off_t
がデフォ
ルトで64bitになっていないラージファイルに問題があるシステム上で,リンク
の問題が発生する可能性があります.
getgroups
関数が利用可能で,(`getgroups (0, 0)'が常に失敗する
Ultrix 4.3と異なり)動作する場合,HAVE_GETGROUPS
を定義します.
GETGROUPS_LIBS
をその関数の使用に必要な全てのライブラリに定義しま
す.このマクロは,AC_TYPE_GETGROUPS
を実行します.
システムのロードアベレージを取得する方法を調査します.適切に調査を実行す
るため,このマクロはファイル`getloadavg.c'が必要です.このため,適
切な置換ディレクトリをAC_LIBOBJ
で確実に設定してください
(一般の関数の調査と,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
の場合,それを定義します.
`nlist.h'が見つかる場合,HAVE_NLIST_H
を定義します.
`struct nlist'が`n_un'メンバーを持つ場合,
HAVE_STRUCT_NLIST_N_UN_N_NAME
を定義します.時代遅れのシンボル
NLIST_NAME_UNION
も定義しますが,それに依存しないようにしてくださ
い.
プログラムによっては,getloadavg
が動作するために,setgid(または
setuid)がインストールされていることを必要とするかもしれません.この場合,
GETLOADAVG_PRIVILEGED
を定義し,出力変数NEED_SETGID
を
`true'に(それ以外では`false'に)設定し,そしてKMEM_GROUP
をインストールされているプログラムを所有するグループの名前に設定します.
IRIX 4,PTXと,Unixwareに対し,`sun',`seq',そして
`gen' のライブラリ内のgetmntent
をそれぞれ調査します.
getmntent
が利用可能な場合,HAVE_GETMNTENT
を定義します.
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
を呼び出してください.
`link'がシンボリックリンクの場合,lstat
は`link/'を
`link/.'と同じものとして扱います.しかし,多くの古いlstat
の
実装では,後置されているスラッシュを間違って無視します.
lstat
が後置されているスラッシュを間違って無視する場合,それ以外の
unlink
のようなsymbolic-link-aware関数も後置されているスラッシュを
間違って無視すると仮定した方が確実です.
lstat
が正しく動作する場合,LSTAT_FOLLOWS_SLASHED_SYMLINK
を定義し,それ以外の場合は,AC_LIBOBJ
をlstat
で置換するよう
要求します.
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); }
memcmp
関数が利用不可能,または(SunOS 4.1.3のように)8ビットデータ
で動作しない,または(NeXT x86 OpenStepのように)16バイトかそれ以上で少な
くとも一つのバッファが4バイト境界で始まらないものの比較時に失敗する場合,
AC_LIBOBJ
で`memcmp'を置換することを要求します.
関数mbrtowc
と型mbstate_t
が正しく宣言されている場合,
HAVE_MBRTOWC
を1に設定します.
mktime
関数が利用不可能,または正しく動作しない場合,
AC_LIBOBJ
で`mktime'を置換することを要求します.このテストの
目的に対して,mktime
はPOSIXに準拠すべきで,
localtime
の反対になっているべきです.
mmap
関数が存在して正しく動作する場合,HAVE_MMAP
を定義しま
す.すでにマップされたメモリの,プライベートな固定したマッピングのみ調査
します.
obstackが見つかった場合,HAVE_OBSTACK
を定義し,そうでない場合は
AC_LIBOBJ
で`obstack'を置換することを要求します.
realloc
関数が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
が引数を持たない(POSIXバージョンの)場合,
SETPGRP_VOID
を定義します.それ以外では,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
のエラーナンバーを返します.POSIXで
はstrerror_r
がint
を返すように要求していますが,多くのシス
テムのスレッドセーフな関数のオプション(例えばGNU Cライブラリの
バージョン2.2.4を含む)は,バッファ引数に等しい必要が無いchar *
の
値を返します.
`intl'ライブラリ内で,SCO UNIXに対するstrftime
を調査し
ます.strftime
が利用可能な場合,HAVE_STRFTIME
を定義します.
strnlen
が利用不可能な場合や(AIX 4.3のように)バグが多い
場合,AC_LIBOBJ
で置換することを要求します.
`utime(file, NULL)'がfileのタイムスタンプを現在のものに
設定する場合,HAVE_UTIME_NULL
を定義します.
vprintf
が見つかった場合,HAVE_VPRINTF
を定義します.それ以
外で,_doprnt
が見つかった場合,HAVE_DOPRNT
を定義します.
(vprintf
が利用可能な場合,vfprintf
とvsprintf
も利用
可能だと仮定できるでしょう.)
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'にリンクされます.
これらのマクロは,"特定の"テストマクロによってカバーていない関数を見つ
けるために使用されます.関数が,デフォルトのCライブラリ以外のライブラリ
にある場合,最初にそれらのライブラリに対してAC_CHECK_LIB
を呼び出
してください.存在の確認だけでなく動作も調査したい場合,独自のテストを書
く必要があります(see section テストを書く).
Cの関数functionが利用可能な場合,シェルコマンド
action-if-foundを,それ以外ではaction-if-not-foundを実行しま
す.関数が利用可能な場合にシンボルを定義したいだけならば,代わりに
AC_CHECK_FUNCS
を使用してください.このマクロは, CのほうがC++より
標準化されているので,AC_LANG_CPLUSPLUS
が呼び出された場合でも,C
にリンクされる関数を調査します.(言語の選択の調査ついての詳細は,
see section 言語の選択.)
空白で区切られた引数のリストで与えられているそれぞれのfunctionに対
し,利用可能な場合はHAVE_function
を(全て大文字で)定義します.
action-if-foundが与えられている場合,関数の一つが見つかったとき実
行する,追加のシェルコードになります.最初に一致したループでブレイクする
ためには,`break'を与えることで可能になります.
action-if-not-foundが与えられている場合,それは関数が一つでも見つ
からないときに実行されます.
Autoconfは,移植性について苦心してきた人々によって,何年もかけて形作られ てきた哲学に従います.特定のファイルの移植性の問題と,POSIX環 境にいるかのような問題とは別物です.関数によっては,無いものがあったり修 正不可能だったりするものもあり,パッケージではそれらを置き換える準備が必 要になります.
無かったり壊れたりしているfunctionの実装を置換するために,実行形式 に含める必要がある`function.c'を指定します.
技術的には,それは`function.$ac_objext'を,それがまだ無い場合
は出力変数LIBOBJS
に追加し,`function.c'に対し
AC_LIBSOURCE
を呼び出します.LIBOBJS
は追跡不可能なので,直
接LIBOBJS
を変更すべきではありません.
プロジェクトをコンパイルするために必要になる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
を引数としてとります.
AC_LIBSOURCE
に似ていますが,カンマで分けられているM4リストに,一
つ以上のfilesを受け入れます.このため,上記の例は以下のように書き
換えられるでしょう.
AC_LIBSOURCES([foo.c, bar.c]) AC_LIBOBJ($foo_or_bar) |
AC_LIBOBJ
で置換するファイルがdirectoryで見つかるように,ソー
スツリーのトップレベルから始まる相対パスを指定します.置換ディレクトリの
デフォルトはトップレベルディレクトリの`.'で,最も一般的な値は
`lib'で,`AC_CONFIG_LIBOBJ_DIR(lib)'で対応します.
configure
は以下の理由で,置換ディレクトリを知る必要がないかも
しれません.(i)置換ファイルを使用する調査もあります.(ii)置換ヘッダのリ
ンクを導入することで,壊れたシステムヘッダをバイパスするマクロもあります.
等々.
AC_LIBOBJ
が無い場合,単に関数の存在を調査し,置換するかどうか尋ね
るだけのことは一般的です.以下のマクロは,便利で手短なものです.
AC_CHECK_FUNCS
に似ていますが,action-if-not-found として
`AC_LIBOBJ(function)'を使用します.`#if
!HAVE_function'にプロトタイプを含めることで,置換する関数を宣言す
ることが可能です.システムに関数が存在する場合,おそらくインクルードして
いるヘッダファイルで宣言されているので,宣言が衝突しないように,それを再
定義すべきではありません.
以下のマクロは,ある特定のCヘッダファイルの存在を調査します.必要として いるヘッダファイルを調査するために特に定義されたマクロがなく,その特別な 特性を調査する必要がない場合,一般的なヘッダファイルチェックマクロの一つ を使用することが可能です.
5.6.1 ヘッダの移植性 | Collected knowledge on common headers | |
5.6.2 特定のヘッダの調査 | Special handling to find certain headers | |
5.6.3 一般的なヘッダの調査 | How to find other headers |
このセクションでは,一般的なヘッダとそれらの問題に関する知識を正しくして みたいと思います.定義上,以下のリストは常なる追加を必要とします.可能な 限り完全に保つ手助けをお願いします.
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/types.h'と`sys/socket.h'を要求します.
それは,`linux/types.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 ]) |
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 ]) |
上記の`inttypes.h'対`stdint.h'を参照して下さい.
多くのシステム上で(例えばDarwin),`stdio.h'が必須になります.
ia32のFreeBSD 4.8と,gccのバージョン2.95.4を使用しているシステムでは, `sys/params.h'が必須になります.
Darwin上では,`stdlib.h'が必須になります.
HP Tru64 5.1上では,`sys/types.h'が必須になります.
XFree86を使用している場合は,このヘッダは`X11/Xlib.h'を要求し,おそ らくそれを探すことを考えなくても良いでしょう.
AC_CHECK_HEADERS([X11/extensions/scrnsaver.h], [], [], [[#include <X11/Xlib.h> ]]) |
これらのマクロは,特定のシステムヘッダファイルを調査します -- それらが 存在しているか,そして場合によっては,特定のシンボルを宣言しているかを調 査します.
以下のヘッダファイルを調査します.最初に見つかった`DIR'を定義してい るものに対して,リストアップされているCプリプロセッサマクロを定義します.
`dirent.h' | |
`sys/ndir.h' | |
`sys/dir.h' | |
`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'ライブラリも調査します.
`sys/types.h'がmajor
,minor
,そしてmakedev
を定
義していないが,`sys/mkdev.h'が定義している場合,
MAJOR_IN_MKDEV
を定義します.それ以外の場合で,
`sys/sysmacros.h'が定義している場合は,MAJOR_IN_SYSMACROS
を
定義します.
`sys/stat.h'で定義されているS_ISDIR
,S_ISREG
等のマク
ロが正確に動作しない(間違った正の値を返す)場合,
STAT_MACROS_BROKEN
を定義します.Tektronix UTekV,Amdahl UTS,そ
してMotorola System V/88の場合がそうです.
`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
システムに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)'を使用することです.
`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 |
プログラムが,`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 |
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 テストを書く).
システムヘッダファイルheader-fileがコンパイル可能な場合,シェルコ
マンドaction-if-foundを,それ以外ではaction-if-not-found を
実行します.ヘッダファイルが利用可能な場合で,シンボルを定義したいだけの
場合は,代わりに,AC_CHECK_HEADERS
を使用を考えてみてください.
古いバージョンのAutoconfとの互換性の問題は,以下を読んでください.
空白で区切られた引数のリストで与えられているシステムヘッダファイル
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 ])
以下のマクロは,変数と関数の宣言を調査します.必要なシンボルを調査するた
めに特別なマクロが定義されていない場合,一般的なマクロ(see section 一般的な宣言の調査を使用することが可能で,より複雑なテストに対しては,
AC_COMPILE_IFELSE
を使用してもかまいません(see section コンパイラの実行).
5.7.1 特定の宣言の調査 | Macros to check for certain declarations | |
5.7.2 一般的な宣言の調査 | How to find other declarations |
宣言を調査する特別なマクロはありません.
これらのマクロは,"特定の"テストマクロでカバーされていない宣言を調査す るために使用します.
symbol(関数や変数)がincludesで定義されていなくて宣言が必要な 場合,シェルコマンドaction-if-not-foundを実行し,それ以外では action-if-foundを実行します.includesが宣言されていない場合, デフォルトのインクルードが使用されます(see section デフォルトのインクルード).
このマクロは,必要でないときに余分な宣言を導入することを避けた方が安全な ので,symbolがr-valueとして有効かどうかを実際にテストし,実際に宣 言されているかどうかはテストしません.
それぞれの(カンマで分けられているリスト)symbolsに対し,
symbolが宣言されれいる場合はHAVE_DECL_symbol
を(全て大
文字で)`1'に定義し,それ以外では`0'に定義します.
action-if-not-foundが与えられている場合,関数宣言の一つが必要なと
き実行するシェルコードを追加し,それ以外ではaction-if-foundが実行
されます.
このマクロは,最初の引数としてM4のリストを使用します.
AC_CHECK_DECLS(strdup) AC_CHECK_DECLS([strlen]) AC_CHECK_DECLS([malloc, realloc, calloc, free]) |
他の`AC_CHECK_*S'マクロと異なり,symbolが宣言されていないとき,
HAVE_DECL_symbol
を宣言しないままにする代わりに,
HAVE_DECL_symbol
は`0'で定義されます.調査の実行を
確かめているときは,HAVE_DECL_symbol
をAutoconfの他の
結果と同じように,以下のように使用してください.
#if !HAVE_DECL_SYMBOL extern char *symbol; #endif |
しかし,テストが実行されていない場合,システムのものと衝突するような宣言 を使用するより,シンボルを宣言しない方が安全なので,以下のように 使用すべきでしょう.
#if defined HAVE_DECL_MALLOC && !HAVE_DECL_MALLOC void *malloc (size_t *s); #endif |
究極の状態でのみ二番目のカテゴリに分類されます.ファイルがコンフィグレー ションされずに使用されている場合か,コンフィグレーション時に使用されてい る場合のいずれかです.ほとんどの場合はこれまでの方法で十分です.
以下のマクロは,特定のCの構造体の存在を調査します.必要なメンバーの調査
するために定義されている特定のマクロが無い場合,一般的な構造体メンバーの
マクロを使用したり(see section 一般的な構造体の調査),より複雑なテストに対して
は,AC_COMPILE_IFELSE
を使用してもかまいません(see section コンパイラの実行).
5.8.1 特定の構造体の調査 | Macros to check for certain structure members | |
5.8.2 一般的な構造体の調査 | How to find other structure members |
以下のマクロは,特定の構造体と構造体のメンバーを調査します.
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]) |
`time.h'が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
を定義します.
これらのマクロは,"特定の"テストマクロでカバーされていない構造体のメン バーを検索するために使用します.
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) |
直前のマクロで使用されている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]) |
以下のマクロは,組み込みまたはtypedefになっている,Cの型を調査します.必 要な型を調査するための特別に定義されたマクロがなく,その特別な特性を調査 する必要がない場合,一般的な型調査マクロを使用することが可能です.
5.9.1 特定の型の調査 | Special handling to find certain types | |
5.9.2 一般的な型の調査 | How to find other types |
これらのマクロは,`sys/types.h',`stdlib.h',そして存在する場 合はその他の,特定のCの型を調査します.
gid_t
とint
のどちらかを,getgroups
への配列引数の基本
の型にするため,GETGROUPS_T
を定義します.
<wchar.h>
でmbstate_t
型が宣言されている場合,
HAVE_MBSTATE_T
を定義します.また,<wchar.h>
で宣言されてい
ない場合,型としてmbstate_t
を定義します.
`AC_CHECK_TYPE(mode_t, int)'と同じです.
`AC_CHECK_TYPE(off_t, long)'と同じです.
`AC_CHECK_TYPE(pid_t, int)'と同じです.
`signal.h'が,signal
をvoid
返す関数へのポインタを返す
ものと宣言されている場合,RETSIGTYPE
をvoid
と定義します.そ
れ以外ではint
と定義します.
シグナルハンドラが返す型をRETSIGTYPE
と定義してください.
RETSIGTYPE hup_handler () { … } |
`AC_CHECK_TYPE(size_t, unsigned)'と同じです.
uid_t
が定義されていない場合,uid_t
をint
に,そして
gid_t
をint
に定義します.
これらのマクロは,"特定の"テストマクロがカバーしない型を調査するために 使用されます.
typeが定義されているかどうかを調査します.コンパイラ組み込みの型や, includes(see section デフォルトのインクルード)で定義されている可能性があります.
定義されている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
のドキュメントを読んでください.
時代遅れのマクロを参照してください.
コンパイラ(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 特定のコンパイラの特徴 | Some portability issues | |
5.10.2 一般的なコンパイラの特徴 | Language independent tests and features | |
5.10.3 Cコンパイラの特徴 | Checking its characteristics | |
5.10.4 C++コンパイラの特徴 | Likewise | |
5.10.5 Fortranコンパイラの特徴 | Likewise |
コンパイラによっては異なる動作を示すものもあります.
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
にキャストするこ
とで,この問題を解決します.
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に定義します.
通常,Autoconfはコンパイラ,リンカ,そしてプリプロセッサが生成する警告を
無視します.このマクロが使用されている場合,現在の言語に対し,警告は重大
なエラーとして処理されます.このマクロは,コンフィグレーションの結果が,
予期せぬ警告が生じる場所で使用されるとき役に立ちます.例えば,プログラム
の一部を`-Werror'オプションでビルドしている場合があてはまります.プ
ログラム全体を`-Werror'を使用してビルドしている場合,コンパイラフラ
グに単純に(CFLAGS
などで)`-Werror'を追加したほうがより単純で
しょう.
以下のマクロは,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
指示語の生成を停止した理由です.
使用する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'に設定します.
Cコンパイラが`-c'と`-o'オプションを同時に受け入れない場合,
NO_MINUS_C_MINUS_O
を定義します.このマクロは,AC_PROG_CC
で見つかったコンパイラと,パスの最初のcc
がそれと異なっている場合
はその両方を,実際にテストします.一つでも失敗した場合,テストは失敗しま
す.このマクロは,GNU Makeがデフォルトのコンパイルルールを選択
するように作成されました.
出力変数CPP
を,Cプリプロセッサを実行するコマンドに設定ます.
`$CC -E'が動作しない場合,`/lib/cpp'を使用します.拡張子が
`.c'のファイルでCPP
を実行することは移植性のためだけです.
プロセッサによっては,足りないインクルードファイルをエラーステータスで示
さないものもあります.そのようなプロセッサに対する内部変数は,プリプロセッ
サからの標準エラーを調査するための他のマクロを設定し,警告が報告された場
合はテストに失敗したと判断します.それにもかかわらず,ほとんどのプリプロ
セッサに対して,AC_PROG_CPP_WERROR
も指定しない限り,警告でインク
ルードファイルのテストは失敗します.
これはAC_PROG_CPP
のように動作しますが,プリプロセッサからの警告を,
プリプロセッサが成功したことを示すステータスで終了した場合でも,エラーが
あったとして処理します.これは,推奨されない注意のような,強制的な警告を
生成するヘッダを避けるときに役に立ちます.
以下のマクロは,Cコンパイラやマシンアーキテクチャの特徴を調査します.こ
こでリストアップされない特徴を調査するために,AC_COMPILE_IFELSE
(see section コンパイラの実行)やAC_RUN_IFELSE
(see section 実行時の動作の調査)
を使用してください.
Cコンパイラが`\a'を理解する場合,`HAVE_C_BACKSLASH_A'を1に定義 します.
(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のデフォルトは,コンフィグレーションを中断し,イ ンストールしている人に,このテストをバイパスさせるために変数を前もって定 義するよう伝えます.
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コンパイラを入手すべきです.
Cコンパイラがrestrict
キーワードを認識する場合は何もしません.
(__restrict
,__restrict__
,または_Restrict
)という,
かわったつづりだけを認識する場合,restrict
をそれに定義します.そ
れ以外では,restrict
を空で定義します.このため,プログラムでは
restrict
をすべてのCコンパイラがサポートしているかのように,単純に
使用してかまいません.そうしない人は,`Makefile'やコンフィグレーショ
ンヘッダで頑張って定義して下さい.
C++でのrestrict
キーワードサポートは要求されていませんが,いくつか
のC++コンパイラはそのキーワードを受け入れます.このマクロは,そこでも動
作します.
Cコンパイラがキーワードvolatile
を理解しない場合,volatile
を空で定義します.プログラムではvolatile
をサポートしているコンパ
イラのように単純に使用することが可能です.サポートしないものに対しては,
`Makefile'やコンフィグレーションヘッダで,それを空として定義されま
す.
プログラムの正当性がvolatile
の意味に依存している場合,単純に空で
定義するとある意味ではコードが壊れます.しかし,volatile
をサポー
トしていないコンパイラでは,自分で何とかしてください.少なくともプログラ
ムはコンパイルされますが,多分駄目でしょう.
一般的に,volatile
キーワードはANSI Cの機能なので,
__STDC__
が定義されているときだけ,volatile
が利用可能だと期
待するかもしれません.しかし,Ultrix 4.3のネイティブコンパイラは
volatile
をサポートとしていますが,__STDC__
を定義しません.
Cコンパイラがキーワードinline
をサポートする場合,何もしません.そ
れ以外では,受け入れられるものによって,inline
を__inline__
や__inline
に定義し,それ以外ではinline
を空で定義します.
Cの型char
がunsignedの場合,Cコンパイラが前もって定義していない限
り,__CHAR_UNSIGNED__
を定義します.
Cコンパイラが,double
の型以上の範囲で動作するlong double
の型をサポートしている場合,HAVE_LONG_DOUBLE
を定義します.
Cプリプロセッサが文字列作成オペレータをサポートする場合,
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
も定義します.これは,ユーザの名前空間
を侵害するマクロが使用不可能なヘッダファイルの利便性ためです.
使用しているGNU Cコンパイラとioctl
が,
`-traditional'無しでは正確に動作しない場合,出力変数CC
に
`-traditional'を加えます.それは通常,修正されたヘッダファイルが古
いシステムにインストールされていないときに発生します.GNU Cコ
ンパイラの最近のバージョンは,インストール時に,自動的にヘッダファイルを
修正するので,これはほとんど問題になりません.
使用する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'を設定します.
出力変数CXXCPP
を,C++プリプロセッサを実行するコマンドに設定します.
`$CXX -E'が動作しない場合,`/lib/cpp'を使用します.`.c',
`.C',または`.cc'の拡張子を持つファイルでCXXCPP
を実行す
るのは移植性のためだけです.
プリプロセッサによっては,足りないインクルードファイルをエラーステータス で示さないものもあります.そのようなプリプロセッサに対して,内部変数は, プリプロセッサからの標準エラー出力を調査する他のマクロに設定され,警告が 報告されない場合はテストに失敗したと考えます.しかし,C++に対してそのよ うな壊れ方をしているプリプロセッサがあるかどうかは知りません.
AutoconfのFortranサポートは,二つのカテゴリに分けられました.これまでの
Fortran 77マクロ(F77
)と,現在のFortramマクロ(FC
)です.前者
は伝統的なFortram 77コードを想定していて,F77
,FFLAGS
,そ
してFLIBS
といった出力変数があります.後者は,より新しいFortranの
標準の元でコンパイル可能(または必須)である,より新しいプログラムを想定し
ていて,FC
,FCFLAGS
,そしてFCLIBS
といった出力変数が
あります.
二つの新しいマクロAC_FC_SRCEXT
とAC_FC_FREEFORM
(以下を参照)
以外では,FC
とF77
のマクロの動作はほとんど同じなので,この
セクションでまとめて説明しています.
使用する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'を設定します.
使用する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'に設定します.
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 実行時の動作の調査)
を使用してください.
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++にリンクする必要が
あるときもおそらく必要です.以下を参照してください.
多くのコンパイラでは,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
から自動的に
呼び出されることに注意してください.一般的にデフォルトの動作を変更したく
ない限り,明示的にに呼び出す必要はありません.
上で議論したように,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
の名前にすべきです.
名前が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するものもあるからです.
識別子nameが与えられている場合,シェル変数shellvarをFortran
リンカの規則(AC_F77_WRAPPERS
やAC_FC_WRAPPERS
も参照してくだ
さい)によって,mangleされるバージョンのnameを保持するように設定し
ます.shellvarはオプションです.提供されていない場合,シェル変数は
単純にnameになります.このマクロの目的は,上記のようにCプリプロセッ
サを通じてではなく,呼び出し側に名前のmangleに関する情報にアクセスする方
法を与えることで,例えば,C/C++以外の言語からFortranルーチンを呼び出すた
めです.
デフォルトで,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](デフォルトは
エラーメッセージとともに終了します)を呼び出します.
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](デフォルトはエラーメッセージとと
もに終了します)を呼び出します.
以下のマクロはオペレーティングシステムのサービスや機能を調査します.
X Window Systemのインクルードファイルとライブラリの場所を調査します.ユー
ザがコマンドラインオプションで,`--x-includes=dir'と
`--x-libraries=dir'を与えている場合,そのディレクトリを使用し
ます.どちらか一つまたは両方とも与えられない場合,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
に追加します.
スクリプトを使用するためのインタプリタを選択するため,`#!
/bin/csh'の形式の行を用いたスクリプトをサポートするかどうかを調査します.
このマクロを実行した後で,`configure.ac'のシェルコードは,シェル変
数の interpval
を調査することが可能になります.システムで`#!'
がサポートされている場合は`yes',そうでなければ`no' を設定しま
す.
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
を注意して使用して下さい.
システムが14文字より長いファイル名をサポートする場合,
HAVE_LONG_FILE_NAMES
を定義します.
POSIX termiosヘッダと関数がシステムで利用可能かどうかを調査し
ます.その場合は,シェル変数ac_cv_sys_posix_termios
を`yes'に
設定します.それ以外ではその変数を`no'に設定します.
以下のマクロは,ヘッダファイルやライブラリが例外的に特異なため,プログラ ムに対して特別な処理が必要なオペレーティングシステムを調査します.これら のマクロは不要なものです.利用可能にする関数や,供給する環境に基づき,よ り規則正しい手法で置換されるでしょう.
AIXの場合,_ALL_SOURCE
を定義します.いくつかの
BSD関数の使用を許可します.Cコンパイラを実行するあらゆるマクロ
の前に呼び出すべきです.
GNU Cライブラリを使用している場合,_GNU_SOURCE
を定義し
ます.いくつかのGNUの関数が使用可能になります.Cコンパイラを実
行するマクロの前で呼び出すべきです.
INTERACTIVE UNIX (ISC)に対して,POSIXの機能が必
要な場合,出力変数LIBS
に`-lcposix'を追加します.これは
AC_PROG_CC
の後で,POSIXインターフェースを使用するその他
のマクロの前で呼び出してください.INTERACTIVE UNIXはすでに販売され
ておらず,Sunは2006-07-23でサポートを終了することを告げているので,この
マクロは時代遅れになっています.
Minixの場合,_MINIX
と_POSIX_SOURCE
を定義し,
_POSIX_1_SOURCE
を2と定義します.これでPOSIXの機能が使用
可能になります.Cコンパイラを実行するあらゆるマクロの前で呼び出すべきで
す.
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated by Akihiro Sagawa on June, 15 2005 using texi2html 1.70.