*** empty log message ***

contrib/slapd-modules/nssov/Makefile

@@ -24,7 +24,7 @@ OPT=-g -O2
 CC=gcc
 
 LDAP_INC=-I$(LDAPOBJ)/include -I$(LDAPSRC)/include -I$(LDAPSRC)/servers/slapd
-NLDAPD_INC=-Inss-ldapd
+NLDAPD_INC=-Inss-pam-ldapd
 INCS=$(LDAP_INC) $(NLDAPD_INC)
 
 LDAP_LIB=-lldap_r -llber
@@ -40,7 +40,7 @@ moduledir = $(libexecdir)$(ldap_subdir)
 sysconfdir = $(prefix)/etc$(ldap_subdir)
 schemadir = $(sysconfdir)/schema
 
-all:	install
+all:	nssov.la
 
 XOBJS = tio.lo
 
@@ -52,8 +52,8 @@ OBJS = alias.lo ether.lo group.lo host.lo netgroup.lo network.lo \
 .c.lo:
 	$(LIBTOOL) --mode=compile $(CC) $(OPT) $(DEFS) $(INCS) -c $<
 
-tio.lo:	nss-ldapd/common/tio.c
-	$(LIBTOOL) --mode=compile $(CC) $(OPT) $(DEFS) $(NLDAPD_INC) -c $?
+tio.lo:	nss-pam-ldapd/tio.c
+	$(LIBTOOL) --mode=compile $(CC) $(OPT) $(DEFS) $(INCS) -c $?
 
 $(OBJS):	nssov.h
 
@@ -68,3 +68,4 @@ install: nssov.la
 
 clean:
 	rm -f *.*o *.la .libs/*
+	rm -rf .libs

contrib/slapd-modules/nssov/README

@@ -4,12 +4,15 @@ same IPC protocol as Arthur de Jong's nss-ldapd, and a complete
 copy of the nss-ldapd source is included here. It also handles
 PAM requests.
 
-To use this code, you will need the client-side stub library from
-nss-ldapd (which resides in nss-ldapd/nss). You will not need the
-nslcd daemon; this overlay replaces that part. You should already
-be familiar with the RFC2307 and RFC2307bis schema to use this
-overlay. See the nss-ldapd/README for more information on the
-schema and which features are supported.
+To use this code, you will need the client-side stuf library from
+nss-pam-ldapd.  You can get it from:
+http://arthurdejong.org/nss-pam-ldapd
+You will not need the nslcd daemon; this overlay replaces that part.
+To disable building of the nslcd daemon in nss-pam-ldapd, add the
+--disable-nslcd option to the nss-pam-ldapd configure script. You
+should already be familiar with the RFC2307 and RFC2307bis schema
+to use this overlay.  See the nss-pam-ldapd README for more information
+on the schema and which features are supported.
 
 To use the overlay, add:
 

contrib/slapd-modules/nssov/alias.c

@@ -83,7 +83,7 @@ static int write_alias(nssov_alias_cbp *cbp,Entry *entry)
 	/* for each name, write an entry */
 	for (i=0;!BER_BVISNULL(&names[i]);i++)
 	{
-		WRITE_INT32(cbp->fp,NSLCD_RESULT_SUCCESS);
+		WRITE_INT32(cbp->fp,NSLCD_RESULT_BEGIN);
 		WRITE_BERVAL(cbp->fp,&names[i]);
 		WRITE_BVARRAY(cbp->fp,members);
 	}
@@ -97,7 +97,7 @@ NSSOV_HANDLE(
 	char fbuf[1024];
 	struct berval filter = {sizeof(fbuf)};
 	filter.bv_val = fbuf;
-	READ_STRING_BUF2(fp,cbp.buf,sizeof(cbp.buf));
+	READ_STRING(fp,cbp.buf);
 	cbp.name.bv_len = tmpint32;
 	cbp.name.bv_val = cbp.buf;,
 	Debug(LDAP_DEBUG_TRACE,"nssov_alias_byname(%s)\n",cbp.name.bv_val,0,0);,

contrib/slapd-modules/nssov/ether.c

@@ -111,7 +111,7 @@ static int write_ether(nssov_ether_cbp *cbp,Entry *entry)
 	for (i=0;!BER_BVISNULL(&names[i]);i++)
 		for (j=0;!BER_BVISNULL(&ethers[j]);j++)
 		{
-			WRITE_INT32(cbp->fp,NSLCD_RESULT_SUCCESS);
+			WRITE_INT32(cbp->fp,NSLCD_RESULT_BEGIN);
 			WRITE_BERVAL(cbp->fp,&names[i]);
 			WRITE_ETHER(cbp->fp,ethers[j]);
 		}
@@ -126,7 +126,7 @@ NSSOV_HANDLE(
 	struct berval filter = {sizeof(fbuf)};
 	filter.bv_val = fbuf;
 	BER_BVZERO(&cbp.addr);
-	READ_STRING_BUF2(fp,cbp.buf,sizeof(cbp.buf));
+	READ_STRING(fp,cbp.buf);
 	cbp.name.bv_len = tmpint32;
 	cbp.name.bv_val = cbp.buf;,
 	Debug(LDAP_DEBUG_TRACE,"nssov_ether_byname(%s)\n",cbp.name.bv_val,0,0);,

contrib/slapd-modules/nssov/group.c

@@ -248,7 +248,7 @@ static int write_group(nssov_group_cbp *cbp,Entry *entry)
 						names[i].bv_val);
 					continue;
 				}
-				WRITE_INT32(cbp->fp,NSLCD_RESULT_SUCCESS);
+				WRITE_INT32(cbp->fp,NSLCD_RESULT_BEGIN);
 				WRITE_BERVAL(cbp->fp,&names[i]);
 				WRITE_BERVAL(cbp->fp,&passwd);
 				WRITE_TYPE(cbp->fp,gid,gid_t);
@@ -277,7 +277,7 @@ NSSOV_HANDLE(
 	char fbuf[1024];
 	struct berval filter = {sizeof(fbuf)};
 	filter.bv_val = fbuf;
-	READ_STRING_BUF2(fp,cbp.buf,sizeof(cbp.buf));
+	READ_STRING(fp,cbp.buf);
 	cbp.name.bv_len = tmpint32;
 	cbp.name.bv_val = cbp.buf;
 	if (!isvalidgroupname(&cbp.name)) {
@@ -316,7 +316,7 @@ NSSOV_HANDLE(
 	char fbuf[1024];
 	struct berval filter = {sizeof(fbuf)};
 	filter.bv_val = fbuf;
-	READ_STRING_BUF2(fp,cbp.buf,sizeof(cbp.buf));
+	READ_STRING(fp,cbp.buf);
 	cbp.user.bv_len = tmpint32;
 	cbp.user.bv_val = cbp.buf;
 	if (!isvalidusername(&cbp.user)) {

contrib/slapd-modules/nssov/host.c

@@ -91,7 +91,7 @@ static int write_host(nssov_host_cbp *cbp,Entry *entry)
 	addrs = a->a_vals;
 	numaddr = a->a_numvals;
 	/* write the entry */
-	WRITE_INT32(cbp->fp,NSLCD_RESULT_SUCCESS);
+	WRITE_INT32(cbp->fp,NSLCD_RESULT_BEGIN);
 	WRITE_BERVAL(cbp->fp,&name);
 	if ( dupname >= 0 ) {
 		WRITE_INT32(cbp->fp,numname-1);
@@ -118,7 +118,7 @@ NSSOV_HANDLE(
 	struct berval filter = {sizeof(fbuf)};
 	filter.bv_val = fbuf;
 	BER_BVZERO(&cbp.addr);
-	READ_STRING_BUF2(fp,cbp.buf,sizeof(cbp.buf));
+	READ_STRING(fp,cbp.buf);
 	cbp.name.bv_len = tmpint32;
 	cbp.name.bv_val = cbp.buf;,
 	Debug(LDAP_DEBUG_TRACE,"nssov_host_byname(%s)\n",cbp.name.bv_val,0,0);,

contrib/slapd-modules/nssov/netgroup.c

@@ -140,8 +140,8 @@ static int write_netgroup_triple(TFILE *fp,const char *triple)
 		return 0;
 	}
 	/* write strings */
-	WRITE_INT32(fp,NSLCD_RESULT_SUCCESS);
-	WRITE_INT32(fp,NETGROUP_TYPE_TRIPLE);
+	WRITE_INT32(fp,NSLCD_RESULT_BEGIN);
+	WRITE_INT32(fp,NSLCD_NETGROUP_TYPE_TRIPLE);
 	WRITE_STRING_STRIPSPACE_LEN(fp,triple+hostb,hoste-hostb)
 	WRITE_STRING_STRIPSPACE_LEN(fp,triple+userb,usere-userb)
 	WRITE_STRING_STRIPSPACE_LEN(fp,triple+domainb,domaine-domainb)
@@ -171,9 +171,9 @@ static int write_netgroup(nssov_netgroup_cbp *cbp,Entry *entry)
 		for (i=0;i<a->a_numvals;i++)
 		{
 			/* write the result code */
-			WRITE_INT32(cbp->fp,NSLCD_RESULT_SUCCESS);
+			WRITE_INT32(cbp->fp,NSLCD_RESULT_BEGIN);
 			/* write triple indicator */
-			WRITE_INT32(cbp->fp,NETGROUP_TYPE_NETGROUP);
+			WRITE_INT32(cbp->fp,NSLCD_NETGROUP_TYPE_NETGROUP);
 			/* write netgroup name */
 			if (write_string_stripspace_len(cbp->fp,a->a_vals[i].bv_val,a->a_vals[i].bv_len))
 				return -1;
@@ -190,7 +190,7 @@ NSSOV_HANDLE(
 	char fbuf[1024];
 	struct berval filter = {sizeof(fbuf)};
 	filter.bv_val = fbuf;
-	READ_STRING_BUF2(fp,cbp.buf,sizeof(cbp.buf));,
+	READ_STRING(fp,cbp.buf);,
 	cbp.name.bv_len = tmpint32;
 	cbp.name.bv_val = cbp.buf;
 	Debug(LDAP_DEBUG_TRACE,"nssov_netgroup_byname(%s)\n",cbp.name.bv_val,0,0);,

contrib/slapd-modules/nssov/nss-ldapd/AUTHORS

-The original nss_ldap library was written by Luke Howard of PADL Software Pty
-Ltd. In 2006 Arthur de Jong of West Consuling forked the library to split it
-into a thin NSS part and a server part. The copyright holders of most of the
-code are:
-
-Luke Howard <lukeh@padl.com>
-West Consulting <info@west.nl>
-Arthur de Jong <arthur@ch.tudelft.nl>
-
-The following people (in no particular order) have also volunteered their
-time, effort, and ideas to make this software available. If you feel you are
-unjustly left out of this list, please send an email.
-
-Steven Barrus <sbarrus@eng.utah.edu>
-David Begley <david@avarice.nepean.uws.edu.au>
-Maxim Batourine <Batourine_M@ald.utoronto.ca>
-Michael Brownea <mbrown@fensystems.co.uk>
-Max Caines <Max.Caines@wlv.ac.uk>
-Carlos Celso <carlos.celso@embraer.com.br>
-Peter Cherny <peterc@luddite.com.au>
-Howard Chu <hyc@symas.com>
-Ben Collins <bcollins@debian.org>
-Stephan Cremer <scremer@dohle.com>
-Alejandro Forero Cuervo <azul@freaks-unidos.net>
-Guenther Deschner <gd@samba.org>
-Luca Filipozzi <lucaf+nssldap@ece.ubc.ca>
-Andrew Findlay <Andrew.Findlay@skills-1st.co.uk>
-Cristian Gafton <gafton@redhat.com>
-Gabor Gombas <gombasg@inf.elte.hu>
-DJ Gregor <dj@gregor.com>
-Bob Guo <bob@mail.ied.ac.cn>
-Daniel Hanks <hanksdc@plug.org>
-Leif Hedstrom <leif@ogre.com>
-Emile Heitor <eheitor@isdnet.net>
-Geert Jansen <undisclosed>
-Szymon Juraszczyk <szymon@ssk.pl>
-Anselm Kruis <kruis@till-photonics.com>
-Thorsten Kukuk <kukuk@suse.de>
-Steve Langasek <vorlon@netexpress.net>
-Joe Little <jlittle@open-it.org>
-Phillip Liu <phillip@loudcloud.com>
-Larry Lile <llile@dreamworks.com>
-Jeff Mandel <jeff.mandel@probes.com>
-Peter Marschall <peter@adpm.de>
-Michael Mattice <mike@bmisystems.com>
-Dejan Muhamedagic <dejan.muhamedagic@at.ibm.com>
-Doug Nazar <nazard@dragoninc.on.ca>
-Frode Nordahl <frode@nordahl.net>
-Lars Oergel <lars.oergel@innominate.de>
-Fredrik Ohrn <ohrn@chl.chalmers.se>
-Rakesh Patel <rpatel@globix.com>
-Nathan Hawkins <Nathan.Hawkins@FMR.COM>
-Andrew Rechenberg <ARechenberg@shermanfinancialgroup.com>
-Greg Retowski <greg@rage.net>
-Alain Richard <alain.richard@equation.fr>
-Michael Shuey <shuey@ecn.purdue.edu>
-Oliver Schulze L. <oliver@samera.com.py>
-Alexander Spannagel <spannagel@jobpilot.com>
-Scott M. Stone <sstone@foo3.com>
-Gero Treuner <gero@faveve.uni-stuttgart.de>
-Jarkko Turkulainen <jt@wapit.com>
-Stein Vrale <stein@terminator.net>
-Simon Wilkinson <sxw@sxw.org.uk>
-Davide Puricelli <evo@debian.org>
-Sami Haahtinen <ressu@debian.org>
-Stephen Frost <sfrost@debian.org>
-Américo Monteiro <a_monteiro@netcabo.pt>
-Cyril Brulebois <cyril.brulebois@enst-bretagne.fr>
-Kenshi Muto <kmuto@debian.org>
-Andreas Schneider <anschneider@suse.de>
-Ralf Haferkamp <rhafer@suse.de>
-Michael Calmer <mc@suse.de>
-Erik Schanze <eriks@debian.org>
-Bart Cornelis <cobaco@skolelinux.no>
-Rudy Godoy Guillén <rudy@debian.org>
-Petter Reinholdtsen <pere@hungry.com>

contrib/slapd-modules/nssov/nss-ldapd/HACKING

-
-This document tries to describe the software layout and design of the library.
-It should provide some help for contributing code to this package.
-
-CONTRIBUTING TO NSS-LDAPD
-=========================
-
-Contributions to nss-ldapd are most welcome. However not all contributions
-will be automatically integrated. Some notes:
-
-* for large changes it is a good idea to send an email first
-* send your patches in unified diff (diff -u) format
-* try to use the svn version of the software to develop the patch
-* clearly state which problem you're trying to solve and how this is
-  accomplished
-* please follow the existing coding conventions
-* patches will be integrated on a best-effort bases
-* please test the patch and include information on testing with the patch
-  (platforms tested, etc)
-* contributions will be acknowledged in the AUTHORS file
-* include a copyright statement in the patched code if you feel the
-  contribution is significant enough (e.g. more than a few lines)
-* when including third-party code, retain copyright information (copyright
-  holder and license) and ensure that the license is LGPL compatible
-
-Please contact Arthur de Jong <arthur@ch.tudelft.nl> if you want to
-contribute or use the Debian BTS if you're using the Debian package.
-
-
-BUILD DEPENDENCIES
-==================
-
-For building svn snapshots the following tools are needed:
-
-* autoconf (2.61 is used but 2.59 is minimal)
-* automake (1.10 is used)
-* check (0.9.5 is used)
-
-and of course the usual build tools (gcc/make/etc). Also see debian/control
-(Build-Depends field) for libraries you need.
-
-To build the svn snapshot run the autogen.sh shell script to build the
-configure script. When developing patches please use --enable-warnings with
-configure and don't introduce too many new warnings. For building the manual
-pages docbook2x is used.
-
-
-RELEASE VERSIONING
-==================
-
-A new versioning scheme was chosen over the nss_ldap release scheme. The
-scheme is a simple major.minor numbering starting with 0.1. Until a 1.0
-release is made the code will be considered work in progress. The interfaces
-may change and features may be added and removed.
-
-
-GENERAL DESIGN
-==============
-
-The basic design splits the functionality in two parts. The NSS part
-interfaces with libc and translates the NSS requests into simple generic
-requests (e.g. "get user with name test", "get group with gid 101" or "get all
-shadow entries"). Translating these requests into LDAP requests is then the
-job of the daemon (nslcd) so that the NSS part won't have to know anything
-about LDAP (in fact replacing it with another lookup method is very simple).
-
-                nslcd  -> OpenLDAP -> LDAP server
-                  ^
-    libc NSS -> libnss_ldap.so
-
-design goals
-------------
-* make it as simple as possible
-* design as specified above
-* simpler configuration and semantics
-* simpler, clearer and completer documentation
-* split source code into directories (src, src/hacks, src/aix, src/irs, etc)
-* get rid of unneeded code and complexity
-* split complexity in two parts (LDAP interface in server, NSS interface in
-  library)
-* have a stable, easily maintainable piece of quality software
-
-
-NSS PART
-========
-
-The NSS part is implemented in files in the nss directory. The functions are
-split into files according to the database they support. All functions look
-like:
-
-_nss_ldap_FUNCTION_r(...)
-  This function opens the connection to the nslcd (with a time-out) builds the
-  correct data structures and does a request (write()) to the nslcd waiting
-  for an answer (again with a time-out)
-
-Currently a number of macros are used to build most of the function bodies for
-these functions. A more elegant solution is welcome.
-
-Some handy links:
-http://mirrors.usc.edu/pub/gnu/Manuals/glibc-2.2.3/html_chapter/libc_28.html#SEC596
-http://www.gnu.org/software/libc/manual/html_node/index.html
-
-
-THE COMMUNICATIONS PROTOCOL
-===========================
-
-The protocol used for communicating between the NSS library and the nslcd
-daemon is very simple and almost fully described in the nslcd.h header file.
-The nslcd-common.h header file defines some macros that are used for reading
-and writing protocol entities (strings, 32-bit integers, etc).
-
-Some of the protocol handling code is automatically generated from the macros
-defined in nslcd.h. This cannot be done automatically in every case though so
-changing the protocol requires manual checking in the relevant source files in
-both the nss and the nslcd directories.
-
-If the protocol is changed in an incompatible way the protocol version should
-be incremented in nslcd.h. There is currently no versioning scheme available
-for this.
-
-A special module (common/tio.c) was made so we can define simpler semantics
-for time-out values and buffer sizes. Both tha NSS library and nslcd use this
-module which means that it includes functionality that is needed for both
-(e.g. large write buffers for the server part and large resettable read
-buffers for the NSS part). Maybe building two modules from the same source
-with different features in them is an option (e.g. the NSS part needs the
-read buffers and handling of SIGPIPE and the nslcd part needs the write
-buffers and possibly flushing in the background).
-
-
-SERVER PART
-===========
-
-At the server end a dispatcher picks up the request and delegates it to one of
-the database specific functions.
-
-nslcd_FUNCION(...)
-  This functions fills in the correct parameters from the request. This
-  function should write responses to the stream. Almost all these functions
-  are generated from a macro in common.h.
-
-
-SECURITY NOTES
-==============
-
-This design does open up the system to more potential security issues as there
-is now a local interface to a daemon with privileges. Before processes could
-only potentially exploit bugs in the library and gain the privileges of the
-process that was doing the name lookups. In this case the privileges of the
-daemon are potentially exposed.
-
-The deamon should be changed to set a specific less-privileged user and
-group to minimize the riscs. Code for this is already in place. Configuration
-options should be added and the Debian packaging should use this.

contrib/slapd-modules/nssov/nss-ldapd/INSTALL

-Installation Instructions
-*************************
-
-Copyright (C) 1994, 1995, 1996, 1999, 2000, 2001, 2002, 2004, 2005,
-2006, 2007 Free Software Foundation, Inc.
-
-This file is free documentation; the Free Software Foundation gives
-unlimited permission to copy, distribute and modify it.
-
-Basic Installation
-==================
-
-Briefly, the shell commands `./configure; make; make install' should
-configure, build, and install this package.  The following
-more-detailed instructions are generic; see the `README' file for
-instructions specific to this package.
-
-   The `configure' shell script attempts to guess correct values for
-various system-dependent variables used during compilation.  It uses
-those values to create a `Makefile' in each directory of the package.
-It may also create one or more `.h' files containing system-dependent
-definitions.  Finally, it creates a shell script `config.status' that
-you can run in the future to recreate the current configuration, and a
-file `config.log' containing compiler output (useful mainly for
-debugging `configure').
-
-   It can also use an optional file (typically called `config.cache'
-and enabled with `--cache-file=config.cache' or simply `-C') that saves
-the results of its tests to speed up reconfiguring.  Caching is
-disabled by default to prevent problems with accidental use of stale
-cache files.
-
-   If you need to do unusual things to compile the package, please try
-to figure out how `configure' could check whether to do them, and mail
-diffs or instructions to the address given in the `README' so they can
-be considered for the next release.  If you are using the cache, and at
-some point `config.cache' contains results you don't want to keep, you
-may remove or edit it.
-
-   The file `configure.ac' (or `configure.in') is used to create
-`configure' by a program called `autoconf'.  You need `configure.ac' if
-you want to change it or regenerate `configure' using a newer version
-of `autoconf'.
-
-The simplest way to compile this package is:
-
-  1. `cd' to the directory containing the package's source code and type
-     `./configure' to configure the package for your system.
-
-     Running `configure' might take a while.  While running, it prints
-     some messages telling which features it is checking for.
-
-  2. Type `make' to compile the package.
-
-  3. Optionally, type `make check' to run any self-tests that come with
-     the package.
-
-  4. Type `make install' to install the programs and any data files and
-     documentation.
-
-  5. You can remove the program binaries and object files from the
-     source code directory by typing `make clean'.  To also remove the
-     files that `configure' created (so you can compile the package for
-     a different kind of computer), type `make distclean'.  There is
-     also a `make maintainer-clean' target, but that is intended mainly
-     for the package's developers.  If you use it, you may have to get
-     all sorts of other programs in order to regenerate files that came
-     with the distribution.
-
-  6. Often, you can also type `make uninstall' to remove the installed
-     files again.
-
-Compilers and Options
-=====================
-
-Some systems require unusual options for compilation or linking that the
-`configure' script does not know about.  Run `./configure --help' for
-details on some of the pertinent environment variables.
-
-   You can give `configure' initial values for configuration parameters
-by setting variables in the command line or in the environment.  Here
-is an example:
-
-     ./configure CC=c99 CFLAGS=-g LIBS=-lposix
-
-   *Note Defining Variables::, for more details.
-
-Compiling For Multiple Architectures
-====================================
-
-You can compile the package for more than one kind of computer at the
-same time, by placing the object files for each architecture in their
-own directory.  To do this, you can use GNU `make'.  `cd' to the
-directory where you want the object files and executables to go and run
-the `configure' script.  `configure' automatically checks for the
-source code in the directory that `configure' is in and in `..'.
-
-   With a non-GNU `make', it is safer to compile the package for one
-architecture at a time in the source code directory.  After you have
-installed the package for one architecture, use `make distclean' before
-reconfiguring for another architecture.
-
-Installation Names
-==================
-
-By default, `make install' installs the package's commands under
-`/usr/local/bin', include files under `/usr/local/include', etc.  You
-can specify an installation prefix other than `/usr/local' by giving
-`configure' the option `--prefix=PREFIX'.
-
-   You can specify separate installation prefixes for
-architecture-specific files and architecture-independent files.  If you
-pass the option `--exec-prefix=PREFIX' to `configure', the package uses
-PREFIX as the prefix for installing programs and libraries.
-Documentation and other data files still use the regular prefix.
-
-   In addition, if you use an unusual directory layout you can give
-options like `--bindir=DIR' to specify different values for particular
-kinds of files.  Run `configure --help' for a list of the directories
-you can set and what kinds of files go in them.
-
-   If the package supports it, you can cause programs to be installed
-with an extra prefix or suffix on their names by giving `configure' the
-option `--program-prefix=PREFIX' or `--program-suffix=SUFFIX'.
-
-Optional Features
-=================
-
-Some packages pay attention to `--enable-FEATURE' options to
-`configure', where FEATURE indicates an optional part of the package.
-They may also pay attention to `--with-PACKAGE' options, where PACKAGE
-is something like `gnu-as' or `x' (for the X Window System).  The
-`README' should mention any `--enable-' and `--with-' options that the
-package recognizes.
-
-   For packages that use the X Window System, `configure' can usually
-find the X include and library files automatically, but if it doesn't,
-you can use the `configure' options `--x-includes=DIR' and
-`--x-libraries=DIR' to specify their locations.
-
-Specifying the System Type
-==========================
-
-There may be some features `configure' cannot figure out automatically,
-but needs to determine by the type of machine the package will run on.
-Usually, assuming the package is built to be run on the _same_
-architectures, `configure' can figure that out, but if it prints a
-message saying it cannot guess the machine type, give it the
-`--build=TYPE' option.  TYPE can either be a short name for the system
-type, such as `sun4', or a canonical name which has the form:
-
-     CPU-COMPANY-SYSTEM
-
-where SYSTEM can have one of these forms:
-
-     OS KERNEL-OS
-
-   See the file `config.sub' for the possible values of each field.  If
-`config.sub' isn't included in this package, then this package doesn't
-need to know the machine type.
-
-   If you are _building_ compiler tools for cross-compiling, you should
-use the option `--target=TYPE' to select the type of system they will
-produce code for.
-
-   If you want to _use_ a cross compiler, that generates code for a
-platform different from the build platform, you should specify the
-"host" platform (i.e., that on which the generated programs will
-eventually be run) with `--host=TYPE'.
-
-Sharing Defaults
-================
-
-If you want to set default values for `configure' scripts to share, you
-can create a site shell script called `config.site' that gives default
-values for variables like `CC', `cache_file', and `prefix'.
-`configure' looks for `PREFIX/share/config.site' if it exists, then
-`PREFIX/etc/config.site' if it exists.  Or, you can set the
-`CONFIG_SITE' environment variable to the location of the site script.
-A warning: not all `configure' scripts look for a site script.
-
-Defining Variables
-==================
-
-Variables not defined in a site shell script can be set in the
-environment passed to `configure'.  However, some packages may run
-configure again during the build, and the customized values of these
-variables may be lost.  In order to avoid this problem, you should set
-them in the `configure' command line, using `VAR=value'.  For example:
-
-     ./configure CC=/usr/local2/bin/gcc
-
-causes the specified `gcc' to be used as the C compiler (unless it is
-overridden in the site shell script).
-
-Unfortunately, this technique does not work for `CONFIG_SHELL' due to
-an Autoconf bug.  Until the bug is fixed you can use this workaround:
-
-     CONFIG_SHELL=/bin/bash /bin/bash ./configure CONFIG_SHELL=/bin/bash
-
-`configure' Invocation
-======================
-
-`configure' recognizes the following options to control how it operates.
-
-`--help'
-`-h'
-     Print a summary of the options to `configure', and exit.
-
-`--version'
-`-V'
-     Print the version of Autoconf used to generate the `configure'
-     script, and exit.
-
-`--cache-file=FILE'
-     Enable the cache: use and save the results of the tests in FILE,
-     traditionally `config.cache'.  FILE defaults to `/dev/null' to
-     disable caching.
-
-`--config-cache'
-`-C'
-     Alias for `--cache-file=config.cache'.
-
-`--quiet'
-`--silent'
-`-q'
-     Do not print messages saying which checks are being made.  To
-     suppress all normal output, redirect it to `/dev/null' (any error
-     messages will still be shown).
-
-`--srcdir=DIR'
-     Look for the package's source code in directory DIR.  Usually
-     `configure' can determine that directory automatically.
-
-`configure' also accepts some other, not widely useful, options.  Run
-`configure --help' for more details.
-