readme

< linux网络编程工具>>配套源码

Solaris 2.4 (SunOS 5.4)
	If you include /usr/lib at the end of your LD_LIBRARY_PATH you run
	the risk of getting the wrong libraries under some circumstances.
	This is because of a new feature in Solaris 2.4, described by
	[e-mail]:

	>> Prior to SunOS 5.4, any LD_LIBRARY_PATH setting was ignored by the
	>> runtime linker if the application was setxid (secure), thus your
	>> applications search path would be:
	>>
	>>	/usr/local/lib	LD_LIBRARY_PATH component - IGNORED
	>>	/usr/lib	LD_LIBRARY_PATH component - IGNORED
	>>	/usr/local/lib	RPATH - honored
	>>	/usr/lib	RPATH - honored
	>>
	>> the effect is that path 3 would be the first used, and this would
	>> satisfy your resolv.so lookup.
	>>
	>> In SunOS 5.4 we made the LD_LIBRARY_PATH a little more flexible.
	>> People who developed setxid applications wanted to be able to alter
	>> the library search path to some degree to allow for their own
	>> testing and debugging mechanisms.  It was decided that the only
	>> secure way to do this was to allow a `trusted' path to be used in
	>> LD_LIBRARY_PATH.  The only trusted directory we presently define
	>> is /usr/lib.  Thus a setuid root developer could play with some
	>> alternative shared object implementations and place them in
	>> /usr/lib (being root we assume they'ed have access to write in this
	>> directory).  This change was made as part of 1155380 - after a
	>> *huge* amount of discussion regarding the security aspect of things.
	>>
	>> So, in SunOS 5.4 your applications search path would be:
	>>
	>>	/usr/local/lib	from LD_LIBRARY_PATH - IGNORED (untrustworthy)
	>>	/usr/lib	from LD_LIBRARY_PATH - honored (trustworthy)
	>>	/usr/local/lib	from RPATH - honored
	>>	/usr/lib	from RPATH - honored
	>>
	>> here, path 2 would be the first used.

Solaris 2.5.1 (SunOS 5.5.1) and 2.6 (SunOS 5.6)
	Apparently Solaris 2.5.1 patch 103663-01 installs a new
	/usr/include/resolv.h file that defines the __P macro without
	checking to see if it is already defined.  This new resolv.h is also
	included in the Solaris 2.6 distribution. This causes compile
	warnings such as:

	   In file included from daemon.c:51:
	   /usr/include/resolv.h:208: warning: `__P' redefined
	   cdefs.h:58: warning: this is the location of the previous definition

	These warnings can be safely ignored or you can create a resolv.h
	file in the obj.SunOS.5.5.1.* or obj.SunOS.5.6.* directory that reads:

	   #undef __P
	   #include "/usr/include/resolv.h"

	Sun is aware of the problem (Sun bug ID 4081053) and it will be fixed
	in Solaris 2.7.

Solaris 7 (SunOS 5.7)
	Solaris 7 includes LDAP libraries but the implementation was
	lacking a few things.  The following settings can be placed in
	devtools/Site/site.SunOS.5.7.m4 if you plan on using those
	libraries.

	APPENDDEF(`confMAPDEF', `-DLDAPMAP')
	APPENDDEF(`confENVDEF', `-DLDAP_VERSION_MAX=3')
	APPENDDEF(`confLIBS', `-lldap')

	Also, Sun's patch 107555 is needed to prevent a crash in the call
	to ldap_set_option for LDAP_OPT_REFERRALS in ldapmap_setopts if
	LDAP support is compiled in sendmail.

Ultrix
	By default, the IDENT protocol is turned off on Ultrix.  If you
	are running Ultrix 4.4 or later, or if you have included patch
	CXO-8919 for Ultrix 4.2 or 4.3 to fix the TCP problem, you can turn
	IDENT on in the configuration file by setting the "ident" timeout.

	The Ultrix 4.5 Y2K patch (ULTV45-022-1) has changed the resolver
	included in libc.a.  Unfortunately, the __RES symbol hasn't changed
	and therefore, sendmail can no longer automatically detect the
	newer version.  If you get a compiler error:

	/lib/libc.a(gethostent.o): local_hostname_length: multiply defined

	Then rebuild with this in devtools/Site/site.ULTRIX.m4:

	APPENDDEF(`conf_sendmail_ENVDEF', `-DNEEDLOCAL_HOSTNAME_LENGTH=0')

Digital UNIX (formerly DEC OSF/1)
	If you are compiling on OSF/1 (DEC Alpha), you must use
	-L/usr/shlib (otherwise it core dumps on startup).  You may also
	need -mld to get the nlist() function, although some versions
	apparently don't need this.

	Also, the enclosed makefile removed /usr/sbin/smtpd; if you need
	it, just create the link to the sendmail binary.

	On DEC OSF/1 3.2 or earlier, the MatchGECOS option doesn't work
	properly due to a bug in the getpw* routines.  If you want to use
	this, use -DDEC_OSF_BROKEN_GETPWENT=1.  The problem is fixed in 3.2C.

	Digital's mail delivery agent, /bin/mail (aka /bin/binmail), will
	only preserve the envelope sender in the "From " header if
	DefaultUserID is set to daemon.  Setting this to mailnull will
	cause all mail to have the header "From mailnull ...".  To use
	a different DefaultUserID, you will need to use a different mail
	delivery agent (such as mail.local found in the sendmail
	distribution).

	On Digital UNIX 4.0 and later, Berkeley DB 1.85 is included with the
	operating system and already has the ndbm.o module removed.  However,
	Digital has modified the original Berkeley DB db.h include file.
	This results in the following warning while compiling map.c and udb.c:

	cc: Warning: /usr/include/db.h, line 74: The redefinition of the macro
	 "__signed" conflicts with a current definition because the replacement
	 lists differ.  The redefinition is now in effect.
	#define __signed        signed
	------------------------^

	This warning can be ignored.

	Digital UNIX's linker checks /usr/ccs/lib/ before /usr/lib/.
	If you have installed a new version of BIND in /usr/include
	and /usr/lib, you will experience difficulties as Digital ships
	libresolv.a in /usr/ccs/lib/ as well.  Be sure to replace both
	copies of libresolv.a.

IRIX
	The header files on SGI IRIX are completely prototyped, and as
	a result you can sometimes get some warning messages during
	compilation.  These can be ignored.  There are two errors in
	deliver only if you are using gcc, both of the form ``warning:
	passing arg N of `execve' from incompatible pointer type''.
	Also, if you compile with -DNIS, you will get a complaint
	about a declaration of struct dom_binding in a prototype
	when compiling map.c; this is not important because the
	function being prototyped is not used in that file.

	In order to compile sendmail you will have had to install
	the developers' option in order to get the necessary include
	files.

	If you compile with -lmalloc (the fast memory allocator), you may
	get warning messages such as the following:

	   ld32: WARNING 85: definition of _calloc in /usr/lib32/libmalloc.so
		preempts that definition in /usr/lib32/mips3/libc.so.
	   ld32: WARNING 85: definition of _malloc in /usr/lib32/libmalloc.so
		preempts that definition in /usr/lib32/mips3/libc.so.
	   ld32: WARNING 85: definition of _realloc in /usr/lib32/libmalloc.so
		preempts that definition in /usr/lib32/mips3/libc.so.
	   ld32: WARNING 85: definition of _free in /usr/lib32/libmalloc.so
		preempts that definition in /usr/lib32/mips3/libc.so.
	   ld32: WARNING 85: definition of _cfree in /usr/lib32/libmalloc.so
		preempts that definition in /usr/lib32/mips3/libc.so.

	These are unavoidable and innocuous -- just ignore them.

	According to Dave Sill <[e-mail]>, there is a version of the
	Berkeley DB library patched to run on Irix 6.2 available from
	http://reality.sgi.com/ariel/freeware/#db .

IRIX 6.x
	If you are using XFS filesystem, avoid using the -32 ABI switch to
	the cc compiler if possible.

IRIX 6.4
	The IRIX 6.5.4 version of /bin/m4 does not work properly with
	sendmail.  Either install fw_m4.sw.m4 off the Freeware_May99 CD and
	use /usr/freeware/bin/m4 or install and use GNU m4.

NeXT or NEXTSTEP
	NEXTSTEP 3.3 and earlier ship with the old DBM library.  Also,
	Berkeley DB does not currently run on NEXTSTEP.

	If you are compiling on NEXTSTEP, you will have to create an
	empty file "unistd.h" and create a file "dirent.h" containing:

		#include <sys/dir.h>
		#define dirent	direct

	(devtools/OS/NeXT should try to do both of these for you.)

	Apparently, there is a bug in getservbyname on Nextstep 3.0
	that causes it to fail under some circumstances with the
	message "SYSERR: service "smtp" unknown" logged.  You should
	be able to work around this by including the line:

		OOPort=25

	in your .cf file.

BSDI (BSD/386) 1.0, NetBSD 0.9, FreeBSD 1.0
	The "m4" from BSDI won't handle the config files properly.
	I haven't had a chance to test this myself.

	The M4 shipped in FreeBSD and NetBSD 0.9 don't handle the config
	files properly. One must use either GNU m4 1.1 or the PD-M4
	recently posted in comp.os.386bsd.bugs (and maybe others).
	NetBSD-current includes the PD-M4 (as stated in the NetBSD file
	CHANGES).

	FreeBSD 1.0 RELEASE has uname(2) now. Use -DUSEUNAME in order to
	use it (look into devtools/OS/FreeBSD). NetBSD-current may have
	it too but it has not been verified.

	The latest version of Berkeley DB uses a different naming
	scheme than the version that is supplied with your release.  This
	means you will be able to use the current version of Berkeley DB
	with sendmail as long you use the new db.h when compiling
	sendmail and link it against the new libdb.a or libdb.so.  You
	should probably keep the original db.h in /usr/include and the
	new db.h in /usr/local/include.

4.3BSD
	If you are running a "virgin" version of 4.3BSD, you'll have
	a very old resolver and be missing some header files.  The
	header files are simple -- create empty versions and everything
	will work fine.  For the resolver you should really port a new
	version (4.8.3 or later) of the resolver; 4.9 is available on
	gatekeeper.DEC.COM in pub/BSD/bind/4.9.  If you are really
	determined to continue to use your old, buggy version (or as
	a shortcut to get sendmail working -- I'm sure you have the
	best intentions to port a modern version of BIND), you can
	copy ../contrib/oldbind.compat.c into sendmail and add
	oldbind.compat.o to OBJADD in the Makefile.

A/UX
	Date: Tue, 12 Oct 1993 18:28:28 -0400 (EDT)
	From: "Eric C. Hagberg" <[e-mail]>
	Subject: Fix for A/UX ndbm

	I guess this isn't really a sendmail bug, however, it is something
	that A/UX users should be aware of when compiling sendmail 8.6.

	Apparently, the calls that sendmail is using to the ndbm routines
	in A/UX 3.0.x contain calls to "broken" routines, in that the
	aliases database will break when it gets "just a little big"
	(sorry I don't have exact numbers here, but it broke somewhere
	around 20-25 aliases for me.), making all aliases non-functional
	after exceeding this point.

	What I did was to get the gnu-dbm-1.6 package, compile it, and
	then re-compile sendmail with "-lgdbm", "-DNDBM", and using the
	ndbm.h header file that comes with the gnu-package. This makes
	things behave properly.
	  [NOTE: see comment above about GDBM]

	I suppose porting the New Berkeley DB package is another route,
	however, I made a quick attempt at it, and found it difficult
	(not easy at least); the gnu-dbm package "configured" and
	compiled easily.

	  [NOTE: Berkeley DB version 2.X runs on A/UX and can be used for
	  database maps.]

SCO Unix
	From: Thomas Essebier <[e-mail]>
	Organisation:  Stallion Technologies Pty Ltd.

	It will probably help those who are trying to configure sendmail 8.6.9
	to know that if they are on SCO, they had better set
		OI-dnsrch
	or they will core dump as soon as they try to use the resolver.
	ie. although SCO has _res.dnsrch defined, and is kinda BIND 4.8.3, it
	does not inititialise it, nor does it understand 'search' in
	/etc/named.boot.
		- sigh -

	According to SCO, the m4 which ships with UnixWare 2.1.2 is broken.
	We recommend installing GNU m4 before attempting to build sendmail.

DG/UX
	Doug Anderson <[e-mail]> has successfully run
	V8 on the DG/UX 5.4.2 and 5.4R3.x platforms under heavy usage.
	Originally, the DG /bin/mail program wasn't compatible with
	the V8 sendmail, since the DG /bin/mail requires the environment
	variable "_FORCE_MAIL_LOCAL_=yes" be set.  Version 8.7 now includes