Skip to content
GitLab
Projects
Groups
Snippets
/
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Sign in / Register
Toggle navigation
Menu
Open sidebar
Joe Martin
OpenLDAP
Commits
19883d7f
Commit
19883d7f
authored
Apr 15, 2010
by
Quanah Gibson-Mount
Browse files
*** empty log message ***
parent
182dacfa
Changes
133
Expand all
Hide whitespace changes
Inline
Side-by-side
contrib/slapd-modules/nssov/Makefile
View file @
19883d7f
...
...
@@ -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
:
i
ns
tall
all
:
ns
sov.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)
$(INC
S
)
-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
View file @
19883d7f
...
...
@@ -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
View file @
19883d7f
...
...
@@ -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
View file @
19883d7f
...
...
@@ -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
View file @
19883d7f
...
...
@@ -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
View file @
19883d7f
...
...
@@ -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
View file @
19883d7f
...
...
@@ -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
deleted
100644 → 0
View file @
182dacfa
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/COPYING
deleted
100644 → 0
View file @
182dacfa
This diff is collapsed.
Click to expand it.
contrib/slapd-modules/nssov/nss-ldapd/ChangeLog
deleted
100644 → 0
View file @
182dacfa
This diff is collapsed.
Click to expand it.
contrib/slapd-modules/nssov/nss-ldapd/HACKING
deleted
100644 → 0
View file @
182dacfa
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
deleted
100644 → 0
View file @
182dacfa
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