📄 autobook_33.html
字号:
<HTML><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><!-- Created on September, 12 2004 by texi2html 1.64 --><!-- Written by: Lionel Cons <Lionel.Cons@cern.ch> (original author) Karl Berry <karl@freefriends.org> Olaf Bachmann <obachman@mathematik.uni-kl.de> and many others.Maintained by: Olaf Bachmann <obachman@mathematik.uni-kl.de>Send bugs and suggestions to <texi2html@mathematik.uni-kl.de> --><HEAD><TITLE>Autoconf, Automake, and Libtool: What to check for</TITLE><META NAME="description" CONTENT="Autoconf, Automake, and Libtool: What to check for"><META NAME="keywords" CONTENT="Autoconf, Automake, and Libtool: What to check for"><META NAME="resource-type" CONTENT="document"><META NAME="distribution" CONTENT="global"><META NAME="Generator" CONTENT="texi2html 1.64"><script language="Javascript"><!-- // Check the browser version. function checkVersion() { if (navigator.appVersion.charAt(0)>=3) return true; if (navigator.appVersion.charAt(0)>=4) return true; else return false; } if (checkVersion()) { homeon = new Image(); homeon.src = "homeon.png"; homeoff = new Image(); homeoff.src = "home.png"; tocon = new Image(); tocon.src = "tocon.png"; tocoff = new Image(); tocoff.src = "toc.png"; indexon = new Image(); indexon.src = "indexon.png"; indexoff = new Image(); indexoff.src = "index.png"; helpon = new Image(); helpon.src = "helpon.png"; helpoff = new Image(); helpoff.src = "help.png"; backon = new Image(); backon.src = "backon.png"; backoff = new Image(); backoff.src = "back.png"; forwardon = new Image(); forwardon.src = "forwardon.png"; forwardoff = new Image(); forwardoff.src = "forward.png"; prevon = new Image(); prevon.src = "prevon.png"; prevoff = new Image(); prevoff.src = "prev.png"; nexton = new Image(); nexton.src = "nexton.png"; nextoff = new Image(); nextoff.src = "next.png"; upon = new Image(); upon.src = "upon.png"; upoff = new Image(); upoff.src = "up.png"; } function img_act(imgName) { if (checkVersion()) { imgOn = eval(imgName + "on.src"); document [imgName].src = imgOn; } } function img_inact(imgName) { if (checkVersion()) { imgOff = eval(imgName + "off.src"); document [imgName].src = imgOff; } }// --></SCRIPT></HEAD><BODY LANG="EN" BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#6688AA" VLINK="#336688" ALINK="#808080"><A NAME="SEC33"></A><TABLE BORDER=0 CELLPADDING=0 CELLSPACING=10><TR VALIGN="TOP"><TD ALIGN="MIDDLE" WIDTH=50 BGCOLOR="#e6e6e6"><TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0><TR VALIGN="TOP" ALIGN="LEFT"><TD VALIGN="MIDDLE" ALIGN="LEFT"><A HREF="autobook_32.html#SEC32" onMouseover="img_act('prev')" onMouseout="img_inact('prev')"><IMG SRC="prev.png" BORDER="0" ALT="Back: Ordering Tests" ALIGN="MIDDLE" NAME="prev"></A></TD></TR><TR VALIGN="TOP" ALIGN="LEFT"><TD VALIGN="MIDDLE" ALIGN="LEFT"><A HREF="autobook_34.html#SEC34" onMouseover="img_act('next')" onMouseout="img_inact('next')"><IMG SRC="next.png" BORDER="0" ALT="Forward: Using Configuration Names" ALIGN="MIDDLE" NAME="next"></A></TD></TR><TR VALIGN="TOP" ALIGN="LEFT"><TD VALIGN="MIDDLE" ALIGN="LEFT"> <TR VALIGN="TOP" ALIGN="LEFT"><TD VALIGN="MIDDLE" ALIGN="LEFT"><A HREF="autobook_34.html#SEC34" onMouseover="img_act('back')" onMouseout="img_inact('back')"><IMG SRC="back.png" BORDER="0" ALT="FastBack: Using Configuration Names" ALIGN="MIDDLE" NAME="back"></A></TD></TR><TR VALIGN="TOP" ALIGN="LEFT"><TD VALIGN="MIDDLE" ALIGN="LEFT"><A HREF="autobook_29.html#SEC29" onMouseover="img_act('up')" onMouseout="img_inact('up')"><IMG SRC="up.png" BORDER="0" ALT="Up: Writing configure.in" ALIGN="MIDDLE" NAME="up"></A></TD></TR><TR VALIGN="TOP" ALIGN="LEFT"><TD VALIGN="MIDDLE" ALIGN="LEFT"><A HREF="autobook_35.html#SEC35" onMouseover="img_act('forward')" onMouseout="img_inact('forward')"><IMG SRC="forward.png" BORDER="0" ALT="FastForward: Introducing GNU Automake" ALIGN="MIDDLE" NAME="forward"></A></TD></TR><TR VALIGN="TOP" ALIGN="LEFT"><TD VALIGN="MIDDLE" ALIGN="LEFT"><A HREF="autobook.html#SEC_Top" onMouseover="img_act('home')" onMouseout="img_inact('home')"><IMG SRC="home.png" BORDER="0" ALT="Top: Autoconf, Automake, and Libtool" ALIGN="MIDDLE" NAME="home"></A></TD></TR><TR VALIGN="TOP" ALIGN="LEFT"><TD VALIGN="MIDDLE" ALIGN="LEFT"><A HREF="autobook_toc.html#SEC_Contents" onMouseover="img_act('toc')" onMouseout="img_inact('toc')"><IMG SRC="toc.png" BORDER="0" ALT="Contents: Table of Contents" ALIGN="MIDDLE" NAME="toc"></A></TD></TR><TR VALIGN="TOP" ALIGN="LEFT"><TD VALIGN="MIDDLE" ALIGN="LEFT"><A HREF="autobook_285.html#SEC285" onMouseover="img_act('index')" onMouseout="img_inact('index')"><IMG SRC="index.png" BORDER="0" ALT="Index: Index" ALIGN="MIDDLE" NAME="index"></A></TD></TR><TR VALIGN="TOP" ALIGN="LEFT"><TD VALIGN="MIDDLE" ALIGN="LEFT"><A HREF="autobook_abt.html#SEC_About" onMouseover="img_act('help')" onMouseout="img_inact('help')"><IMG SRC="help.png" BORDER="0" ALT="About: About this document" ALIGN="MIDDLE" NAME="help"></A></TD></TR></TABLE></TD><TD ALIGN="LEFT"><H2> 6.4 What to check for </H2><!--docid::SEC33::--><P>Deciding what to check for is really the central part of writing<TT>`configure.in'</TT>. Once you've read the Autoconf reference manual,the "how"s of writing a particular test should be fairly clear. The"when"s might remain a mystery -- and it's just as easy to check for toomany things as it is to check for too few.</P><P>One notable area of divergence between various Unix-like systems is thatthe same programs don't exist on all systems, and, even when they do,they don't always work in the same way. For these problems werecommend, when possible, following the advice of the GNU CodingStandards: use the most common options from a relatively limited set ofprograms. Failing that, try to stick to programs and options specifiedby POSIX, perhaps augmenting this approach by doing checks for knownproblems on platforms you care about.</P><P>Checking for tools and their differences is usually a fairly small partof a <TT>`configure'</TT> script; more common are checks for functions,libraries, and the like.</P><P>Except for a few core libraries like <TT>`libc'</TT> and, usually,<TT>`libm'</TT> and libraries like <TT>`libX11'</TT> which typically aren'tconsidered system libraries, there isn't much agreement about librarynames or contents between Unix systems. Still, libraries are easy tohandle, because decisions about libraries almost always only affect thevarious <TT>`Makefile'</TT>s. That means that checking for another librarytypically doesn't require major (or even, sometimes, any) changes to thesource code. Also, because adding a new library test has a small impacton the development cycle -- effectively just re-running <TT>`configure'</TT>and then a relink -- you can effectively adopt a lax approach tolibraries. For instance, you can just make things work on the fewsystems you immediately care about and then handle library changes on anas-needed basis.</P><P>Suppose you do end up with a link problem. How do you handle it? Thefirst thing to do is use <CODE>nm</CODE> to look through the system librariesto see if the missing function exists. If it does, and it is in alibrary you can use then the solution is easy -- just add another<CODE>AC_CHECK_LIB</CODE>. Note that just finding the function in a libraryis not enough, because on some systems, some "standard" libraries areundesirable; <TT>`libucb'</TT> is the most common example of a library whichyou should avoid.</P><P>If you can't find the function in a system library then you have asomewhat more difficult problem: a non-portable function. There arebasically three approaches to a missing function. Below we talk aboutfunctions, but really these same approaches apply, more or less, totypedefs, structures, and global variables.</P><P>The first approach is to write a replacement function and eitherconditionally compile it, or put it into an appropriately-named file anduse <CODE>AC_REPLACE_FUNCS</CODE>. For instance, Tcl uses<CODE>AC_REPLACE_FUNCS(strstr)</CODE> to handle systems that have no<CODE>strstr</CODE> function.</P><P>The second approach is used when there is a similar function with adifferent name. The idea here is to check for all the alternatives andthen modify your source to use whichever one might exist. The idiomhere is to use <CODE>break</CODE> in the second argument to<CODE>AC_CHECK_FUNCS</CODE>; this is used both to skip unnecessary tests andto indicate to the reader that these checks are related. For instance,here is how <CODE>libgcj</CODE> checks for <CODE>inet_aton</CODE> or<CODE>inet_addr</CODE>; it only uses the first one found:</P><P><TABLE width=100%><tr><td> </td><td class=example bgcolor=#6688aa><br><pre>AC_CHECK_FUNCS(inet_aton inet_addr, break)</pre></td></tr></table></P><P>Code to use the results of these checks looks something like:</P><P><TABLE width=100%><tr><td> </td><td class=example bgcolor=#6688aa><br><pre>#if HAVE_INET_ATON ... use inet_aton here#else#if HAVE_INET_ADDR ... use inet_addr here#else#error Function missing!#endif#endif</pre></td></tr></table></P><P>Note how we've made it a compile-time error if the function does notexist. In general it is best to make errors occur as early as possiblein the build process.</P><P>The third approach to non-portable functions is to write code such thatthese functions are only optionally used. For instance, if you arewriting an editor you might decide to use <CODE>mmap</CODE> to map a file intothe editor's memory. However, since <CODE>mmap</CODE> is not portable, youwould also write a function to use the more portable <CODE>read</CODE>.</P><P>Handling known non-portable functions is only part of the problem,however. The pragmatic approach works fairly well, but it is somewhatinefficient if you are primarily developing on a more modern system,like GNU/Linux, which has few functions missing. In this case theproblem is that you might not notice non-portable constructs in yourcode until it has largely been finished.</P><P>Unfortunately, there's no high road to solving this problem. In theend, you need to have a working knowledge of the range of existing Unixsystems. Knowledge of standards such as POSIX and XPG can be usefulhere, as a first cut -- if it isn't in POSIX, you should at leastconsider checking for it. However, standards are not a panacea -- notall systems are POSIX compliant, and sometimes there are bugs in systemsfunctions which you must work around.</P><P>One final class of problems you might encounter is that it is also easyto check for too much. This is bad because it adds unnecessarymaintenance burden to your program. For instance, sometimes you'll seecode that checks for <CODE><sys/types.h></CODE>. However, there's no point indoing that -- using this header is mostly portable. Again, this canonly be addressed by having a practical knowledge, which is only reallypossible by examining your target systems.</P><P><A NAME="Using Configuration Names"></A></TR></TABLE><BR> <FONT SIZE="-1">This document was generatedby <I>Gary V. Vaughan</I> on <I>September, 12 2004</I>using <A HREF="http://www.mathematik.uni-kl.de/~obachman/Texi2html"><I>texi2html</I></A></BODY></HTML>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -