| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
以下のマクロは、パッケージが必要な、あるいは使いたい特定のOSの機能を 調べます。以下のマクロに定義されていない機能の有無をチェックしたい場合、 基本テストマクロ(primitive test macro)に適切な引数を渡してチェックを 実現することになります(see section 5. Writing Tests参照)。
以下のテストは、どの機能をチェックしているか、なにがわかったかを
知らせるメッセージを出力します。チェック結果はconfigureを
再度実行したときのためにキャッシュされます(see section 6.3 Caching Results参照)。
マクロには出力変数を設定するものがあります。出力変数の値を 参照するやりかたについてはSee section 3.3 Substitutions in Makefilesを参照してください。 以下で、「nameを定義します」という文は、 「Cプリプロセッサシンボルnameを1に定義します」という意味です。 定義された値をプログラム中で参照するやりかたについてはSee section 6.1 Defining C Preprocessor Symbols を参照してください。
| 4.1 Alternative Programs | Selecting between alternative programs. | |
| 4.2 Library Files | Library archives that might be missing. | |
| 4.3 Library Functions | C library functions that might be missing. | |
| 4.4 Header Files | Header files that might be missing. | |
| 4.5 Structures | Structures or members that might be missing. | |
| 4.6 Typedefs | typedefs that might be missing. | |
| 4.7 C Compiler Characteristics | ||
| 4.8 Fortran 77 Compiler Characteristics | ||
| 4.9 System Services | Operating system services. | |
| 4.10 UNIX Variants | Special kludges for specific UNIX variants. |
以下のマクロは特定のプログラムの有無、またはふるまいをチェックします。 マクロは、いくつかの候補となるプログラムからどれかひとつを選んだり、 選んだものをどう利用するかを定めるために使われます。 パッケージで使うプログラム専用のマクロが定義されておらず、 そのプログラムに関する特殊なチェックが必要ない場合、 汎用のマクロのうちいずれかを利用することができます。
| 4.1.1 Particular Program Checks | Special handling to find certain programs. | |
| 4.1.2 Generic Program and File Checks | How to find other programs. |
以下のマクロは特定のプログラムをチェックします--- プログラムが存在するかどうか、およびいくつかのプログラムについては プログラム特有の機能をチェックします。
yytextの型が`char []'でなく
`char *'だった場合、
YYTEXT_POINTERを定義します。
また、lexの出力ファイル名を
出力変数LEX_OUTPUT_ROOTに
定義します。通常は`lex.yy'ですが
他の値のこともあります。これらの結果は
lexとflexのどちらが
利用されているかによって変わります。
mawk、gawk、nawk、
awkがあるかどうかをこの順序で
調べ、出力変数AWKの値を
最初にみつけたプログラムの
名前に設定します。mawkを最初に
調べるのは、これが一番高速動作する
実装だと言われているからです。
CCが設定されて
いなかったら、gccがあるか
どうか調べ、なければccを
使います。出力変数CCを
みつけたコンパイラの名前に設定します。
このマクロは、GNU Cコンパイラを使う場合
shell変数GCCを`yes'に、
そうでない場合空に設定します。
もし出力変数CFLAGSがまだ
設定されていなかったら、
GNU Cコンパイラの場合には
`-g -O2'に設定します
(GCCが`-g'を受け付けない場合
`-O2'に、他のコンパイラの場合
`-g'に設定します)。
現在利用することになっている
Cコンパイラが、configureが
実行されているシステム以外のための
バイナリを生成する場合、
shell変数cross_compilingを
`yes'に設定します。
そうでない場合`no'に設定します。
言い替えれば、このテストは
build対象のシステムが
ホストシステムタイプ(訳註:
コンパイルを行うシステムのタイプ)と
異なるかどうかを調べます
(「ターゲットシステムタイプ」は
このマクロとは無関係です)。
クロスコンパイルのサポートに
ついてはSee section 8. Manual Configurationを
参照してください。
NO_MINUS_C_MINUS_Oを定義します。
CPPに、Cプリプロセッサを
実行するためのコマンド名を定義します。
`$CC -E'が動かない場合、
`/lib/cpp'が使われます。
CPPを`.c'ファイル以外に
用いるのは移植性がありません。
移植性のために、CPPに通すのは
拡張子が`.c'のファイルだけにしましょう。
現在選択されている言語がCの場合
(see section 5.8 Language Choice参照)、
一部のテストマクロは出力変数CPPの
値を間接的に利用しています。
「間接的に」というのは、テストマクロ内部でマクロ
AC_TRY_CPP、AC_CHECK_HEADER、
AC_EGREP_HEADER、AC_EGREP_CPPを
呼び出しているからです。
CXXまたはCCCが
定義されていないか(CXXを先に)
調べます;
もし定義されていたら、定義されている値を
出力変数CXXにセットします。
さもなくば、C++コンパイラらしい名前の
プログラムを探します
(c++, g++, gcc, CC,
cxx, それからcc++)。
もし以上のチェックが全て失敗したら、
最後の手段としてCXXをgccにセットします。
GNU C++コンパイラを利用する場合、
shell変数GXXを`yes'に、
さもなくば空にセットします。
出力変数CXXFLAGSがまだ定義されて
いない場合、CXXFLAGSを定義します。
GNU C++コンパイラを
利用するなら`-g -O2'(GNU C++が
`-g'を受け付けない場合`-O2')に、
他のコンパイラの場合は`-g'になります。
現在利用することになっている
C++コンパイラが、configureが
実行されているシステム以外のための
バイナリを生成する場合、
shell変数cross_compilingを
`yes'に設定します。
そうでない場合`no'に設定します。
言い替えれば、このテストは
build対象のシステムが
ホストシステムタイプ(訳註:
コンパイルを行うシステムのタイプ)と
異なるかどうかを調べます
(「ターゲットシステムタイプ」は
このマクロとは無関係です)。
クロスコンパイルのサポートに
ついてはSee section 8. Manual Configurationを
参照してください。
CXXCPPに、C++プリプロセッサを
実行するためのコマンド名を定義します。
`$CXX -E'が動かない場合、
`/lib/cpp'が使われます。
CXXCPPを`.c'、`.C'
または`.cc'以外のファイルに
用いるのは移植性がありません。
移植性のために、CPPに通すのは
上記に挙げた拡張子をもつファイルだけにしましょう。
現在選択されている言語がC++の場合
(see section 5.8 Language Choice参照)、
一部のテストマクロは出力変数CXXCPPの
値を間接的に利用しています。
「間接的に」というのは、テストマクロ内部でマクロ
AC_TRY_CPP、AC_CHECK_HEADER、
AC_EGREP_HEADER、AC_EGREP_CPPを
呼び出しているからです。
F77が設定されて
いなかったら、g77、f77 そして f2cを
この順番で調べます。出力変数F77をみつけたコンパイラの名前に設定し
ます。
g77(GNU Fortran 77コンパイラ)を使う場合AC_PROG_F77はshell
変数G77を`yes'に、そうでない場合空に設定します。もし出力変数
FFLAGSがその環境でまだ設定されていなかったら、g77の場合に
は`-g -02'を(g77が`-g'を受け付けない場合`-O2'に設
定します)、他のコンパイラの場合`-g'にFFLAGSを設定します
F77_NO_MINUS_C_MINUS_O を
定義します。
ioctlがうまく動かない場合、
出力変数CCに`-traditional'を
付け加えます。
通常、これはGNU Cコンパイラ用に修正された
ヘッダファイルがインストールされていない
古いシステムで起こります。
GNU Cコンパイラの最近のバージョンでは、
インストール時にヘッダファイルを修正するので、
この問題は起きなくなってきました。
PATH上にBSD互換の
installプログラムがあった場合、
出力変数INSTALLをその名前にセットします。
さもなくば、`dir/instal-sh -c'を
セットします。
後者の場合、AC_CONFIG_AUX_DIRに
指定されたディレクトリ(またはデフォルトの
ディレクトリ)を使ってdirを決定します
(see section 3.2 Creating Output Files)。
さらに、INSTALL_PROGRAMとINSTALL_SCRIPTを`${INSTALL}'に、
INSTALL_DATAを`${INSTALL} -m 644'にセットします。
このマクロは、うまく動作しない
installプログラムを無視します。
プログラムを探す際には、速度のためにスクリプトよりは
Cで書かれたプログラムの方を優先します。
`install-sh'以外に、`install.sh'を
使うこともできますが、`install.sh'という
ファイル名はobsoleteなので使わない方がいいでしょう(訳註: 意訳)。
これは、
一部のmakeが、`Makefile'がないときに
`install.sh'から`install'を生成する
ルールをもっているためです。
パッケージに含める(訳註: 意訳)
`install-sh'としては、
Autoconfと一緒に配布されている`install-sh'を
利用することができます。
AC_PROG_INSTALLを利用した場合、
`install-sh'または`install.sh'を
配布に含める必要があります。
含めなかった場合、configureは
ファイルがみつからなかった旨
エラーメッセージを出力します。
エラーメッセージは正しく動作する
installがある場合にも出力されます。
このチェックは、install-shを
パッケージに含め忘れないための安全策です。
含め忘れた場合、あなたのパッケージを
BSD互換のinstallプログラムのない
システムでインストールできなくなってしまいます。
標準的なinstallプログラムにない機能が
必要で独自のインストールプログラムを利用したい
場合には、AC_PROG_INSTALLを利用する
必要はありません; 御自分のインストールプログラムへの
パス名を`Makefile.in'に単に含めればいいのです。
flexがあったら、出力変数LEXを
`flex'に、(もし`libfl.a'が
標準的な場所にあったら)LEXLIBを
`-lfl'に設定します。
もしflexがなかったら、
LEXを`lex'に、
LEXLIBを`-ll'に設定します。
LN_Sを`ln -s'に設定します。
動かなかったら、`ln'に設定します。
カレントディレクトリ以外のパス名をリンク先として
指定した場合、`ln'と`ln -s'では
意味が異なってきます。
`$(LN_S)'を使って安全にリンクを作成するためには、
makefile中でどちらが使われているか調べて動作を変えるか、
lnコマンドをリンクが置かれるディレクトリで
呼び出すかのいずれかを行わねばなりません。
言い替えれば、以下はうまく動きません:
$(LN_S) foo /x/bar |
ので、かわりにこうしましょう:
(cd /x && $(LN_S) foo bar) |
ranlibがみつかったら、出力変数
RANLIBを`ranlib'に設定します。
さもなくば、:(なにもしない)に設定します。
bisonがみつかったら、出力変数
YACCを`bison -y'に設定します。
かわりにbyaccがみつかったら、出力変数
YACCを`byacc'に設定します。
さもなくば、yaccに設定します。
以下のマクロは、プログラムをみつけるための専用マクロが特に
定義されていないプログラムをみつけるために使われます。
プログラムの存在だけでなくプログラムの挙動を調べたい場合、
自分でテストスクリプトを記述する必要があります(see section 5. Writing Tests)。
デフォルトでは、マクロは環境変数PATHを使います。
ユーザのPATHにないようなプログラムをチェックする場合、
以下のように自分でサーチパスを変更してマクロに渡すことができます:
AC_PATH_PROG(INETD, inetd, /usr/libexec/inetd, $PATH:/usr/libexec:/usr/sbin:/usr/etc:etc) |
AC_CHECK_FILEをfilesに列挙したそれぞれのファイルごとに一度
ずつ実行します。さらに見つけたファイルそれぞれに対して
`HAVE_file'を1に定義します。
PATH中に
あるかどうかを調べます。もし発見された場合variableを
value-if-foundに設定します。発見されなかった場合
(value-if-not-foundが指定されていた場合は)
value-if-not-foundに設定します。
このマクロは、reject (絶対パスのファイル名)を
サーチパス上で発見してもそれは無視します。
この場合、variableはパス上でみつかった
prog-to-check-forで、rejectではない
ファイルの絶対パス名になります。
variableが既に設定されていた場合、なにもしません。
variableのために、AC_SUBSTを呼び出します。
PATH上に
あるかどうかを調べます。もしあった場合、
そのプログラム名をvariableに設定します。
さもなくば、次のプログラム名を探します。
もし、指定された全てのプログラムがなかった場合、
value-if-not-foundの値をvariableに設定します。
もしvalue-if-not-foundが指定されていなかったら、
variableの値は変更されません。
variableのために、AC_SUBSTを呼び出します。
AC_CHECK_PROGと同様ですが、prog-to-check-forの
先頭にAC_CANONICAL_HOSTで判定されたホストタイプを
つけたものを最初に探します(see section 8.2 Getting the Canonical System Type参照)。
例えば、ユーザが`configure --host=i386-gnu'を
実行し、その中で
AC_CHECK_TOOL(RANLIB, ranlib, :) |
RANLIBに設定します。
プログラムがなければRANLIBは`:'にされます。
AC_CHECK_PROGと同様ですが、
プログラムが発見された場合variableを
prog-to-check-forの絶対パスに設定します。
AC_CHECK_PROGSと同様ですが、
progs-to-check-forの中のいずれかが
見付かったら、プログラムの絶対パスを
variableに設定します。
以下のマクロは指定されたC、C++、Fortran 77ライブラリファイル(および中身)が 存在するかどうかを調べます。
action-if-foundには、リンクが成功した場合に
呼び出されるshellコマンド列を指定します。
action-if-not-foundには、リンクが失敗したときに
呼び出されるshellコマンド列を指定します。
action-if-foundが
指定されなかった場合、デフォルトの動作になります。
デフォルトの動作はLIBに`-llibrary'を追加し、
`HAVE_LIBlibrary'を(全部大文字)定義するように
なっています。
もしlibraryだけとリンクするのでは未解決のシンボルが 出てしまい、他のライブラリをリンクしないといけない場合には、 それらのライブラリ名をスペースで区切ってother-librariesに 指定してください: `-lXt -lX11'のように。 指定しなかった場合、マクロはlibraryが存在することを 検出できません。なぜなら、未解決シンボルのせいでリンクが 常に失敗するからです。
AC_CHECK_LIBを、引数functionを
mainにして呼び出すのと同じです。引数libraryは
`foo'でも`-lfoo'でも、あるいは`libfoo.a'
とでも指定できます。これらの全ての場合に、コンパイラには
引数`-lfoo'が渡ります。
libraryにshell変数を渡すことはできません。
libraryは文字列リテラルである必要があります。
このマクロはobsoleteです。
AC_TRY_LINK_FUNCを最初にラ
イブラリなしで、それからsearch-libsに列挙されたライブラリをそれぞ
れ指定して呼び出すのと同じです。
関数が見つかればaction-if-foundを実行します。そうでなければ action-if-not-foundを実行します。
もし、libraryのリンクがシンボル未解決という結果になり、追加のライ ブラリとともにリンクすることによってそれが解決するようならば、そのような ライブラリをother-libraries引数に空白区切りで`-lXt -lX11'のよ うに与えてください。そうでなければ、テストプログラムのリンクがいつもシン ボル未解決で失敗するので、このマクロはfunctionが存在することを発見 するのに失敗するでしょう。
AC_TRY_LINK_FUNCの一回の呼び出しと同じです。特定のfunction
が見つかった最初のライブラリに対し、`-llibrary'をLIBS
に追加し、action-if-foundを実行します。それ以外の場合は
action-if-not-foundを実行します。
以下のマクロは、Cのライブラリ関数があるかどうかを調べます。 もし、あるマクロをチェックする特別の関数が定義されておらず、 特殊なチェックが必要でない場合には、汎用の関数チェックマクロを 用いることができます。
| 4.3.1 Particular Function Checks | Special handling to find certain functions. | |
| 4.3.2 Generic Function Checks | How to find other functions. |
以下のマクロは、特定のCライブラリ関数をチェックします --- 関数が存在するかどうか、および特定の引数を与えられたときの 挙動がチェックされます。
allocaの有無をチェックします。
このチェックでは、なるべくコンパイラ組み込みの
allocaを探そうとします。
このために、`alloca.h'があるかどうかおよび
Cプリプロセッサマクロ__GNUC__と
_AIXがあらかじめ定義されているかを調べます。
もし`alloca.h'がみつかったら、
HAVE_ALLOCA_Hが定義されます。
上記のチェックが失敗したら、標準Cライブラリに
関数があるかどうかを探します。
ここまでのチェックのいずれかが成功した場合、
HAVE_ALLOCAを定義します。
全てが失敗した場合、出力変数ALLOCAを
`alloca.o'に定義し、C_ALLOCAを定義します
(C_ALLOCAは、プログラムがGCのために
定期的に`alloca(0)'を呼び出すことが
できるようにするため定義されます)。
ALLOCAはLIBOBJSとは独立に定義されます。
これは複数のプログラムをコンパイルするとき、
allocaを実際使うものが少なかった場合に
いちいち`alloca.o'をコンパイルしなくて済むようにするためです
(訳註: 超意訳。自信なし。原文は「
This variable is separate from LIBOBJS so multiple programs can
share the value of ALLOCA without needing to create an actual
library, in case only some of them use the code in LIBOBJS.」)。
このマクロはSystem V R3の`libPW'や
System V R4の`libucb'に含まれる
allocaを探すことはしません。
なぜなら、これらのライブラリには
場合によってはallocaが
含まれていなかったり、
含まれていてもallocaバグがあったり、
あるいは互換性に問題のあるalloca以外の
関数が含まれていたりするためです。
どうしてもこれらのライブラリに含まれる
allocaを利用したい場合には、
(`alloca.c'をコンパイルするのではなく)
arを使って`alloca.o'を取り出してください。
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 |
closedirが
意味のある値を返さない場合、CLOSEDIR_VOIDを
定義します。
定義されなかった場合には、
closedirを呼んだ場合
返り値を用いてエラーチェックを行うべきです。
fnmatchが存在し、かつ動作するなら、
HAVE_FNMATCHを定義します
(ちなみに、SunOS 5.4付属のものは動きません)。
getloadavgが利用できるなら、
HAVE_GETLOADAVGを定義し、
LIBSに必要なライブラリファイルを追加します。
もしgetloadavgが利用できないなら、
`getloadavg.o'を出力変数LIBOBJSに追加し、
必要ならいくつかのCプリプロセッサマクロや出力変数を定義します:
SVR4、DGUX、UMAXまたは
UMAX4_3のうちであてはまるものを定義します。
NLIST_STRUCTを定義します。
NLIST_NAME_UNIONを定義します。
LDAV_PRIVILEGEDが定義された場合、
getloadavgが正しく動作するには、
プログラムは(setuid bitをたてるなどして)
root権限で動作するようにインストールされる必要があります。
この場合、GETLOADAVG_PRIVILEGEDが定義されます。
NEED_SETGIDが定義されます。
インストールする際にsetgid bitをたてる必要がある場合には
値は`true'に、さもなくば値は`false'になります。
NEED_SETGIDが`true'である場合には、
プログラムファイルの所属すべき
gidがKMEM_GROUPに定義されます。
getmntentがライブラリファイル
`sun'、`seq'および`gen'の
いずれかに含まれているかどうか調べます
(順に、Irix 4、PTX、Unixwareの場合の
ライブラリファイルです)。
getmntentが存在した場合、
HAVE_GETMNTENTを定義します。
getpgrpが引数をとらない場合
(つまりPOSIX.1準拠の場合)、
GETPGRP_VOIDを定義します。
定義されなかった場合、getpgrpはBSDでのように
プロセスIDを引数にとります。
このマクロはgetpgrpがあるかどうかは
全く調べません; getpgrpがない場合に
対処するには、先にAC_CHECK_FUNCを使って
getpgrpがあるかどうか調べてください。
memcmpがないか、
または(SunOS 4.1.3のように)8bitデータに対して
使えない場合、`memcmp.o'を
出力変数LIBOBJSに追加します。
mmapが存在して正常動作する場合、
HAVE_MMAPを定義します。
動作チェックは、既にマップされたメモリを
自プロセスの固定アドレスにマップする場合に関してのみ
行われます。
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.1準拠の場合)、
SETPGRP_VOIDを定義します。
定義されなかった場合、setpgrpはBSDでのように
プロセスIDを引数にとります。
このマクロはsetpgrpがあるかどうかは
全く調べません; setpgrpがない場合に
対処するには、先にAC_CHECK_FUNCを使って
setpgrpがあるかどうか調べてください。
setvbufの第2引数がバッファリングの形式で、
第3引数がバッファへのポインタの場合、
SETVBUF_REVERSEDを定義します。
SETVBUF_REVERSEDが定義されるのは、
release 3以前のSystem Vの場合です。
strcollが存在して正常動作する場合、
HAVE_STRCOLLを定義します。
このマクロはstrcollがあるかどうかを
AC_CHECK_FUNCより詳しく調べます。
一部のシステムでは、strcollの
定義が誤っているためこの関数を使うべきではないからです。
strftimeが`intl'ライブラリにあるかどうかを調べます
(これはSCO UNIXのためです)。
もしあった場合、HAVE_STRFTIMEを定義します。
HAVE_UTIME_NULLを定義します。
HAVE_VFORK_Hを定義します。
正常動作動作するvforkが発見されなかった場合、
vforkをforkに#defineします。
このマクロは、いくつかのシステムでのvforkの
バグをチェックし、バグつきの場合にはvforkが
みつからなかったかのように振舞います。
ただし、子プロセスでsignalを呼んでも
親プロセスのシグナルハンドラが変更されない場合には
これはバグつきとはみなされません。
子プロセスでシグナルハンドラを変更することは
めったにないからです。
vprintfが存在する場合、
HAVE_VPRINTFを定義します。
ない場合に_doprntが存在したら、
HAVE_DOPRNTを定義します。
ちなみに、vprintfが存在したら、
vfprintfとvsprintfも
存在すると仮定して構いません。
wait3が存在し、呼び出し時に第3引数
(`struct rusage *')の指し先の内容がきちんと
設定される場合、
HAVE_WAIT3を定義します。
ちなみに、HP-UXでは第3引数の差し先はきちんと設定されません。
以下のマクロは、チェックのための特別のマクロがないライブラリ関数について
調べるために用意されています。
ライブラリ関数がデフォルトのCライブラリに入っていない
可能性がある場合には、AC_CHECK_LIBを用いて
そのライブラリファイルがあるかどうか調べてください。
ライブラリ関数があるかどうかだけでなく、その振舞いも調べる
必要がある場合には、自前でテストを記述する必要があるでしょう
(see section 5. Writing Tests)。
AC_CHECK_FUNCSを使ったほうがいいでしょう。
このマクロはAC_LANG_CPLUSPLUSが呼ばれているいないに関わらず
C linkageで関数を探します。
C++ではCよりもライブラリ関数がきちんと標準化されているので、
AC_CHECK_FUNCを使う機会は少なそうだからです
(環境を調べる対象の言語を選ぶやりかたについては、
see section 5.8 Language Choiceを参照)。
HAVE_function(全部大文字)を定義します。
action-if-foundには、
各々の関数がみつかったときに実行したいshellスクリプトを記述します。
action-if-foundを`break'にすると、
最初に関数が見つかったところでループを抜けることができます。
action-if-not-foundには、
各関数がみつからなかったときに実行されるshellスクリプトを記述します。
LIBOBJSに`function.o'を追加します。
この動作は、
AC_CHECK_FUNCSで
action-if-not-foundに
「出力変数LIBOBJSに`function.o'を追加する」
と記述した場合と似ています。
ライブラリの置き換え用の関数を定義するときには、
プロトタイプ宣言を`#ifndef HAVE_function'で
くくっておいた方がいいでしょう。
システムにfunctionがある場合、
システム定義のincludeファイルのどこかにプロトタイプ宣言があるはずです。
定義が矛盾するかもしれないから、システムにfunctionが
あるときには再定義を避けるべきです。
以下のマクロはCヘッダファイルがあるかないか調べます。 あなたのチェックしたいヘッダファイルについて 特定ヘッダファイル向けのマクロがなくて、 しかも特殊なことを調べる必要がなければ、 汎用のヘッダファイル検査マクロを使うとよいでしょう。
| 4.4.1 Particular Header Checks | Special handling to find certain headers. | |
| 4.4.2 Generic Header Checks | How to find other headers. |
以下のマクロは特定のシステムヘッダファイルを検査します。 ファイルがあるかどうか、それから必要なときには なにを定義しているかを検査します。
sys_siglistが`signal.h'または`unistd.h'で定義されているなら、
SYS_SIGLIST_DECLAREDを定義します。
AC_HEADER_DIRENTとAC_FUNC_CLOSEDIR_VOIDを呼ぶのと似ていますが、
定義するCプリプロセッサマクロが違います。
AC_DIR_HEADERは
どのヘッダファイルがみつかったのかを表すCプリプロセッサマクロを定義します。
AC_DIR_HEADER、およびこれにより定義されるCプリプロセッサマクロは
obsoleteです。
定義されるCプリプロセッサマクロは以下のとおり:
DIRENT
SYSNDIR
SYSDIR
NDIR
さらに、関数closedirの返り値に意味がない場合には
VOID_CLOSEDIRを定義します。
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型として定義します。
ディレクトリエントリ名をとるためにはNAMLENマクロに
struct direntへのポインタを渡します。
このマクロはSCO Xenixの`dir'と`x'ライブラリも検査します。
major、minor、それから
makedevが定義されておらず、
`sys/mkdev.h'で定義されている場合、
MAJOR_IN_MKDEVを定義します。
`sys/sysmacros.h'で定義されている場合、
MAJOR_IN_SYSMACROSを定義します。
STDC_HEADERSを定義します。
具体的には、`stdlib.h'、`stdarg.h'、`string.h'、
それから`float.h'をチェックします。
これらのヘッダがあれば、多分他のANSI Cヘッダファイルもあるでしょう。
このマクロは、`string.h'でmemchrが定義されているかどうか
調べます(もしmemchrがあればほかのmem系関数もあるでしょう)。
それから、`stdlib.h'でfreeが定義されているかどうか
調べます(もしokならmallocや他の関連関数もあるでしょう)。
さらに、`ctype.h'で定義されるマクロがANSI Cの定義どおり、
`2^7'のビットが立っていても動くかどうか調べます。
ANSI互換のヘッダファイル(とCライブラリ関数)があるかどうか決めるには、
__STDC__でないしにSTDC_HEADERSを使いましょう。
GCCがインストールされているシステムの多くには
ANSI Cヘッダファイルがないからです(訳註: つまり、__STDC__が
あってもANSI Cヘッダファイルがあるとは限らない、ということ)。
ANSI Cヘッダのないシステムでは、どのヘッダでなにを定義しているかは 全くばらばらです。 ですから、どのヘッダファイルに定義があるか探すよりも、 自分で使う関数を自分で定義した方が簡単です。 あるシステムではANSIとBSDの関数が混在しています。 あるシステムはほぼANSI互換なのに`memmove'がありません。 あるシステムはBSD由来の関数を`string.h'や`strings.h'註の マクロとして定義しています。 あるシステムではBSD由来の関数しかなく、`string.h'がありません。 メモリ関係の関数は`memory.h'で定義されていたり、`string.h'で 定義されていたりします。 他にもいろいろ変種があります。 とりあえず、ANSIで定義されている関数が 文字列関係関数をひとつ、 メモリ関係関数を検査すれば多分こと足りるでしょう。 検査が成功すれば、多分他のANSI定義の関数もあるでしょう。 以下を`configure.in'に含めた場合:
AC_HEADER_STDC AC_CHECK_FUNCS(strchr memcpy) |
プログラム中では以下のように定義します:
#if STDC_HEADERS # include <string.h> #else # ifndef HAVE_STRCHR # define strchr index # define strrchr rindex # endif char *strchr (), *strrchr (); # ifndef HAVE_MEMCPY # define memcpy(d, s, n) bcopy ((s), (d), (n)) # define memmove(d, s, n) bcopy ((s), (d), (n)) # endif #endif |
もしプログラム中でmemchr、memset、strtok、
strspnなど、BSD系OSに代用になる関数がないような関数を使う場合、
この定義だけでは足りません。
各関数について配布キット中にプログラムコードを添付しなければなりません。
添付したプログラムを必要なときにだけ使うにはどうすればいいでしょう?
(システムのCライブラリに入っている関数の方が最適化されていて
速いかもしれないので)
例えば関数memchrの場合、
`memchr.c'というファイルを置いて、
`AC_REPLACE_FUNCS(memchr)'を使えば大丈夫です。
HAVE_SYS_WAIT_Hを定義します。
`sys/wait.h'がない場合、exit statusを保持するのにintでなしに
古いBSDのようにunion waitを使っている場合にはPOSIX.1非互換です。
`sys/wait.h'がPOSIX.1互換でない場合には、
ヘッダファイルをincludeせず、
POSIX.1マクロを自分で定義しましょう。
例えば:
#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 |
memcpyやmemcmpなどが`string.h'で定義されておらず、
`memory.h'が存在する場合、NEED_MEMORY_Hを定義します。
このマクロはobsoleteです。
かわりにAC_CHECK_HEADERS(memory.h)を使ってください。
AC_HEADER_STDCの例参照。
HAVE_UNISTD_Hを定義します。
このマクロはobsoleteです。
かわりに`AC_CHECK_HEADERS(unistd.h)'を使ってください。
POSIX.1互換かどうか調べるには以下のようにします:
#if HAVE_UNISTD_H # include <sys/types.h> # include <unistd.h> #endif #ifdef _POSIX_VERSION /* Code for POSIX.1 systems. */ #endif |
_POSIX_VERSIONは、POSIX.1互換のシステムで`unistd.h'をinclude
すると定義されます。
`unistd.h'がないシステムは間違いなくPOSIX.1非互換です。
でも、一部のPOSIX.1非互換のシステムには`unistd.h'があります。
rindexやbzeroがないシステムなら
USGを定義します。
このマクロは
`string.h'、strrchr、memset等が存在すると仮定しています。
USGはobsoleteです。
このマクロでなしに、AC_HEADER_STDCの例題をみてください。
以下のマクロは、特定のヘッダファイル用マクロが定義されていない ヘッダファイルを検査するためのものです。 ヘッダファイルがあるかないかだけでなく、中身もチェックしたい場合、 自力で検査マクロを記述しないといけません(see section 5. Writing Tests参照)。
AC_CHECK_HEADERSを使った方がいいでしょう。
HAVE_header-file(全部大文字)を定義します。
action-if-foundには、
各々のヘッダファイルがみつかったときに実行したいshellスクリプトを記述します。
action-if-foundを`break'にすると、
最初にヘッダファイルが見つかったところでループを抜けることができます。
action-if-not-foundには、
各ヘッダファイルがみつからなかったときに実行されるshellスクリプトを記述します。
以下のマクロは特定の構造体や構造体のメンバを検査します。
ここにない構造体を検査したい場合、
AC_EGREP_CPP (see section 5.1 Examining Declarations)やAC_TRY_COMPILE
(see section 5.2 Examining Syntax)を使ってください。
S_ISDIRやS_ISREGなどの、`sys/stat.h'で定義されている
マクロが正しく動かない場合(返り値が嘘の場合)、
STAT_MACROS_BROKENを定義します。
Tektronix UTekV、Amdahl UTS、それからMotorola System V/88が該当します。
TIME_WITH_SYS_TIMEを定義します。
古いシステムでは、`sys/time.h'が`time.h'をincludeしていて、
しかも`time.h'に複数回includeされた場合に対する対処がないことがあります。
この場合、両方のヘッダファイルを明示的にincludeしてはいけません。
このマクロは、例えば、struct timevalやstruct timezoneと、
struct tmを同時に使うプログラムに有効です。
HAVE_SYS_TIME_Hとあわせて使うのがよいでしょう。
HAVE_SYS_TIME_Hは
AC_CHECK_HEADERS(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 |
struct statにメンバst_blksizeが定義されているなら、
HAVE_ST_BLKSIZEを定義します。
struct statにメンバst_blocksが定義されているなら、
HAVE_ST_BLOCKSを定義します。
もしなければ、`fileblocks.o'を出力変数LIBOBJSに足します。
struct statにメンバst_rdevが定義されているなら、
HAVE_ST_RDEVを定義します。
struct tmが定義されていなければ、
TM_IN_SYS_TIMEを定義します。
TM_IN_SYS_TIMEは、struct tmの定義が欲しければ
`sys/time.h'をincludeせよ、という意味です(訳註: 意訳)。
struct tmにメンバtm_zoneが定義されているなら、
HAVE_TM_ZONEを定義します。
グローバル変数tznameが定義されていたら、HAVE_TZNAMEを定義します。
以下のマクロはCのtypedefを検査します。 検査したいtypedef用に特定のマクロがなくて、 しかも特殊な検査をしたいわけでないのなら、 汎用のtypedef検査マクロが使えます。
| 4.6.1 Particular Typedef Checks | Special handling to find certain types. | |
| 4.6.2 Generic Typedef Checks | How to find other types. |
以下のマクロは、`sys/types.h'と`stdlib.h'の中のC typedefを 検査します(もしファイルがあれば、ですが)。
GETGROUPS_Tを、
getgroupsの引数の型(配列の基底型)にあわせて、
gid_tまたはintに定義します。
mode_tが定義されていない場合、
Cプリプロセッサマクロmode_tをintに#defineします。
off_tが定義されていない場合、Cプリプロセッサマクロoff_tを
longに#defineします。
pid_tが定義されていない場合、Cプリプロセッサマクロpid_tを
intに#defineします。
signalが
「返り値がvoidの関数へのポインタ(つまり、(void (*)())」を
返す場合、RETSIGTYPEをvoidに定義します。
さもなくば、RETSIGTYPEをintに定義します。
シグナルハンドラ関数を定義するときには、
返り値をRETSIGTYPEにしましょう:
RETSIGTYPE
hup_handler ()
{
...
}
|
size_tが定義されていなければ、Cプリプロセッサマクロsize_tを
unsignedと定義します。
uid_tが定義されていなければ、
Cプリプロセッサマクロuid_tをintに、
gid_tをintに定義します。
このマクロは、 特定のtypedef検査マクロが提供されていないtypedefについて調べるときに 使います。
#defineします。
もしヘッダファイルが存在するなら、
`stdlib.h'や`stddef.h'についても調べます。
以下のマクロはCコンパイラやマシンアーキテクチャの特性を調べます。
以下にない性質を調べたい場合、
AC_TRY_COMPILE (see section 5.2 Examining Syntax) か AC_TRY_RUN
(see section 5.4 Checking Run Time Behavior)を使ってください。
WORDS_BIGENDIANを定義します。
例えばMotorolaやSPARCなどのCPUがこれにあたります。
IntelやVAXは違います。
constを完全にサポートしていなければ、
constを空に#defineします。
世の中にはconstをサポートしているのに__STDC__を定義していない
Cコンパイラや、
逆にconstを完全にはサポートしていないのに__STDC__を定義している
Cコンパイラがあります。
AC_C_CONSTを使えば、プログラム中では必ずCコンパイラがconstを
サポートしているつもりで、constを書けば大丈夫です。
Cコンパイラがconstをサポートしていなければ、
constは`Makefile'またはconfiguration header fileで空にされます。
inlineをサポートしていればなにもしません。
inlineがサポートされておらず、__inline__あるいは
__inlineがサポートされていれば、
inlineを__inline__か__inlineに#defineします。
どちらもサポートされていなければ空にします。
charが符号なし(unsigned)だったら、
__CHAR_UNSIGNED__を定義します。
ただし、Cコンパイラが既に__CHAR_UNSIGNED__を
定義していたらなにもしません。
long double型をサポートしていたら、
HAVE_LONG_DOUBLEを定義します。
世の中には
__STDC__を定義していないのに
long doubleをサポートしているCコンパイラや、
__STDC__を定義しているのに
long doubleをサポートしていないCコンパイラがあります。
HAVE_STRINGIZEを定義します。文字列化演算子は`#' で、以下のよ
うなマクロ定義の中で見出せます。
#define x(y) #y |
SIZEOF_uctypeをC(またはC++の)基底型typeの
バイトサイズにします。
typeは例えば`int'とか`char *'とかです。
コンパイラが`type'を知らない場合、SIZEOF_uctypeは
0になります。
uctypeは、typeの小文字を大文字に、スペースを下線`_'に、
アスタリスク(`*')を`P'にしたものです。
クロスコンパイルをしている場合、
cross-sizeを指定していればそれが使われます。
クロスコンパイルをしている場合に
cross-sizeが指定されていないと、
configureはエラーメッセージを出して終了します。
例えば、DEC Alpha AXPで
AC_CHECK_SIZEOF(int *) |
SIZEOF_INT_Pは8になります。
intが16ビットの場合、INT_16_BITSを定義します。
このマクロはobsoleteです。
かわりにより汎用的な`AC_CHECK_SIZEOF(int)'を使ってください。
long intが64ビットの場合、LONG_64_BITSを定義します。
このマクロはobsoleteです。
かわりにより汎用的な`AC_CHECK_SIZEOF(long)'を使ってください。
以下のマクロはFortran 77コンパイラの特性を検査します。ここに列挙されてい
ない特性を検査するには、AC_TRY_COMPILE(see section 5.2 Examining Syntax)
や AC_TRY_RUN (see section 5.4 Checking Run Time Behavior) を使います。まず現在選択されてい
る言語がFortran 77 AC_LANG_FORTRAN77 に設定されていることを確かめ
てください(see section 5.8 Language Choice)。
FLIBSはこれらのフラグに設定されます。
このマクロは例えば、1つのプログラムや共有ライブラリでC++とFortran 77ソー スコードを混合する必要がある場合に使われることを意図されています。 (see section `Mixing Fortran 77 With C and C++' in GNU Automake)。
例えば、もしC++とFortran 77コンパイラからのオブジェクトファイルが一緒に リンクされなければならないなら、C++コンパイラ/リンカはリンクのために使わ れなければなりません(C++特有のものは、リンク時にグローバルコンストラクタ、 インスタンステンプレート、例外処理等を呼び出す必要が生じるためです)。
しかし、Fortran 77イントリンシックとランタイムライブラリも同様にリンクす
る必要がありますが、C++コンパイラ/リンカは、デフォルトでFortran 77ライブ
ラリを加える方法を知りません。そのため、マクロ
AC_F77_LIBRARY_LDFLAGSは、これらのFortran 77ライブラリを決定する
ため作られました。
The following macros check for operating system services or capabilities.
CYGWIN を`yes'に設定します。もしそうでないならCYGWIN
を空文字列に設定します。
EXEEXTを定義します。典型的にはUNIXなら空文字列に、
Win32やOS/2なら`.exe'に設定します。
OBJEXTを定義します。典型的にはUNIXなら`o' に、Win32なら
`obj'に設定します。
MINGW32を`yes'に設定します。そうでないなら
MINGW32を空文字列に設定します。
configureの呼び出し時に、ユーザが
`--x-includes=dir'や`--x-libraries=dir'を
指定していたら、指定されたディレクトリを使います。
片方または両方とも指定されていなかったら、
決まっていない値を、
簡単な`Imakefile'をxmkmfに食わせ、
生成された`Makefile'を調べることで定めます。
もしこれが(xmkmfがないとかの理由で)失敗したら、
一般的にX Window Systemが置かれるディレクトリを探します。
いずれかの方法で値が決まったら、
shell変数x_includesとx_librariesに結果を格納します。
ただし、ディレクトリがコンパイラのデフォルトサーチパスに入っている場合には
値は設定されません。
上記の方法でもディレクトリがわからなかった場合や、
ユーザが`--without-x'を指定していた場合、
no_xを`yes'に設定します。
no_xは`yes'でなければ空になります。
AC_PATH_Xの拡張版です。
X_CFLAGSにXが必要とするCコンパイラのフラグを、
X_LIBSにリンカのフラグを設定します。
Xがない場合にはX_CFLAGSに`-DX_DISPLAY_MISSING'を追加します。
このマクロは、
Xを使うプログラムをコンパイルするときに特別なライブラリが必要なら、
それもチェックしてX_EXTRA_LIBSに追加します。
X11R6特有のライブラリのうち`-lX11'より前に指定しないといけない
ものがあったら、
それをX_PRE_LIBSに追加します。
configure.inの中に記述するshellスクリプトの中で、
shell変数interpvalを使えます。
このshell変数の値はシステムが`#!'をサポートしていれば`yes'、
していなければ`no'になります。
HAVE_LONG_FILE_NAMESを定義します。
HAVE_RESTARTABLE_SYSCALLSを定義します。
以下のマクロは、ヘッダファイルやライブラリに癖があるなどの理由で、 特別な取扱が必要なOSについてチェックします。 これらのマクロは無理矢理作った逃げ道です (訳註: wartだから「目の上のたんこぶ」とか言ってもいいのだけれど、 それでは意味が通じない)。 本来はよりシステマチックに、ライブラリやヘッダファイルの内容および機能や、 OSで提供される環境について調べるべきです。
_ALL_SOURCEを定義します。
BSDの機能の一部が使えます。
Cコンパイラを実行するマクロより前に使わないといけません。
LIBSに追加します。
このマクロはobsoleteです。
かわりにAC_FUNC_GETMNTENTを使いましょう。
LIBSに追加します。
このマクロはobsoleteです。
getmntentを使いたいためにこのマクロを使っていたのなら、
AC_FUNC_GETMNTENTを使いましょう。
NISサポート入りのパスワード/gid系関数を使いたければ、
`AC_CHECK_LIB(sun, getpwnam)'を使いましょう。
_POSIX_SOURCEを定義し、`-posix'(GNU Cコンパイラ用)
または`-Xp'(他のCコンパイラ用)をCCに追加します。
AC_PROG_CCより後で、しかもCコンパイラを呼び出す他のマクロより先に
呼び出さねばなりません。
_MINIXと_POSIX_SOURCEを定義し、
_POSIX_1_SOURCEを2に定義します。
こうするとPOSIXの機能が使えます。
Cコンパイラを実行するマクロより前に使わないといけません。
LIBSに追加します。
このマクロはobsoleteです。
かわりにAC_FUNC_STRFTIMEを使いましょう。
LIBSに追加します。
また、`dirent.h'が使われていたら、`-ldir'を出力変数LIBSに
追加します。
このマクロはobsoleteです。
AC_HEADER_DIRENTを使いましょう。
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |