mirror of
git://git.sv.gnu.org/autoconf
synced 2025-01-18 10:45:15 +08:00
doc cleanups
This commit is contained in:
David MacKenzie
parent
e7763fa443
commit
697fe9e8d9
@ -1589,14 +1589,15 @@ for ac_file in .. ${CONFIG_HEADERS}; do if test "x$ac_file" != x..; then
|
||||
EOF
|
||||
|
||||
# Transform confdefs.h into a sed script conftest.vals that substitutes
|
||||
# the proper values into config.h.in to produce config.h.
|
||||
# the proper values into config.h.in to produce config.h. And first:
|
||||
# Protect against being on the right side of a sed subst in config.status.
|
||||
# Protect against being in an unquoted here document in config.status.
|
||||
rm -f conftest.vals
|
||||
dnl Using a here document instead of a string reduces the quoting nightmare.
|
||||
dnl Putting comments in sed scripts is not portable.
|
||||
cat > conftest.hdr <<\EOF
|
||||
changequote(<<, >>)dnl
|
||||
# Protect against being on the right side of a sed subst in config.status.
|
||||
s/[\\&%]/\\&/g
|
||||
# Protect against being in an unquoted here document in config.status.
|
||||
s%[\\$`]%\\&%g
|
||||
s%<<#define>> \([A-Za-z_][A-Za-z0-9_]*\) \(.*\)%${ac_dA}\1${ac_dB}\1${ac_dC}\2${ac_dD}%gp
|
||||
s%ac_d%ac_u%gp
|
||||
|
||||
@ -652,7 +652,7 @@ AC_CACHE_VAL(ac_cv_func_mmap,
|
||||
#endif
|
||||
|
||||
#ifdef __cplusplus
|
||||
extern "C" { char *valloc(int), *malloc(int); }
|
||||
extern "C" { void *valloc(unsigned), *malloc(unsigned); }
|
||||
#else
|
||||
char *valloc(), *malloc();
|
||||
#endif
|
||||
@ -665,9 +665,9 @@ main()
|
||||
int i2 = getpagesize()*2;
|
||||
int fd;
|
||||
|
||||
buf1 = valloc(i2);
|
||||
buf2 = valloc(i);
|
||||
buf3 = malloc(i2);
|
||||
buf1 = (char *)valloc(i2);
|
||||
buf2 = (char *)valloc(i);
|
||||
buf3 = (char *)malloc(i2);
|
||||
for (j = 0; j < i2; ++j)
|
||||
*(buf1 + j) = rand();
|
||||
fd = open("conftestmmap", O_CREAT | O_RDWR, 0666);
|
||||
@ -1643,10 +1643,11 @@ else
|
||||
[X_EXTRA_LIBS="$X_EXTRA_LIBS -ldnet_stub"])
|
||||
fi
|
||||
|
||||
# msh@cis.ufl.edu says -lnsl (and -lsocket) are needed for his 386/AT.
|
||||
# msh@cis.ufl.edu says -lnsl (and -lsocket) are needed for his 386/AT,
|
||||
# to get the SysV transport functions.
|
||||
# Not sure which flavor of 386 Unix this is, but it seems harmless to
|
||||
# check for it.
|
||||
AC_CHECK_LIB(nsl, main, [X_EXTRA_LIBS="$X_EXTRA_LIBS -lnsl"])
|
||||
AC_CHECK_LIB(nsl, t_accept, [X_EXTRA_LIBS="$X_EXTRA_LIBS -lnsl"])
|
||||
|
||||
# lieder@skyler.mavd.honeywell.com says without -lsocket,
|
||||
# socket/setsockopt and other routines are undefined under SCO ODT 2.0.
|
||||
|
||||
263
autoconf.texi
263
autoconf.texi
@ -269,15 +269,10 @@ place; all of the the configuration scripts can be regenerated
|
||||
automatically to take advantage of the updated code.
|
||||
|
||||
Larry Wall's Metaconfig package is similar in purpose to Autoconf, but
|
||||
is more general. The scripts it produces require manual user
|
||||
intervention, which is quite inconvenient when configuring large source
|
||||
trees.
|
||||
|
||||
Unlike Metaconfig scripts, Autoconf scripts can support cross-compiling,
|
||||
if some care is taken in writing them. They should avoid executing test
|
||||
programs, since test programs compiled with a cross-compiler can not be
|
||||
executed on the host system. Also, they shouldn't do anything that
|
||||
tests features of the host system instead of the target system.
|
||||
the scripts it produces require manual user intervention, which is quite
|
||||
inconvenient when configuring large source trees. Unlike Metaconfig
|
||||
scripts, Autoconf scripts can support cross-compiling, if some care is
|
||||
taken in writing them.
|
||||
|
||||
Autoconf imposes some restrictions on the names of macros used with
|
||||
@code{#ifdef} in C programs (@pxref{Preprocessor Symbol Index}).
|
||||
@ -327,10 +322,10 @@ compilers, to help debugging if @code{configure} makes a mistake.
|
||||
@end itemize
|
||||
|
||||
To create a @code{configure} script with Autoconf, you need to write an
|
||||
Autoconf input file (@file{configure.in}) and run Autoconf on it to
|
||||
produce the script. If you write your own feature tests to supplement
|
||||
those that come with Autoconf, you might also write a file called
|
||||
@file{aclocal.m4}. If you use a C header file to contain @code{#define}
|
||||
Autoconf input file @file{configure.in} and run @code{autoconf} on it.
|
||||
If you write your own feature tests to supplement those that come with
|
||||
Autoconf, you might also write files called @file{aclocal.m4} and
|
||||
@file{acsite.m4}. If you use a C header file to contain @code{#define}
|
||||
directives, you might also write @file{acconfig.h}, @file{config.h.top},
|
||||
and @file{config.h.bot}, and you will distribute the Autoconf-generated
|
||||
file @file{config.h.in} with the package.
|
||||
@ -365,7 +360,9 @@ Makefile.in -------------------------------> Makefile.in
|
||||
Files used in configuring a software package:
|
||||
@example
|
||||
@group
|
||||
configure* ------------.
|
||||
configure* ------------+-------------> config.cache
|
||||
|
|
||||
+-------------> config.log
|
||||
|
|
||||
[config.h.in] -. v .-> [config.h] -.
|
||||
+--> config.status* -+ +--> make*
|
||||
@ -527,7 +524,7 @@ the Autoconf version number and exits, and @code{--help}, which prints a
|
||||
summary of the command-line options and exits.
|
||||
|
||||
@node Invoking autoscan, Invoking ifnames, Invoking autoheader, Making configure Scripts
|
||||
@section Invoking autoscan
|
||||
@section Invoking @code{autoscan}
|
||||
|
||||
The @code{autoscan} program can help you create a @file{configure.in}
|
||||
file for a software package. @code{autoscan} examines source files in
|
||||
@ -539,9 +536,9 @@ that package. You should manually examine @file{configure.scan} before
|
||||
renaming it to @file{configure.in}; it will probably need some
|
||||
adjustments. If you want the package to use a configuration header
|
||||
file, you will have to add a call to @code{AC_CONFIG_HEADER}. You might
|
||||
have to change or add some @code{#if} directives in order to make the
|
||||
package work with Autoconf (@pxref{Invoking ifnames}, for information
|
||||
about a program that might help with that job).
|
||||
have to change or add some @code{#if} directives to your program in
|
||||
order to make it work with Autoconf (@pxref{Invoking ifnames}, for
|
||||
information about a program that might help with that job).
|
||||
|
||||
@code{autoscan} uses several data files, which are installed with the
|
||||
distributed Autoconf macro files, to determine which macros to output
|
||||
@ -571,13 +568,13 @@ Print the version number of @code{autoscan} and exit.
|
||||
@end table
|
||||
|
||||
@node Invoking ifnames, Invoking autoreconf, Invoking autoscan, Making configure Scripts
|
||||
@section Invoking ifnames
|
||||
@section Invoking @code{ifnames}
|
||||
|
||||
@code{ifnames} can help when writing a @file{configure.in} for a
|
||||
software package. It prints the identifiers used in C preprocessor
|
||||
conditionals. If a package has already been set up to have some
|
||||
portability, this program can help you figure out what its
|
||||
@code{configure} needs to check for. It may fill in some gaps in a
|
||||
@code{configure} needs to check for. It may help fill in some gaps in a
|
||||
@file{configure.in} generated by @code{autoscan} (@pxref{Invoking autoscan}).
|
||||
|
||||
@code{ifnames} scans all of the C source files named on the command line
|
||||
@ -603,7 +600,7 @@ Print the version number of @code{ifnames} and exit.
|
||||
@end table
|
||||
|
||||
@node Invoking autoreconf, Invoking autoupdate, Invoking ifnames, Making configure Scripts
|
||||
@section Invoking autoreconf
|
||||
@section Invoking @code{autoreconf}
|
||||
|
||||
If you have a lot of Autoconf-generated @code{configure} scripts and you
|
||||
get a new version of Autoconf, the @code{autoreconf} program can be
|
||||
@ -632,7 +629,7 @@ Print the version number of @code{autoreconf} and exit.
|
||||
@end table
|
||||
|
||||
@node Invoking autoupdate, , Invoking autoreconf, Making configure Scripts
|
||||
@section Invoking autoupdate
|
||||
@section Invoking @code{autoupdate}
|
||||
|
||||
The @code{autoupdate} program updates a @file{configure.in} file that
|
||||
calls Autoconf macros by their old names to use the current macro names.
|
||||
@ -680,7 +677,8 @@ general purpose test macros with appropriate arguments (@pxref{General
|
||||
Purpose Macros}).
|
||||
|
||||
All of these macros that set @code{make} variables call @code{AC_SUBST}
|
||||
on those variables (@pxref{Setting Variables}, for details about
|
||||
on those variables to insert them into the output @file{Makefile} files
|
||||
(@pxref{Setting Variables}, for details about
|
||||
@code{AC_SUBST}). The phrase ``define @var{name}'' is used below as a
|
||||
shorthand to mean either add @samp{-D@var{name}=1} to the @code{make}
|
||||
variable @code{DEFS}, or put @samp{#define @var{name} 1} in the
|
||||
@ -708,7 +706,8 @@ what existing GNU programs use. These macros are defined in the file
|
||||
@section Alternative Programs
|
||||
|
||||
The following macros check for the presence or behavior of particular
|
||||
programs:
|
||||
programs. @xref{File Existence}, for how to check for programs not
|
||||
listed here.
|
||||
|
||||
@defmac AC_DECL_YYTEXT
|
||||
@maindex DECL_YYTEXT
|
||||
@ -765,7 +764,7 @@ been called already.
|
||||
@defmac AC_PROG_CXX
|
||||
@maindex PROG_CXX
|
||||
Determine a C++ compiler to use. Check if the environment variable
|
||||
@var{CXX} or @var{CCC} (in that order) is set; if so, set @code{make}
|
||||
@code{CXX} or @code{CCC} (in that order) is set; if so, set @code{make}
|
||||
variable @code{CXX} to its value. Otherwise search for a C++ compiler
|
||||
under likely names (@code{c++}, @code{g++}, @code{gcc}, @code{CC}, and
|
||||
@code{cxx}). If none of those checks succeed, as a last resort set
|
||||
@ -794,21 +793,24 @@ this macro first if it hasn't been called already. This macro calls
|
||||
@maindex PROG_GCC_TRADITIONAL
|
||||
Add @samp{-traditional} to @code{make} variable @code{CC} if using the
|
||||
GNU C compiler and @code{ioctl} does not work properly without
|
||||
@samp{-traditional}. This macro calls @code{AC_PROG_CC} and
|
||||
@code{AC_PROG_CPP} if they haven't been called already.
|
||||
@samp{-traditional}. That usually happens when the fixed header files
|
||||
have not been installed on an old system. Since recent versions of the
|
||||
GNU C compiler fix the header files automatically when installed, this
|
||||
is becoming a less prevalent problem. This macro calls
|
||||
@code{AC_PROG_CC} and @code{AC_PROG_CPP} if they haven't been called
|
||||
already.
|
||||
@end defmac
|
||||
|
||||
@defmac AC_PROG_INSTALL
|
||||
@maindex PROG_INSTALL
|
||||
Set @code{make} variable @code{INSTALL} to @samp{install -c} if
|
||||
@code{install} is found and is compatible with the BSD and GNU versions.
|
||||
Set @code{make} variable @code{INSTALL} to the path of a BSD compatible
|
||||
@code{install} program, if one is found in the current @code{PATH}.
|
||||
Otherwise, set @code{INSTALL} to @samp{@var{dir}/install.sh -c}, where
|
||||
it checks the directories specified to @code{AC_CONFIG_AUX_DIR} (or its
|
||||
default directories) to determine @var{dir} (@pxref{Setup}).
|
||||
|
||||
This macro screens out the false matches @file{/etc/install},
|
||||
@file{/usr/sbin/install}, and other instances of @code{install} known
|
||||
not to work. It also sets the variable @code{INSTALL_PROGRAM} to
|
||||
This macro screens out various instances of @code{install} known to not
|
||||
work. It also sets the variable @code{INSTALL_PROGRAM} to
|
||||
@samp{$@{INSTALL@}} and @code{INSTALL_DATA} to @samp{$@{INSTALL@} -m
|
||||
644}.
|
||||
|
||||
@ -869,7 +871,8 @@ to @samp{byacc}. Otherwise set @code{YACC} to @samp{yacc}.
|
||||
@node Header Files, Typedefs, Alternative Programs, Specific Tests
|
||||
@section Header Files
|
||||
|
||||
The following macros check for the presence of certain C header files:
|
||||
The following macros check for the presence of certain C header files.
|
||||
@xref{C Features}, for how to check for header files not listed here.
|
||||
|
||||
@defmac AC_DECL_SYS_SIGLIST
|
||||
@maindex DECL_SYS_SIGLIST
|
||||
@ -1001,37 +1004,39 @@ the system has ANSI-compliant header files (and probably C library
|
||||
functions) because many systems that have GCC do not have ANSI C header
|
||||
files.
|
||||
|
||||
To check whether to use the System V/ANSI C string functions and header
|
||||
file, you can put the following in @file{configure.in}:
|
||||
On systems without ANSI C headers, there is so much variation that it is
|
||||
probably easier to declare the functions you use than to figure out
|
||||
exactly what the system header files declare. Some systems contain a
|
||||
mix of functions ANSI and BSD; some are mostly ANSI but lack
|
||||
@samp{memmove}; some define the BSD functions as macros in
|
||||
@file{string.h} or @file{strings.h}; some have only the BSD functions
|
||||
but @file{string.h}; some declare the memory functions in
|
||||
@file{memory.h}, some in @file{string.h}; etc. It is probably
|
||||
sufficient to check for one string function and one memory function; if
|
||||
the library has the ANSI versions of those then it probably has most of
|
||||
the others. If you put the following in @file{configure.in}:
|
||||
|
||||
@example
|
||||
AC_HEADER_STDC
|
||||
AC_CHECK_HEADERS(string.h memory.h)
|
||||
AC_CHECK_FUNCS(strchr memcpy)
|
||||
@end example
|
||||
|
||||
@noindent
|
||||
Then, in the code, use a test like this:
|
||||
then, in your code, you can put declarations like this:
|
||||
|
||||
@example
|
||||
@group
|
||||
/* memory.h might conflict with an ANSI string.h, or strings.h. */
|
||||
#if STDC_HEADERS || HAVE_STRING_H
|
||||
#if STDC_HEADERS
|
||||
# include <string.h>
|
||||
# if !STDC_HEADERS && HAVE_MEMORY_H
|
||||
# include <memory.h>
|
||||
# endif
|
||||
#else
|
||||
# include <strings.h>
|
||||
# ifndef strchr
|
||||
# ifndef HAVE_STRCHR
|
||||
# define strchr index
|
||||
# endif
|
||||
# ifndef strrchr
|
||||
# define strrchr rindex
|
||||
# endif
|
||||
# ifndef memcpy
|
||||
char *strchr (), *strrchr ();
|
||||
# ifndef HAVE_MEMCPY
|
||||
# define memcpy(d, s, n) bcopy ((s), (d), (n))
|
||||
# endif
|
||||
# ifndef memcmp
|
||||
# define memmove(d, s, n) bcopy ((s), (d), (n))
|
||||
# define memcmp(s1, s2, n) bcmp ((s1), (s2), (n))
|
||||
# endif
|
||||
#endif
|
||||
@ -1039,10 +1044,13 @@ Then, in the code, use a test like this:
|
||||
@end example
|
||||
|
||||
@noindent
|
||||
This example asssumes that your code uses the ANSI C/System V style
|
||||
functions. If you use the BSD style functions, replace the macro
|
||||
definitions with ones that go in the other direction. (Or, better,
|
||||
modernize your code.)
|
||||
If you use a function like @code{memchr}, @code{memset}, @code{strtok},
|
||||
or @code{strspn}, which have no BSD equivalent, then macros won't
|
||||
suffice; you must provide an implementation of each function. An easy
|
||||
way to incorporate your implementations only when needed (since the ones
|
||||
in system C libraries may be hand optimized) is to, taking @code{memchr}
|
||||
for example, put it in @file{memchr.c} and use
|
||||
@samp{AC_REPLACE_FUNCS(memchr)}.
|
||||
|
||||
This macro calls @code{AC_PROG_CPP} or @code{AC_PROG_CXXCPP} (depending
|
||||
on which language is current, @pxref{Language Choice}), if it hasn't
|
||||
@ -1100,7 +1108,8 @@ code. See the example for @code{AC_HEADER_STDC}.
|
||||
@node Typedefs, Library Functions, Header Files, Specific Tests
|
||||
@section Typedefs
|
||||
|
||||
The following macros check for predefined C types:
|
||||
The following macros check for predefined C types.
|
||||
@xref{C Features}, for how to check for types not listed here.
|
||||
|
||||
@defmac AC_TYPE_GETGROUPS
|
||||
@maindex TYPE_GETGROUPS
|
||||
@ -1168,7 +1177,8 @@ If @code{uid_t} is not defined in @file{sys/types.h}, define
|
||||
@node Library Functions, Structures, Typedefs, Specific Tests
|
||||
@section Library Functions
|
||||
|
||||
The following macros check for particular C library functions:
|
||||
The following macros check for particular C library functions.
|
||||
@xref{C Features}, for how to check for functions not listed here.
|
||||
|
||||
@defmac AC_FUNC_ALLOCA
|
||||
@maindex FUNC_ALLOCA
|
||||
@ -1330,7 +1340,9 @@ If @code{wait3} is found and fills in the contents of its third argument
|
||||
@node Structures, Compiler Characteristics, Library Functions, Specific Tests
|
||||
@section Structures
|
||||
|
||||
The following macros check for certain structures or structure members:
|
||||
The following macros check for certain structures or structure members.
|
||||
You can use @code{AC_TRY_LINK} (@pxref{C System Output}) to check
|
||||
structures not listed here.
|
||||
|
||||
@defmac AC_HEADER_STAT
|
||||
@maindex HEADER_STAT
|
||||
@ -1411,7 +1423,8 @@ macro calls @code{AC_STRUCT_TM} if it hasn't been called already.
|
||||
@section Compiler Characteristics
|
||||
|
||||
The following macros check for C compiler or machine architecture
|
||||
features:
|
||||
features. You can use @code{AC_TRY_LINK} or @code{AC_TRY_RUN} (@pxref{C
|
||||
System Output}) to check for characteristics not listed here.
|
||||
|
||||
@defmac AC_C_BIGENDIAN
|
||||
@maindex C_BIGENDIAN
|
||||
@ -1488,7 +1501,7 @@ that define @code{__STDC__} do not support @code{long double}.
|
||||
@node System Services, UNIX Variants, Compiler Characteristics, Specific Tests
|
||||
@section System Services
|
||||
|
||||
The following macros check for operating system services:
|
||||
The following macros check for operating system services or capabilities.
|
||||
|
||||
@defmac AC_SYS_INTERPRETER
|
||||
@maindex SYS_INTERPRETER
|
||||
@ -1510,7 +1523,7 @@ variables @code{x_includes} and @code{x_libraries} to their locations,
|
||||
unless they are in directories the compiler searches by default.
|
||||
|
||||
If both methods fail, or the user gave the command line option
|
||||
@samp{--without-x}, set the shell variable @code{no_x} to @samp{true};
|
||||
@samp{--without-x}, set the shell variable @code{no_x} to @samp{yes};
|
||||
otherwise set it to the empty string.
|
||||
|
||||
The command line options @samp{--x-includes=@var{dir}} and
|
||||
@ -1908,7 +1921,8 @@ results (@pxref{C Features}).
|
||||
@defmac AC_COMPILE_CHECK (@var{echo-text}, @var{includes}, @var{function-body}, @var{action-if-found} @r{[}, @var{action-if-not-found}@r{]})
|
||||
@maindex COMPILE_CHECK
|
||||
This is an obsolete alias for @code{AC_TRY_LINK}, with the addition that it
|
||||
prints @samp{checking for @var{echo-text}} to the standard output first.
|
||||
prints @samp{checking for @var{echo-text}} to the standard output first,
|
||||
if @var{echo-text} is non-empty.
|
||||
@end defmac
|
||||
|
||||
@defmac AC_EGREP_CPP (@var{pattern}, @var{program}, @var{action-if-found} @r{[}, @var{action-if-not-found}@r{]})
|
||||
@ -2096,7 +2110,7 @@ shell commands @var{action-if-true}. Otherwise run shell commands
|
||||
@var{action-if-false}. @var{help-string} is a description of
|
||||
the option which looks like this:
|
||||
@example
|
||||
--enable-readline support fancy command line editing
|
||||
--enable-editing support fancy command line editing
|
||||
@end example
|
||||
@noindent
|
||||
@var{help-string} may be more than one line long, if more detail is
|
||||
@ -2190,8 +2204,9 @@ set @var{variable} to that value (verbatim), otherwise set it to 1.
|
||||
@var{value} should not contain literal newlines, and if you are not
|
||||
using @code{AC_CONFIG_HEADER} it should not contain any @samp{#}
|
||||
characters, as @code{make} tends to eat them. To use a shell variable
|
||||
or a value containing the @code{m4} quote characters @samp{[} or
|
||||
@samp{]}, use @code{AC_DEFINE_UNQUOTED} instead.
|
||||
(which you need to do in order to define a value containing the
|
||||
@code{m4} quote characters @samp{[} or @samp{]}), use
|
||||
@code{AC_DEFINE_UNQUOTED} instead.
|
||||
|
||||
@code{AC_OUTPUT} substitutes the values defined by this macro as the
|
||||
variable @code{DEFS} in the file(s) that it generates (typically
|
||||
@ -2265,7 +2280,7 @@ AC_CHECK_HEADER(elf.h, AC_DEFINE(SVR4); LIBS="$LIBS -lelf")
|
||||
Like @code{AC_DEFINE}, but three shell expansions are performed once on
|
||||
@var{value}: variable expansion (@samp{$}), command substitution
|
||||
(@samp{`}), and backslash escaping (@samp{\}). Use this macro instead
|
||||
of @code{AC_DEFINE} when @var{value} contains a shell variable. For
|
||||
of @code{AC_DEFINE} when @var{value} is a shell variable. For
|
||||
example:
|
||||
|
||||
@example
|
||||
@ -2392,9 +2407,10 @@ make hard links}.
|
||||
|
||||
@defmac AC_VERBOSE (@var{result-description})
|
||||
@maindex VERBOSE
|
||||
This macro is similar to @code{AC_MSG_RESULT}, except that it is meant to
|
||||
follow a call to @code{AC_CHECKING} instead of @code{AC_MSG_CHECKING}.
|
||||
It is considered obsolete.
|
||||
This macro is similar to @code{AC_MSG_RESULT}, except that it is meant
|
||||
to follow a call to @code{AC_CHECKING} instead of
|
||||
@code{AC_MSG_CHECKING}; it starts the message it prints with a tab. It
|
||||
is considered obsolete.
|
||||
@end defmac
|
||||
|
||||
@node Language Choice, Macro Ordering, Printing Messages, General Purpose Macros
|
||||
@ -2543,7 +2559,7 @@ Autoconf provides a uniform method for handling unguessable features.
|
||||
@end menu
|
||||
|
||||
@node Specifying Names, Canonicalizing, , Manual Configuration
|
||||
@section Specifying The System Type
|
||||
@section Specifying the System Type
|
||||
|
||||
Like other GNU @code{configure} scripts, Autoconf-generated
|
||||
@code{configure} scripts can make decisions based on a canonical name
|
||||
@ -2566,7 +2582,7 @@ system types are involved. The options to specify them are:
|
||||
@table @code
|
||||
@item --build=@var{build-type}
|
||||
the type of system on which the package is being configured and
|
||||
compiled;
|
||||
compiled (rarely needed);
|
||||
|
||||
@item --host=@var{host-type}
|
||||
the type of system on which the package will run;
|
||||
@ -2595,7 +2611,7 @@ example, @samp{decstation} can be given on the command line instead of
|
||||
@code{config.sub} to canonicalize system type aliases.
|
||||
|
||||
@node Canonicalizing, System Name Variables, Specifying Names, Manual Configuration
|
||||
@section Getting The Canonical System Type
|
||||
@section Getting the Canonical System Type
|
||||
|
||||
The following macros make the name of the system type available in
|
||||
@code{configure} scripts.
|
||||
@ -2624,7 +2640,8 @@ given to it.
|
||||
@node System Name Variables, Using System Type, Canonicalizing, Manual Configuration
|
||||
@section System Name Variables
|
||||
|
||||
The shell and @code{make} variables that contain the system type
|
||||
After calling @code{AC_CANONICAL_SYSTEM} or @code{AC_CANONICAL_HOST},
|
||||
the the shell and @code{make} variables that contain the system type
|
||||
information are:
|
||||
|
||||
@table @code
|
||||
@ -2642,7 +2659,7 @@ the individual parts of the canonical names (for convenience).
|
||||
@end table
|
||||
|
||||
@node Using System Type, , System Name Variables, Manual Configuration
|
||||
@section Using The System Type
|
||||
@section Using the System Type
|
||||
|
||||
How do you use a canonical system type? Usually, you use it in one or
|
||||
more @code{case} statements in @file{configure.in} to select
|
||||
@ -2819,8 +2836,9 @@ many of the macros use @samp{`} and @samp{'}, mismatched. However, in a
|
||||
few places the macros need to use brackets (usually in C program text or
|
||||
regular expressions). In those places, they use the @code{m4} builtin
|
||||
command @code{changequote} to temporarily change the quote characters to
|
||||
@samp{<<} and @samp{>>}. Sometimes, if they don't need to quote
|
||||
anything, they disable quoting entirely instead. Here is an example:
|
||||
@samp{<<} and @samp{>>}. (Sometimes, if they don't need to quote
|
||||
anything, they disable quoting entirely instead by setting the quote
|
||||
characters to empty strings.) Here is an example:
|
||||
|
||||
@example
|
||||
AC_TRY_LINK(
|
||||
@ -2987,7 +3005,15 @@ prevents people from configuring your package for cross-compiling. If
|
||||
it's really best that you test for a run-time behavior, try to provide a
|
||||
default ``worst case'' value to use when cross-compiling makes run-time
|
||||
tests impossible. You do this by passing the optional last argument to
|
||||
@code{AC_TRY_RUN}.
|
||||
@code{AC_TRY_RUN}. To configure for cross-compiling you can also set up
|
||||
a test results cache file with the correct values for the target system
|
||||
(@pxref{Caching Values}). But that is a last resort. Alternatively,
|
||||
choose a value for those parameters based on the canonical system name
|
||||
(@pxref{Manual Configuration}).
|
||||
|
||||
To enable @code{configure} scripts to support cross-compilation, they
|
||||
shouldn't do anything that tests features of the host system instead of
|
||||
the target system.
|
||||
|
||||
@menu
|
||||
* Guidelines:: General rules for writing test programs.
|
||||
@ -3021,7 +3047,7 @@ include any header files containing clashing prototypes.
|
||||
|
||||
@example
|
||||
#ifdef __cplusplus
|
||||
extern "C" char *malloc(int);
|
||||
extern "C" void *malloc(size_t);
|
||||
#else
|
||||
char *malloc();
|
||||
#endif
|
||||
@ -3113,18 +3139,19 @@ it had to perform all of the checks every time.
|
||||
Ensure that the results of the check identified by @var{cache-id} are
|
||||
available. If the results of the check were in the cache file that was
|
||||
read, and @code{configure} was not given the @samp{--quiet} or
|
||||
@samp{--silent} option, print a message saying so; otherwise, run the
|
||||
shell commands @var{commands-to-set-it}. Those commands should have no
|
||||
side effects except for setting the variable @var{cache-id}. In
|
||||
particular, they should not call @code{AC_DEFINE}; the code that follows
|
||||
the call to @code{AC_CACHE_VAL} should do that, based on the cached
|
||||
value. Also, they should not print any messages, for example with
|
||||
@code{AC_MSG_CHECKING}; do that before calling @code{AC_CACHE_VAL}, so
|
||||
the messages are printed regardless of whether the results of the check
|
||||
are retrieved from the cache or determined by running the shell
|
||||
commands. If the shell commands are run to determine the value, the
|
||||
value will be saved in the cache file just before @code{configure}
|
||||
creates its output files.
|
||||
@samp{--silent} option, print a message saying that the result was
|
||||
cached; otherwise, run the shell commands @var{commands-to-set-it}.
|
||||
Those commands should have no side effects except for setting the
|
||||
variable @var{cache-id}. In particular, they should not call
|
||||
@code{AC_DEFINE}; the code that follows the call to @code{AC_CACHE_VAL}
|
||||
should do that, based on the cached value. Also, they should not print
|
||||
any messages, for example with @code{AC_MSG_CHECKING}; do that before
|
||||
calling @code{AC_CACHE_VAL}, so the messages are printed regardless of
|
||||
whether the results of the check are retrieved from the cache or
|
||||
determined by running the shell commands. If the shell commands are run
|
||||
to determine the value, the value will be saved in the cache file just
|
||||
before @code{configure} creates its output files. @xref{Cache
|
||||
Variables}, for how to choose the name of the @var{cache-id} variable.
|
||||
@end defmac
|
||||
|
||||
@menu
|
||||
@ -3135,7 +3162,7 @@ creates its output files.
|
||||
@node Cache Files, Cache Variables, , Caching Values
|
||||
@section Cache Files
|
||||
|
||||
The cache file is a shell script that caches the results of configure
|
||||
A cache file is a shell script that caches the results of configure
|
||||
tests run on one system so they can be shared between configure scripts
|
||||
and configure runs. It is not useful on other systems. If its contents
|
||||
are invalid for some reason, the user may delete or edit it.
|
||||
@ -3163,7 +3190,8 @@ someone runs a @code{configure} script; it will be initially
|
||||
nonexistent. Running @code{configure} merges the new cache results with
|
||||
the existing cache file. The site initialization script can specify a
|
||||
site-wide cache file to use instead of the default, to make it work
|
||||
transparently (@pxref{Site Default Values}).
|
||||
transparently, as long as the same C compiler is used every time
|
||||
(@pxref{Site Default Values}).
|
||||
|
||||
@node Cache Variables, , Cache Files, Caching Values
|
||||
@section Cache Variables
|
||||
@ -3271,8 +3299,8 @@ directory, this is the same as @code{srcdir}.
|
||||
@defvar CFLAGS
|
||||
Debugging and optimization options for the C compiler. If it is not set
|
||||
in the environment when @code{configure} runs, the default value is set
|
||||
by @code{AC_PROG_CC} (empty if you don't). @code{configure} uses this
|
||||
variable when compiling programs to test for C features.
|
||||
when you call @code{AC_PROG_CC} (or empty if you don't). @code{configure}
|
||||
uses this variable when compiling programs to test for C features.
|
||||
@end defvar
|
||||
|
||||
@defvar CPPFLAGS
|
||||
@ -3286,8 +3314,9 @@ preprocessing programs to test for C features.
|
||||
@defvar CXXFLAGS
|
||||
Debugging and optimization options for the C++ compiler. If it is not
|
||||
set in the environment when @code{configure} runs, the default value is
|
||||
set by @code{AC_PROG_CXX} (empty if you don't). @code{configure} uses
|
||||
this variable when compiling programs to test for C++ features.
|
||||
set when you call @code{AC_PROG_CXX} (or empty if you don't).
|
||||
@code{configure} uses this variable when compiling programs to test for
|
||||
C++ features.
|
||||
@end defvar
|
||||
|
||||
@defvar DEFS
|
||||
@ -3438,11 +3467,13 @@ You can give @file{config.status} the @samp{--recheck} option to update
|
||||
itself. This option is useful if you change @code{configure}, so that
|
||||
the results of some tests might be different from the previous run. The
|
||||
@samp{--recheck} option re-runs @code{configure} with the same arguments
|
||||
you used before, plus the @samp{--no-create} option, which prevents
|
||||
you used before, plus the @samp{--no-create} option, which prevent
|
||||
@code{configure} from running @file{config.status} and creating
|
||||
@file{Makefile} and other files. (This is so other @file{Makefile}
|
||||
rules can run @file{config.status} when it changes; @pxref{Automatic
|
||||
Remaking}, for an example).
|
||||
@file{Makefile} and other files, and the @samp{--norecursion} option,
|
||||
which prevents @code{configure} from running other @code{configure}
|
||||
scripts in subdirectories. (This is so other @file{Makefile} rules can
|
||||
run @file{config.status} when it changes; @pxref{Automatic Remaking},
|
||||
for an example).
|
||||
|
||||
@file{config.status} also accepts the options @samp{--help}, which
|
||||
prints a summary of the options to @file{config.status}, and
|
||||
@ -3521,8 +3552,8 @@ separately for each architecture.
|
||||
If the environment variable @code{CONFIG_SITE} is set and contains the
|
||||
name of a readable file, @code{configure} reads that file as a shell
|
||||
script. Otherwise, it reads the shell script
|
||||
@file{@var{exec_prefix}/lib/config.site} if it exists, then
|
||||
@file{@var{prefix}/lib/config.site} if it exists. Thus, settings in
|
||||
@file{@var{prefix}/lib/config.site} if it exists, then
|
||||
@file{@var{exec_prefix}/lib/config.site} if it exists. Thus, settings in
|
||||
system dependent files override those in system independent ones in case
|
||||
of conflict. @code{configure} reads any cache file after it has read
|
||||
any site files. This way, the site file can define a default cache
|
||||
@ -3530,13 +3561,13 @@ file, to be shared between all Autoconf-generated @code{configure}
|
||||
scripts run on that system.
|
||||
|
||||
Site files can be arbitrary shell scripts, but only certain kinds of
|
||||
code are really appropriate to be in them. Besides a cache file, they
|
||||
are good places to set default values for other shell variables like
|
||||
@code{CC}, if you need to give them unusual values: anything you would
|
||||
normally do, repetitively, on the command line. If you use non-default
|
||||
values for @var{prefix} or @var{exec_prefix} (wherever you locate the
|
||||
site file), you can set them in the site file if you specify it with the
|
||||
@code{CONFIG_SITE} environment variable.
|
||||
code are really appropriate to be in them. Besides selecting a cache
|
||||
file, they are good places to set default values for other shell
|
||||
variables like @code{CC}, if you need to give them unusual values:
|
||||
anything you would normally do, repetitively, on the command line. If
|
||||
you use non-default values for @var{prefix} or @var{exec_prefix}
|
||||
(wherever you locate the site file), you can set them in the site file
|
||||
if you specify it with the @code{CONFIG_SITE} environment variable.
|
||||
|
||||
It is possible to set some cache values in the site file.
|
||||
If you are cross-compiling, it is impossible to check features that
|
||||
@ -3659,12 +3690,12 @@ information while configuring.
|
||||
|
||||
Autoconf version 2 is mostly backward compatible with version 1.
|
||||
However, it introduces better ways to do some things, and doesn't
|
||||
support some of the ugly things about version 1. So, depending on how
|
||||
support some of the ugly things in version 1. So, depending on how
|
||||
sophisticated your @file{configure.in} files are, you might have to do
|
||||
some manual work in order to upgrade to version 2. This chapter points
|
||||
out some problems to watch for when upgrading. Also, perhaps your
|
||||
@code{configure} scripts could benefit from some of the new features in
|
||||
version 2; see the @file{NEWS} file in the distribution for a summary.
|
||||
version 2.
|
||||
|
||||
@menu
|
||||
* Changed File Names:: Files you might rename.
|
||||
@ -3782,9 +3813,9 @@ fi
|
||||
@end example
|
||||
|
||||
If you were working around bugs in @code{AC_DEFINE_UNQUOTED} by adding
|
||||
backslashes, you probably need to remove them. It now works
|
||||
predictably, and does not treat quotes (except backquotes) specially.
|
||||
@xref{Setting Variables}.
|
||||
backslashes before quotes, you probably need to remove them. It now
|
||||
works predictably, and does not treat quotes (except backquotes)
|
||||
specially. @xref{Setting Variables}.
|
||||
|
||||
@node Changed Macro Writing, , Changed Results, Upgrading
|
||||
@section Changed Macro Writing
|
||||
@ -3816,7 +3847,7 @@ You may be wondering, Why was Autoconf originally written? How did it
|
||||
get into its present form? (Why does it look like gorilla spit?) If
|
||||
you're not wondering, then this chapter contains no information useful
|
||||
to you, and you might as well skip it. If you @emph{are} wondering,
|
||||
then let there be light.
|
||||
then let there be light@dots{}
|
||||
|
||||
@menu
|
||||
* Genesis:: Prehistory and naming of @code{configure}.
|
||||
@ -3878,7 +3909,7 @@ reads pieces of @file{configure.in} when run. But I didn't want to have
|
||||
to distribute all of the feature tests with every package, so I settled
|
||||
on having a different @code{configure} made from each
|
||||
@file{configure.in} by a preprocessor. That approach also offered more
|
||||
control and flexibility
|
||||
control and flexibility.
|
||||
|
||||
I looked briefly into using Larry Wall's Metaconfig program, but I
|
||||
decided not to for several reasons. The @code{Configure} scripts it
|
||||
@ -3936,7 +3967,7 @@ checks, great ideas, and bug fixes.
|
||||
@section Numbers
|
||||
|
||||
In July 1992, after months of alpha testing, I released Autoconf 1.0,
|
||||
and converted many of GNU packages to use it. I was surprised by how
|
||||
and converted many GNU packages to use it. I was surprised by how
|
||||
positive the reaction to it was. More people started using it than I
|
||||
could keep track of, including people working on software that wasn't
|
||||
part of the GNU Project (such as TCL, FSP, @TeX{}, and Kerberos v5).
|
||||
@ -3947,7 +3978,7 @@ Autoconf turned out to be a good torture test for @code{m4}
|
||||
implementations. Unix @code{m4} started to dump core because of the
|
||||
length of the macros that Autoconf defined, and several bugs showed up
|
||||
in GNU @code{m4} as well. Eventually, we realized that we needed to use
|
||||
some features that only GNU @code{m4} has. BSD @code{m4}, in
|
||||
some features that only GNU @code{m4} has. 4.3BSD @code{m4}, in
|
||||
particular, has an impoverished set of builtin macros; the System V
|
||||
version is better, but still doesn't provide everything we need.
|
||||
|
||||
|
||||
@ -269,15 +269,10 @@ place; all of the the configuration scripts can be regenerated
|
||||
automatically to take advantage of the updated code.
|
||||
|
||||
Larry Wall's Metaconfig package is similar in purpose to Autoconf, but
|
||||
is more general. The scripts it produces require manual user
|
||||
intervention, which is quite inconvenient when configuring large source
|
||||
trees.
|
||||
|
||||
Unlike Metaconfig scripts, Autoconf scripts can support cross-compiling,
|
||||
if some care is taken in writing them. They should avoid executing test
|
||||
programs, since test programs compiled with a cross-compiler can not be
|
||||
executed on the host system. Also, they shouldn't do anything that
|
||||
tests features of the host system instead of the target system.
|
||||
the scripts it produces require manual user intervention, which is quite
|
||||
inconvenient when configuring large source trees. Unlike Metaconfig
|
||||
scripts, Autoconf scripts can support cross-compiling, if some care is
|
||||
taken in writing them.
|
||||
|
||||
Autoconf imposes some restrictions on the names of macros used with
|
||||
@code{#ifdef} in C programs (@pxref{Preprocessor Symbol Index}).
|
||||
@ -327,10 +322,10 @@ compilers, to help debugging if @code{configure} makes a mistake.
|
||||
@end itemize
|
||||
|
||||
To create a @code{configure} script with Autoconf, you need to write an
|
||||
Autoconf input file (@file{configure.in}) and run Autoconf on it to
|
||||
produce the script. If you write your own feature tests to supplement
|
||||
those that come with Autoconf, you might also write a file called
|
||||
@file{aclocal.m4}. If you use a C header file to contain @code{#define}
|
||||
Autoconf input file @file{configure.in} and run @code{autoconf} on it.
|
||||
If you write your own feature tests to supplement those that come with
|
||||
Autoconf, you might also write files called @file{aclocal.m4} and
|
||||
@file{acsite.m4}. If you use a C header file to contain @code{#define}
|
||||
directives, you might also write @file{acconfig.h}, @file{config.h.top},
|
||||
and @file{config.h.bot}, and you will distribute the Autoconf-generated
|
||||
file @file{config.h.in} with the package.
|
||||
@ -365,7 +360,9 @@ Makefile.in -------------------------------> Makefile.in
|
||||
Files used in configuring a software package:
|
||||
@example
|
||||
@group
|
||||
configure* ------------.
|
||||
configure* ------------+-------------> config.cache
|
||||
|
|
||||
+-------------> config.log
|
||||
|
|
||||
[config.h.in] -. v .-> [config.h] -.
|
||||
+--> config.status* -+ +--> make*
|
||||
@ -527,7 +524,7 @@ the Autoconf version number and exits, and @code{--help}, which prints a
|
||||
summary of the command-line options and exits.
|
||||
|
||||
@node Invoking autoscan, Invoking ifnames, Invoking autoheader, Making configure Scripts
|
||||
@section Invoking autoscan
|
||||
@section Invoking @code{autoscan}
|
||||
|
||||
The @code{autoscan} program can help you create a @file{configure.in}
|
||||
file for a software package. @code{autoscan} examines source files in
|
||||
@ -539,9 +536,9 @@ that package. You should manually examine @file{configure.scan} before
|
||||
renaming it to @file{configure.in}; it will probably need some
|
||||
adjustments. If you want the package to use a configuration header
|
||||
file, you will have to add a call to @code{AC_CONFIG_HEADER}. You might
|
||||
have to change or add some @code{#if} directives in order to make the
|
||||
package work with Autoconf (@pxref{Invoking ifnames}, for information
|
||||
about a program that might help with that job).
|
||||
have to change or add some @code{#if} directives to your program in
|
||||
order to make it work with Autoconf (@pxref{Invoking ifnames}, for
|
||||
information about a program that might help with that job).
|
||||
|
||||
@code{autoscan} uses several data files, which are installed with the
|
||||
distributed Autoconf macro files, to determine which macros to output
|
||||
@ -571,13 +568,13 @@ Print the version number of @code{autoscan} and exit.
|
||||
@end table
|
||||
|
||||
@node Invoking ifnames, Invoking autoreconf, Invoking autoscan, Making configure Scripts
|
||||
@section Invoking ifnames
|
||||
@section Invoking @code{ifnames}
|
||||
|
||||
@code{ifnames} can help when writing a @file{configure.in} for a
|
||||
software package. It prints the identifiers used in C preprocessor
|
||||
conditionals. If a package has already been set up to have some
|
||||
portability, this program can help you figure out what its
|
||||
@code{configure} needs to check for. It may fill in some gaps in a
|
||||
@code{configure} needs to check for. It may help fill in some gaps in a
|
||||
@file{configure.in} generated by @code{autoscan} (@pxref{Invoking autoscan}).
|
||||
|
||||
@code{ifnames} scans all of the C source files named on the command line
|
||||
@ -603,7 +600,7 @@ Print the version number of @code{ifnames} and exit.
|
||||
@end table
|
||||
|
||||
@node Invoking autoreconf, Invoking autoupdate, Invoking ifnames, Making configure Scripts
|
||||
@section Invoking autoreconf
|
||||
@section Invoking @code{autoreconf}
|
||||
|
||||
If you have a lot of Autoconf-generated @code{configure} scripts and you
|
||||
get a new version of Autoconf, the @code{autoreconf} program can be
|
||||
@ -632,7 +629,7 @@ Print the version number of @code{autoreconf} and exit.
|
||||
@end table
|
||||
|
||||
@node Invoking autoupdate, , Invoking autoreconf, Making configure Scripts
|
||||
@section Invoking autoupdate
|
||||
@section Invoking @code{autoupdate}
|
||||
|
||||
The @code{autoupdate} program updates a @file{configure.in} file that
|
||||
calls Autoconf macros by their old names to use the current macro names.
|
||||
@ -680,7 +677,8 @@ general purpose test macros with appropriate arguments (@pxref{General
|
||||
Purpose Macros}).
|
||||
|
||||
All of these macros that set @code{make} variables call @code{AC_SUBST}
|
||||
on those variables (@pxref{Setting Variables}, for details about
|
||||
on those variables to insert them into the output @file{Makefile} files
|
||||
(@pxref{Setting Variables}, for details about
|
||||
@code{AC_SUBST}). The phrase ``define @var{name}'' is used below as a
|
||||
shorthand to mean either add @samp{-D@var{name}=1} to the @code{make}
|
||||
variable @code{DEFS}, or put @samp{#define @var{name} 1} in the
|
||||
@ -708,7 +706,8 @@ what existing GNU programs use. These macros are defined in the file
|
||||
@section Alternative Programs
|
||||
|
||||
The following macros check for the presence or behavior of particular
|
||||
programs:
|
||||
programs. @xref{File Existence}, for how to check for programs not
|
||||
listed here.
|
||||
|
||||
@defmac AC_DECL_YYTEXT
|
||||
@maindex DECL_YYTEXT
|
||||
@ -765,7 +764,7 @@ been called already.
|
||||
@defmac AC_PROG_CXX
|
||||
@maindex PROG_CXX
|
||||
Determine a C++ compiler to use. Check if the environment variable
|
||||
@var{CXX} or @var{CCC} (in that order) is set; if so, set @code{make}
|
||||
@code{CXX} or @code{CCC} (in that order) is set; if so, set @code{make}
|
||||
variable @code{CXX} to its value. Otherwise search for a C++ compiler
|
||||
under likely names (@code{c++}, @code{g++}, @code{gcc}, @code{CC}, and
|
||||
@code{cxx}). If none of those checks succeed, as a last resort set
|
||||
@ -794,21 +793,24 @@ this macro first if it hasn't been called already. This macro calls
|
||||
@maindex PROG_GCC_TRADITIONAL
|
||||
Add @samp{-traditional} to @code{make} variable @code{CC} if using the
|
||||
GNU C compiler and @code{ioctl} does not work properly without
|
||||
@samp{-traditional}. This macro calls @code{AC_PROG_CC} and
|
||||
@code{AC_PROG_CPP} if they haven't been called already.
|
||||
@samp{-traditional}. That usually happens when the fixed header files
|
||||
have not been installed on an old system. Since recent versions of the
|
||||
GNU C compiler fix the header files automatically when installed, this
|
||||
is becoming a less prevalent problem. This macro calls
|
||||
@code{AC_PROG_CC} and @code{AC_PROG_CPP} if they haven't been called
|
||||
already.
|
||||
@end defmac
|
||||
|
||||
@defmac AC_PROG_INSTALL
|
||||
@maindex PROG_INSTALL
|
||||
Set @code{make} variable @code{INSTALL} to @samp{install -c} if
|
||||
@code{install} is found and is compatible with the BSD and GNU versions.
|
||||
Set @code{make} variable @code{INSTALL} to the path of a BSD compatible
|
||||
@code{install} program, if one is found in the current @code{PATH}.
|
||||
Otherwise, set @code{INSTALL} to @samp{@var{dir}/install.sh -c}, where
|
||||
it checks the directories specified to @code{AC_CONFIG_AUX_DIR} (or its
|
||||
default directories) to determine @var{dir} (@pxref{Setup}).
|
||||
|
||||
This macro screens out the false matches @file{/etc/install},
|
||||
@file{/usr/sbin/install}, and other instances of @code{install} known
|
||||
not to work. It also sets the variable @code{INSTALL_PROGRAM} to
|
||||
This macro screens out various instances of @code{install} known to not
|
||||
work. It also sets the variable @code{INSTALL_PROGRAM} to
|
||||
@samp{$@{INSTALL@}} and @code{INSTALL_DATA} to @samp{$@{INSTALL@} -m
|
||||
644}.
|
||||
|
||||
@ -869,7 +871,8 @@ to @samp{byacc}. Otherwise set @code{YACC} to @samp{yacc}.
|
||||
@node Header Files, Typedefs, Alternative Programs, Specific Tests
|
||||
@section Header Files
|
||||
|
||||
The following macros check for the presence of certain C header files:
|
||||
The following macros check for the presence of certain C header files.
|
||||
@xref{C Features}, for how to check for header files not listed here.
|
||||
|
||||
@defmac AC_DECL_SYS_SIGLIST
|
||||
@maindex DECL_SYS_SIGLIST
|
||||
@ -1001,37 +1004,39 @@ the system has ANSI-compliant header files (and probably C library
|
||||
functions) because many systems that have GCC do not have ANSI C header
|
||||
files.
|
||||
|
||||
To check whether to use the System V/ANSI C string functions and header
|
||||
file, you can put the following in @file{configure.in}:
|
||||
On systems without ANSI C headers, there is so much variation that it is
|
||||
probably easier to declare the functions you use than to figure out
|
||||
exactly what the system header files declare. Some systems contain a
|
||||
mix of functions ANSI and BSD; some are mostly ANSI but lack
|
||||
@samp{memmove}; some define the BSD functions as macros in
|
||||
@file{string.h} or @file{strings.h}; some have only the BSD functions
|
||||
but @file{string.h}; some declare the memory functions in
|
||||
@file{memory.h}, some in @file{string.h}; etc. It is probably
|
||||
sufficient to check for one string function and one memory function; if
|
||||
the library has the ANSI versions of those then it probably has most of
|
||||
the others. If you put the following in @file{configure.in}:
|
||||
|
||||
@example
|
||||
AC_HEADER_STDC
|
||||
AC_CHECK_HEADERS(string.h memory.h)
|
||||
AC_CHECK_FUNCS(strchr memcpy)
|
||||
@end example
|
||||
|
||||
@noindent
|
||||
Then, in the code, use a test like this:
|
||||
then, in your code, you can put declarations like this:
|
||||
|
||||
@example
|
||||
@group
|
||||
/* memory.h might conflict with an ANSI string.h, or strings.h. */
|
||||
#if STDC_HEADERS || HAVE_STRING_H
|
||||
#if STDC_HEADERS
|
||||
# include <string.h>
|
||||
# if !STDC_HEADERS && HAVE_MEMORY_H
|
||||
# include <memory.h>
|
||||
# endif
|
||||
#else
|
||||
# include <strings.h>
|
||||
# ifndef strchr
|
||||
# ifndef HAVE_STRCHR
|
||||
# define strchr index
|
||||
# endif
|
||||
# ifndef strrchr
|
||||
# define strrchr rindex
|
||||
# endif
|
||||
# ifndef memcpy
|
||||
char *strchr (), *strrchr ();
|
||||
# ifndef HAVE_MEMCPY
|
||||
# define memcpy(d, s, n) bcopy ((s), (d), (n))
|
||||
# endif
|
||||
# ifndef memcmp
|
||||
# define memmove(d, s, n) bcopy ((s), (d), (n))
|
||||
# define memcmp(s1, s2, n) bcmp ((s1), (s2), (n))
|
||||
# endif
|
||||
#endif
|
||||
@ -1039,10 +1044,13 @@ Then, in the code, use a test like this:
|
||||
@end example
|
||||
|
||||
@noindent
|
||||
This example asssumes that your code uses the ANSI C/System V style
|
||||
functions. If you use the BSD style functions, replace the macro
|
||||
definitions with ones that go in the other direction. (Or, better,
|
||||
modernize your code.)
|
||||
If you use a function like @code{memchr}, @code{memset}, @code{strtok},
|
||||
or @code{strspn}, which have no BSD equivalent, then macros won't
|
||||
suffice; you must provide an implementation of each function. An easy
|
||||
way to incorporate your implementations only when needed (since the ones
|
||||
in system C libraries may be hand optimized) is to, taking @code{memchr}
|
||||
for example, put it in @file{memchr.c} and use
|
||||
@samp{AC_REPLACE_FUNCS(memchr)}.
|
||||
|
||||
This macro calls @code{AC_PROG_CPP} or @code{AC_PROG_CXXCPP} (depending
|
||||
on which language is current, @pxref{Language Choice}), if it hasn't
|
||||
@ -1100,7 +1108,8 @@ code. See the example for @code{AC_HEADER_STDC}.
|
||||
@node Typedefs, Library Functions, Header Files, Specific Tests
|
||||
@section Typedefs
|
||||
|
||||
The following macros check for predefined C types:
|
||||
The following macros check for predefined C types.
|
||||
@xref{C Features}, for how to check for types not listed here.
|
||||
|
||||
@defmac AC_TYPE_GETGROUPS
|
||||
@maindex TYPE_GETGROUPS
|
||||
@ -1168,7 +1177,8 @@ If @code{uid_t} is not defined in @file{sys/types.h}, define
|
||||
@node Library Functions, Structures, Typedefs, Specific Tests
|
||||
@section Library Functions
|
||||
|
||||
The following macros check for particular C library functions:
|
||||
The following macros check for particular C library functions.
|
||||
@xref{C Features}, for how to check for functions not listed here.
|
||||
|
||||
@defmac AC_FUNC_ALLOCA
|
||||
@maindex FUNC_ALLOCA
|
||||
@ -1330,7 +1340,9 @@ If @code{wait3} is found and fills in the contents of its third argument
|
||||
@node Structures, Compiler Characteristics, Library Functions, Specific Tests
|
||||
@section Structures
|
||||
|
||||
The following macros check for certain structures or structure members:
|
||||
The following macros check for certain structures or structure members.
|
||||
You can use @code{AC_TRY_LINK} (@pxref{C System Output}) to check
|
||||
structures not listed here.
|
||||
|
||||
@defmac AC_HEADER_STAT
|
||||
@maindex HEADER_STAT
|
||||
@ -1411,7 +1423,8 @@ macro calls @code{AC_STRUCT_TM} if it hasn't been called already.
|
||||
@section Compiler Characteristics
|
||||
|
||||
The following macros check for C compiler or machine architecture
|
||||
features:
|
||||
features. You can use @code{AC_TRY_LINK} or @code{AC_TRY_RUN} (@pxref{C
|
||||
System Output}) to check for characteristics not listed here.
|
||||
|
||||
@defmac AC_C_BIGENDIAN
|
||||
@maindex C_BIGENDIAN
|
||||
@ -1488,7 +1501,7 @@ that define @code{__STDC__} do not support @code{long double}.
|
||||
@node System Services, UNIX Variants, Compiler Characteristics, Specific Tests
|
||||
@section System Services
|
||||
|
||||
The following macros check for operating system services:
|
||||
The following macros check for operating system services or capabilities.
|
||||
|
||||
@defmac AC_SYS_INTERPRETER
|
||||
@maindex SYS_INTERPRETER
|
||||
@ -1510,7 +1523,7 @@ variables @code{x_includes} and @code{x_libraries} to their locations,
|
||||
unless they are in directories the compiler searches by default.
|
||||
|
||||
If both methods fail, or the user gave the command line option
|
||||
@samp{--without-x}, set the shell variable @code{no_x} to @samp{true};
|
||||
@samp{--without-x}, set the shell variable @code{no_x} to @samp{yes};
|
||||
otherwise set it to the empty string.
|
||||
|
||||
The command line options @samp{--x-includes=@var{dir}} and
|
||||
@ -1908,7 +1921,8 @@ results (@pxref{C Features}).
|
||||
@defmac AC_COMPILE_CHECK (@var{echo-text}, @var{includes}, @var{function-body}, @var{action-if-found} @r{[}, @var{action-if-not-found}@r{]})
|
||||
@maindex COMPILE_CHECK
|
||||
This is an obsolete alias for @code{AC_TRY_LINK}, with the addition that it
|
||||
prints @samp{checking for @var{echo-text}} to the standard output first.
|
||||
prints @samp{checking for @var{echo-text}} to the standard output first,
|
||||
if @var{echo-text} is non-empty.
|
||||
@end defmac
|
||||
|
||||
@defmac AC_EGREP_CPP (@var{pattern}, @var{program}, @var{action-if-found} @r{[}, @var{action-if-not-found}@r{]})
|
||||
@ -2096,7 +2110,7 @@ shell commands @var{action-if-true}. Otherwise run shell commands
|
||||
@var{action-if-false}. @var{help-string} is a description of
|
||||
the option which looks like this:
|
||||
@example
|
||||
--enable-readline support fancy command line editing
|
||||
--enable-editing support fancy command line editing
|
||||
@end example
|
||||
@noindent
|
||||
@var{help-string} may be more than one line long, if more detail is
|
||||
@ -2190,8 +2204,9 @@ set @var{variable} to that value (verbatim), otherwise set it to 1.
|
||||
@var{value} should not contain literal newlines, and if you are not
|
||||
using @code{AC_CONFIG_HEADER} it should not contain any @samp{#}
|
||||
characters, as @code{make} tends to eat them. To use a shell variable
|
||||
or a value containing the @code{m4} quote characters @samp{[} or
|
||||
@samp{]}, use @code{AC_DEFINE_UNQUOTED} instead.
|
||||
(which you need to do in order to define a value containing the
|
||||
@code{m4} quote characters @samp{[} or @samp{]}), use
|
||||
@code{AC_DEFINE_UNQUOTED} instead.
|
||||
|
||||
@code{AC_OUTPUT} substitutes the values defined by this macro as the
|
||||
variable @code{DEFS} in the file(s) that it generates (typically
|
||||
@ -2265,7 +2280,7 @@ AC_CHECK_HEADER(elf.h, AC_DEFINE(SVR4); LIBS="$LIBS -lelf")
|
||||
Like @code{AC_DEFINE}, but three shell expansions are performed once on
|
||||
@var{value}: variable expansion (@samp{$}), command substitution
|
||||
(@samp{`}), and backslash escaping (@samp{\}). Use this macro instead
|
||||
of @code{AC_DEFINE} when @var{value} contains a shell variable. For
|
||||
of @code{AC_DEFINE} when @var{value} is a shell variable. For
|
||||
example:
|
||||
|
||||
@example
|
||||
@ -2392,9 +2407,10 @@ make hard links}.
|
||||
|
||||
@defmac AC_VERBOSE (@var{result-description})
|
||||
@maindex VERBOSE
|
||||
This macro is similar to @code{AC_MSG_RESULT}, except that it is meant to
|
||||
follow a call to @code{AC_CHECKING} instead of @code{AC_MSG_CHECKING}.
|
||||
It is considered obsolete.
|
||||
This macro is similar to @code{AC_MSG_RESULT}, except that it is meant
|
||||
to follow a call to @code{AC_CHECKING} instead of
|
||||
@code{AC_MSG_CHECKING}; it starts the message it prints with a tab. It
|
||||
is considered obsolete.
|
||||
@end defmac
|
||||
|
||||
@node Language Choice, Macro Ordering, Printing Messages, General Purpose Macros
|
||||
@ -2543,7 +2559,7 @@ Autoconf provides a uniform method for handling unguessable features.
|
||||
@end menu
|
||||
|
||||
@node Specifying Names, Canonicalizing, , Manual Configuration
|
||||
@section Specifying The System Type
|
||||
@section Specifying the System Type
|
||||
|
||||
Like other GNU @code{configure} scripts, Autoconf-generated
|
||||
@code{configure} scripts can make decisions based on a canonical name
|
||||
@ -2566,7 +2582,7 @@ system types are involved. The options to specify them are:
|
||||
@table @code
|
||||
@item --build=@var{build-type}
|
||||
the type of system on which the package is being configured and
|
||||
compiled;
|
||||
compiled (rarely needed);
|
||||
|
||||
@item --host=@var{host-type}
|
||||
the type of system on which the package will run;
|
||||
@ -2595,7 +2611,7 @@ example, @samp{decstation} can be given on the command line instead of
|
||||
@code{config.sub} to canonicalize system type aliases.
|
||||
|
||||
@node Canonicalizing, System Name Variables, Specifying Names, Manual Configuration
|
||||
@section Getting The Canonical System Type
|
||||
@section Getting the Canonical System Type
|
||||
|
||||
The following macros make the name of the system type available in
|
||||
@code{configure} scripts.
|
||||
@ -2624,7 +2640,8 @@ given to it.
|
||||
@node System Name Variables, Using System Type, Canonicalizing, Manual Configuration
|
||||
@section System Name Variables
|
||||
|
||||
The shell and @code{make} variables that contain the system type
|
||||
After calling @code{AC_CANONICAL_SYSTEM} or @code{AC_CANONICAL_HOST},
|
||||
the the shell and @code{make} variables that contain the system type
|
||||
information are:
|
||||
|
||||
@table @code
|
||||
@ -2642,7 +2659,7 @@ the individual parts of the canonical names (for convenience).
|
||||
@end table
|
||||
|
||||
@node Using System Type, , System Name Variables, Manual Configuration
|
||||
@section Using The System Type
|
||||
@section Using the System Type
|
||||
|
||||
How do you use a canonical system type? Usually, you use it in one or
|
||||
more @code{case} statements in @file{configure.in} to select
|
||||
@ -2819,8 +2836,9 @@ many of the macros use @samp{`} and @samp{'}, mismatched. However, in a
|
||||
few places the macros need to use brackets (usually in C program text or
|
||||
regular expressions). In those places, they use the @code{m4} builtin
|
||||
command @code{changequote} to temporarily change the quote characters to
|
||||
@samp{<<} and @samp{>>}. Sometimes, if they don't need to quote
|
||||
anything, they disable quoting entirely instead. Here is an example:
|
||||
@samp{<<} and @samp{>>}. (Sometimes, if they don't need to quote
|
||||
anything, they disable quoting entirely instead by setting the quote
|
||||
characters to empty strings.) Here is an example:
|
||||
|
||||
@example
|
||||
AC_TRY_LINK(
|
||||
@ -2987,7 +3005,15 @@ prevents people from configuring your package for cross-compiling. If
|
||||
it's really best that you test for a run-time behavior, try to provide a
|
||||
default ``worst case'' value to use when cross-compiling makes run-time
|
||||
tests impossible. You do this by passing the optional last argument to
|
||||
@code{AC_TRY_RUN}.
|
||||
@code{AC_TRY_RUN}. To configure for cross-compiling you can also set up
|
||||
a test results cache file with the correct values for the target system
|
||||
(@pxref{Caching Values}). But that is a last resort. Alternatively,
|
||||
choose a value for those parameters based on the canonical system name
|
||||
(@pxref{Manual Configuration}).
|
||||
|
||||
To enable @code{configure} scripts to support cross-compilation, they
|
||||
shouldn't do anything that tests features of the host system instead of
|
||||
the target system.
|
||||
|
||||
@menu
|
||||
* Guidelines:: General rules for writing test programs.
|
||||
@ -3021,7 +3047,7 @@ include any header files containing clashing prototypes.
|
||||
|
||||
@example
|
||||
#ifdef __cplusplus
|
||||
extern "C" char *malloc(int);
|
||||
extern "C" void *malloc(size_t);
|
||||
#else
|
||||
char *malloc();
|
||||
#endif
|
||||
@ -3113,18 +3139,19 @@ it had to perform all of the checks every time.
|
||||
Ensure that the results of the check identified by @var{cache-id} are
|
||||
available. If the results of the check were in the cache file that was
|
||||
read, and @code{configure} was not given the @samp{--quiet} or
|
||||
@samp{--silent} option, print a message saying so; otherwise, run the
|
||||
shell commands @var{commands-to-set-it}. Those commands should have no
|
||||
side effects except for setting the variable @var{cache-id}. In
|
||||
particular, they should not call @code{AC_DEFINE}; the code that follows
|
||||
the call to @code{AC_CACHE_VAL} should do that, based on the cached
|
||||
value. Also, they should not print any messages, for example with
|
||||
@code{AC_MSG_CHECKING}; do that before calling @code{AC_CACHE_VAL}, so
|
||||
the messages are printed regardless of whether the results of the check
|
||||
are retrieved from the cache or determined by running the shell
|
||||
commands. If the shell commands are run to determine the value, the
|
||||
value will be saved in the cache file just before @code{configure}
|
||||
creates its output files.
|
||||
@samp{--silent} option, print a message saying that the result was
|
||||
cached; otherwise, run the shell commands @var{commands-to-set-it}.
|
||||
Those commands should have no side effects except for setting the
|
||||
variable @var{cache-id}. In particular, they should not call
|
||||
@code{AC_DEFINE}; the code that follows the call to @code{AC_CACHE_VAL}
|
||||
should do that, based on the cached value. Also, they should not print
|
||||
any messages, for example with @code{AC_MSG_CHECKING}; do that before
|
||||
calling @code{AC_CACHE_VAL}, so the messages are printed regardless of
|
||||
whether the results of the check are retrieved from the cache or
|
||||
determined by running the shell commands. If the shell commands are run
|
||||
to determine the value, the value will be saved in the cache file just
|
||||
before @code{configure} creates its output files. @xref{Cache
|
||||
Variables}, for how to choose the name of the @var{cache-id} variable.
|
||||
@end defmac
|
||||
|
||||
@menu
|
||||
@ -3135,7 +3162,7 @@ creates its output files.
|
||||
@node Cache Files, Cache Variables, , Caching Values
|
||||
@section Cache Files
|
||||
|
||||
The cache file is a shell script that caches the results of configure
|
||||
A cache file is a shell script that caches the results of configure
|
||||
tests run on one system so they can be shared between configure scripts
|
||||
and configure runs. It is not useful on other systems. If its contents
|
||||
are invalid for some reason, the user may delete or edit it.
|
||||
@ -3163,7 +3190,8 @@ someone runs a @code{configure} script; it will be initially
|
||||
nonexistent. Running @code{configure} merges the new cache results with
|
||||
the existing cache file. The site initialization script can specify a
|
||||
site-wide cache file to use instead of the default, to make it work
|
||||
transparently (@pxref{Site Default Values}).
|
||||
transparently, as long as the same C compiler is used every time
|
||||
(@pxref{Site Default Values}).
|
||||
|
||||
@node Cache Variables, , Cache Files, Caching Values
|
||||
@section Cache Variables
|
||||
@ -3271,8 +3299,8 @@ directory, this is the same as @code{srcdir}.
|
||||
@defvar CFLAGS
|
||||
Debugging and optimization options for the C compiler. If it is not set
|
||||
in the environment when @code{configure} runs, the default value is set
|
||||
by @code{AC_PROG_CC} (empty if you don't). @code{configure} uses this
|
||||
variable when compiling programs to test for C features.
|
||||
when you call @code{AC_PROG_CC} (or empty if you don't). @code{configure}
|
||||
uses this variable when compiling programs to test for C features.
|
||||
@end defvar
|
||||
|
||||
@defvar CPPFLAGS
|
||||
@ -3286,8 +3314,9 @@ preprocessing programs to test for C features.
|
||||
@defvar CXXFLAGS
|
||||
Debugging and optimization options for the C++ compiler. If it is not
|
||||
set in the environment when @code{configure} runs, the default value is
|
||||
set by @code{AC_PROG_CXX} (empty if you don't). @code{configure} uses
|
||||
this variable when compiling programs to test for C++ features.
|
||||
set when you call @code{AC_PROG_CXX} (or empty if you don't).
|
||||
@code{configure} uses this variable when compiling programs to test for
|
||||
C++ features.
|
||||
@end defvar
|
||||
|
||||
@defvar DEFS
|
||||
@ -3438,11 +3467,13 @@ You can give @file{config.status} the @samp{--recheck} option to update
|
||||
itself. This option is useful if you change @code{configure}, so that
|
||||
the results of some tests might be different from the previous run. The
|
||||
@samp{--recheck} option re-runs @code{configure} with the same arguments
|
||||
you used before, plus the @samp{--no-create} option, which prevents
|
||||
you used before, plus the @samp{--no-create} option, which prevent
|
||||
@code{configure} from running @file{config.status} and creating
|
||||
@file{Makefile} and other files. (This is so other @file{Makefile}
|
||||
rules can run @file{config.status} when it changes; @pxref{Automatic
|
||||
Remaking}, for an example).
|
||||
@file{Makefile} and other files, and the @samp{--norecursion} option,
|
||||
which prevents @code{configure} from running other @code{configure}
|
||||
scripts in subdirectories. (This is so other @file{Makefile} rules can
|
||||
run @file{config.status} when it changes; @pxref{Automatic Remaking},
|
||||
for an example).
|
||||
|
||||
@file{config.status} also accepts the options @samp{--help}, which
|
||||
prints a summary of the options to @file{config.status}, and
|
||||
@ -3521,8 +3552,8 @@ separately for each architecture.
|
||||
If the environment variable @code{CONFIG_SITE} is set and contains the
|
||||
name of a readable file, @code{configure} reads that file as a shell
|
||||
script. Otherwise, it reads the shell script
|
||||
@file{@var{exec_prefix}/lib/config.site} if it exists, then
|
||||
@file{@var{prefix}/lib/config.site} if it exists. Thus, settings in
|
||||
@file{@var{prefix}/lib/config.site} if it exists, then
|
||||
@file{@var{exec_prefix}/lib/config.site} if it exists. Thus, settings in
|
||||
system dependent files override those in system independent ones in case
|
||||
of conflict. @code{configure} reads any cache file after it has read
|
||||
any site files. This way, the site file can define a default cache
|
||||
@ -3530,13 +3561,13 @@ file, to be shared between all Autoconf-generated @code{configure}
|
||||
scripts run on that system.
|
||||
|
||||
Site files can be arbitrary shell scripts, but only certain kinds of
|
||||
code are really appropriate to be in them. Besides a cache file, they
|
||||
are good places to set default values for other shell variables like
|
||||
@code{CC}, if you need to give them unusual values: anything you would
|
||||
normally do, repetitively, on the command line. If you use non-default
|
||||
values for @var{prefix} or @var{exec_prefix} (wherever you locate the
|
||||
site file), you can set them in the site file if you specify it with the
|
||||
@code{CONFIG_SITE} environment variable.
|
||||
code are really appropriate to be in them. Besides selecting a cache
|
||||
file, they are good places to set default values for other shell
|
||||
variables like @code{CC}, if you need to give them unusual values:
|
||||
anything you would normally do, repetitively, on the command line. If
|
||||
you use non-default values for @var{prefix} or @var{exec_prefix}
|
||||
(wherever you locate the site file), you can set them in the site file
|
||||
if you specify it with the @code{CONFIG_SITE} environment variable.
|
||||
|
||||
It is possible to set some cache values in the site file.
|
||||
If you are cross-compiling, it is impossible to check features that
|
||||
@ -3659,12 +3690,12 @@ information while configuring.
|
||||
|
||||
Autoconf version 2 is mostly backward compatible with version 1.
|
||||
However, it introduces better ways to do some things, and doesn't
|
||||
support some of the ugly things about version 1. So, depending on how
|
||||
support some of the ugly things in version 1. So, depending on how
|
||||
sophisticated your @file{configure.in} files are, you might have to do
|
||||
some manual work in order to upgrade to version 2. This chapter points
|
||||
out some problems to watch for when upgrading. Also, perhaps your
|
||||
@code{configure} scripts could benefit from some of the new features in
|
||||
version 2; see the @file{NEWS} file in the distribution for a summary.
|
||||
version 2.
|
||||
|
||||
@menu
|
||||
* Changed File Names:: Files you might rename.
|
||||
@ -3782,9 +3813,9 @@ fi
|
||||
@end example
|
||||
|
||||
If you were working around bugs in @code{AC_DEFINE_UNQUOTED} by adding
|
||||
backslashes, you probably need to remove them. It now works
|
||||
predictably, and does not treat quotes (except backquotes) specially.
|
||||
@xref{Setting Variables}.
|
||||
backslashes before quotes, you probably need to remove them. It now
|
||||
works predictably, and does not treat quotes (except backquotes)
|
||||
specially. @xref{Setting Variables}.
|
||||
|
||||
@node Changed Macro Writing, , Changed Results, Upgrading
|
||||
@section Changed Macro Writing
|
||||
@ -3816,7 +3847,7 @@ You may be wondering, Why was Autoconf originally written? How did it
|
||||
get into its present form? (Why does it look like gorilla spit?) If
|
||||
you're not wondering, then this chapter contains no information useful
|
||||
to you, and you might as well skip it. If you @emph{are} wondering,
|
||||
then let there be light.
|
||||
then let there be light@dots{}
|
||||
|
||||
@menu
|
||||
* Genesis:: Prehistory and naming of @code{configure}.
|
||||
@ -3878,7 +3909,7 @@ reads pieces of @file{configure.in} when run. But I didn't want to have
|
||||
to distribute all of the feature tests with every package, so I settled
|
||||
on having a different @code{configure} made from each
|
||||
@file{configure.in} by a preprocessor. That approach also offered more
|
||||
control and flexibility
|
||||
control and flexibility.
|
||||
|
||||
I looked briefly into using Larry Wall's Metaconfig program, but I
|
||||
decided not to for several reasons. The @code{Configure} scripts it
|
||||
@ -3936,7 +3967,7 @@ checks, great ideas, and bug fixes.
|
||||
@section Numbers
|
||||
|
||||
In July 1992, after months of alpha testing, I released Autoconf 1.0,
|
||||
and converted many of GNU packages to use it. I was surprised by how
|
||||
and converted many GNU packages to use it. I was surprised by how
|
||||
positive the reaction to it was. More people started using it than I
|
||||
could keep track of, including people working on software that wasn't
|
||||
part of the GNU Project (such as TCL, FSP, @TeX{}, and Kerberos v5).
|
||||
@ -3947,7 +3978,7 @@ Autoconf turned out to be a good torture test for @code{m4}
|
||||
implementations. Unix @code{m4} started to dump core because of the
|
||||
length of the macros that Autoconf defined, and several bugs showed up
|
||||
in GNU @code{m4} as well. Eventually, we realized that we needed to use
|
||||
some features that only GNU @code{m4} has. BSD @code{m4}, in
|
||||
some features that only GNU @code{m4} has. 4.3BSD @code{m4}, in
|
||||
particular, has an impoverished set of builtin macros; the System V
|
||||
version is better, but still doesn't provide everything we need.
|
||||
|
||||
|
||||
@ -148,7 +148,7 @@ Some packages pay attention to @samp{--with-@var{package}} options to
|
||||
@code{configure}, where @var{package} is something like @samp{gnu-as} or
|
||||
@samp{x} (for the X Window System). They may also pay attention to
|
||||
@samp{--enable-@var{feature}} options, where @var{feature} indicates an
|
||||
optional part of the package. The README should mention any
|
||||
optional part of the package. The @file{README} should mention any
|
||||
@samp{--with-} and @samp{--enable-} options that the package recognizes.
|
||||
|
||||
@noindent
|
||||
|
||||
@ -148,7 +148,7 @@ Some packages pay attention to @samp{--with-@var{package}} options to
|
||||
@code{configure}, where @var{package} is something like @samp{gnu-as} or
|
||||
@samp{x} (for the X Window System). They may also pay attention to
|
||||
@samp{--enable-@var{feature}} options, where @var{feature} indicates an
|
||||
optional part of the package. The README should mention any
|
||||
optional part of the package. The @file{README} should mention any
|
||||
@samp{--with-} and @samp{--enable-} options that the package recognizes.
|
||||
|
||||
@noindent
|
||||
|
||||
@ -1589,14 +1589,15 @@ for ac_file in .. ${CONFIG_HEADERS}; do if test "x$ac_file" != x..; then
|
||||
EOF
|
||||
|
||||
# Transform confdefs.h into a sed script conftest.vals that substitutes
|
||||
# the proper values into config.h.in to produce config.h.
|
||||
# the proper values into config.h.in to produce config.h. And first:
|
||||
# Protect against being on the right side of a sed subst in config.status.
|
||||
# Protect against being in an unquoted here document in config.status.
|
||||
rm -f conftest.vals
|
||||
dnl Using a here document instead of a string reduces the quoting nightmare.
|
||||
dnl Putting comments in sed scripts is not portable.
|
||||
cat > conftest.hdr <<\EOF
|
||||
changequote(<<, >>)dnl
|
||||
# Protect against being on the right side of a sed subst in config.status.
|
||||
s/[\\&%]/\\&/g
|
||||
# Protect against being in an unquoted here document in config.status.
|
||||
s%[\\$`]%\\&%g
|
||||
s%<<#define>> \([A-Za-z_][A-Za-z0-9_]*\) \(.*\)%${ac_dA}\1${ac_dB}\1${ac_dC}\2${ac_dD}%gp
|
||||
s%ac_d%ac_u%gp
|
||||
|
||||
@ -652,7 +652,7 @@ AC_CACHE_VAL(ac_cv_func_mmap,
|
||||
#endif
|
||||
|
||||
#ifdef __cplusplus
|
||||
extern "C" { char *valloc(int), *malloc(int); }
|
||||
extern "C" { void *valloc(unsigned), *malloc(unsigned); }
|
||||
#else
|
||||
char *valloc(), *malloc();
|
||||
#endif
|
||||
@ -665,9 +665,9 @@ main()
|
||||
int i2 = getpagesize()*2;
|
||||
int fd;
|
||||
|
||||
buf1 = valloc(i2);
|
||||
buf2 = valloc(i);
|
||||
buf3 = malloc(i2);
|
||||
buf1 = (char *)valloc(i2);
|
||||
buf2 = (char *)valloc(i);
|
||||
buf3 = (char *)malloc(i2);
|
||||
for (j = 0; j < i2; ++j)
|
||||
*(buf1 + j) = rand();
|
||||
fd = open("conftestmmap", O_CREAT | O_RDWR, 0666);
|
||||
@ -1643,10 +1643,11 @@ else
|
||||
[X_EXTRA_LIBS="$X_EXTRA_LIBS -ldnet_stub"])
|
||||
fi
|
||||
|
||||
# msh@cis.ufl.edu says -lnsl (and -lsocket) are needed for his 386/AT.
|
||||
# msh@cis.ufl.edu says -lnsl (and -lsocket) are needed for his 386/AT,
|
||||
# to get the SysV transport functions.
|
||||
# Not sure which flavor of 386 Unix this is, but it seems harmless to
|
||||
# check for it.
|
||||
AC_CHECK_LIB(nsl, main, [X_EXTRA_LIBS="$X_EXTRA_LIBS -lnsl"])
|
||||
AC_CHECK_LIB(nsl, t_accept, [X_EXTRA_LIBS="$X_EXTRA_LIBS -lnsl"])
|
||||
|
||||
# lieder@skyler.mavd.honeywell.com says without -lsocket,
|
||||
# socket/setsockopt and other routines are undefined under SCO ODT 2.0.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user