135062Sbostic# Copyright (c) 1983 Eric P. Allman 248582Sbostic# Copyright (c) 1988 The Regents of the University of California. 333728Sbostic# All rights reserved. 433728Sbostic# 548582Sbostic# %sccs.include.redist.sh% 633728Sbostic# 7*67770Seric# @(#)READ_ME 8.71 (Berkeley) 09/09/94 833728Sbostic# 948582Sbostic 109881SericThis directory contains the source files for sendmail. 115369Seric 1260565SericFor detailed instructions, please read the document ../doc/op.me: 135369Seric 1460565Seric eqn ../doc/op.me | pic | ditroff -me 155369Seric 1665366SericThe Makefile is for the new (4.4BSD) Berkeley make and uses syntax 1765366Sericthat is not recognized by older makes. It also has assumptions 1865366Sericabout the 4.4 file system layout built in. See below for details 1965366Sericabout other Makefiles. 2057418Seric 2164501SericThere is also a Makefile.dist which is much less clever, but works on 2264501Sericthe old traditional make. You can use this using: 2364501Seric 2457418Seric make -f Makefile.dist 2557418Seric 2665366Seric************************************************** 2765366Seric** Read below for more details of Makefiles. ** 2865366Seric************************************************** 2957943Seric 3064272SericThere is also a shell script (makesendmail) that tries to be clever 3164272Sericabout using object subdirectories. It's pretty straightforward, and 3264272Sericmay help if you share a source tree among different architectures. 3364035Seric 3465000Seric************************************************************************** 3565000Seric** IMPORTANT: DO NOT USE OPTIMIZATION (``-O'') IF YOU ARE RUNNING ** 3665000Seric** GCC 2.4.x or 2.5.x. THERE IS A BUG IN THE GCC OPTIMIZER THAT ** 3765000Seric** CAUSES SENDMAIL COMPILES TO FAIL MISERABLY. ** 3865000Seric************************************************************************** 3964272Seric 4065000SericJim Wilson of Cygnus believes he has found the problem -- it will 4165000Sericprobably be fixed in GCC 2.5.6 -- but until this is verified, be 4265000Sericvery suspicious of gcc -O. 4364701Seric 4465000Seric************************************************************************** 4565000Seric** IMPORTANT: Read the appropriate paragraphs in the section on ** 4665000Seric** ``Operating System and Compile Quirks''. ** 4765000Seric************************************************************************** 4864718Seric 4965000Seric 5065366Seric+-----------+ 5165366Seric| MAKEFILES | 5265366Seric+-----------+ 5365366Seric 5465366SericThe "Makefile"s in these directories are from 4.4 BSD, and hence 5565366Sericreally only work properly if you are on a 4.4 system. In particular, 5665366Sericthey use new syntax that will not be recognized on old make programs, 5765366Sericand some of them do things like ``.include ../../Makefile.inc'' to 5865366Sericpick up some system defines. If you are getting sendmail separately, 5965366Sericthese files won't be included in the distribution, as they are 6065366Sericoutside of the sendmail tree. 6165366Seric 6265366SericInstead, you should use one of the other Makefiles, such as 6365366SericMakefile.SunOS for a SunOS system, and so forth. These should 6465366Sericwork with the version of make that is appropriate for that 6565366Sericsystem. 6665366Seric 6765366SericThere are a bunch of other Makefiles for other systems with names 6865366Sericlike Makefile.HPUX for an HP-UX system. They use the version of 6965366Sericmake that is native for that system. These are the Makefiles that 7065366SericI use, and they have "Berkeley quirks" in them. I can't guarantee 7165366Sericthat they will work unmodified in your environment. Many of them 7265366Sericinclude -I/usr/sww/include/db and -L/usr/sww/lib -- this is Berkeley's 7365366Sericlocation (the ``Software Warehouse'') for the new database libraries, 7465366Sericdescribed below. You don't have to remove these definitions if you 7565366Sericdon't have these directories. 7665366Seric 7765366SericPlease look for an appropriate Makefile before you start trying to 7865366Sericcompile with Makefile or Makefile.dist. 7965366Seric 8065366SericIf you want to port the new Berkeley make, you can get it from 8165366Sericftp.uu.net in the directory /systems/unix/bsd-sources/usr.bin/make. 8265366SericDiffs and instructions for building this version of make under 8365366SericSunOS 4.1.x are available on ftp.css.itd.umich.edu in 8465366Seric/pub/systems/sun/Net2-make.sun4.diff.Z. Diffs and instructions 8565366Sericfor building this version of make under IBM AIX 3.2.4 are available 8665366Sericon ftp.uni-stuttgart.de in /sw/src/patches/bsd-make-rus-patches. 8767555SericFor Ultrix, try ftp.vix.com:~ftp/pub/patches/pmake-for-ultrix.Z. 8865366SericPaul Southworth <pauls@umich.edu> published a description of porting 8965366Sericthis make in comp.unix.bsd. 9065366Seric 9165366SericThe complete text of the Makefile.inc that is in the parent of the 9265366Sericsendmail directory is: 9365366Seric 9465366Seric # @(#)Makefile.inc 8.1 (Berkeley) 6/6/93 9565366Seric 9665366Seric BINDIR?= /usr/sbin 9765366Seric 9865366Seric 9964250Seric+----------------------+ 10064250Seric| DATABASE DEFINITIONS | 10164250Seric+----------------------+ 10264250Seric 10364250SericThere are several database formats that can be used for the alias files 10464250Sericand for general maps. When used for alias files they interact in an 10564250Sericattempt to be back compatible. 10664250Seric 10764250SericThe three options are NEWDB (the new Berkeley DB package), NDBM (the 10864250Sericolder DBM implementation -- the very old V7 implementation is no 10964250Sericlonger supported), and NIS (Network Information Services). Used alone 11064376Sericthese just include the support they indicate. [If you are using NEWDB, 11164376Sericget the latest version from FTP.CS.Berkeley.EDU in /ucb/4bsd. DO NOT 11265000Sericuse the version from the Net2 distribution! However, if you are on 11365000SericBSD/386 or 386BSD-based systems, use the one that already exists 11466843Sericon your system. You may need to #define OLD_NEWDB 1 to do this.] 11564250Seric 11665910Seric[NOTE WELL: it is CRITICAL that you remove ndbm.o from libdb.a and 11765910Sericndbm.h from the appropriate include directories if you want to get 11865910Sericndbm support. These files OVERRIDE calls to ndbm routines -- in 11965910Sericparticular, if you leave ndbm.h in, you can find yourself using 12065910Sericthe new db package even if you don't define NEWDB.] 12165910Seric 12264250SericIf NEWDB and NDBM are defined (but not NIS), then sendmail will read 12364250SericNDBM format alias files, but the next time a newaliases is run the 12464250Sericformat will be converted to NEWDB; that format will be used forever 12564250Sericmore. This is intended as a transition feature. [Note however that 12664250Sericthe NEWDB library also catches and maps NDBM calls; you will have to 12764250Sericback out this feature to get this to work. See ``Quirks'' section 12864250Sericbelow for details.] 12964250Seric 13064250SericIf all three are defined, sendmail operates as described above, and also 13164250Sericlooks for the file /var/yp/Makefile. If it exists, newaliases will 13264250Sericbuild BOTH the NEWDB and NDBM format alias files. However, it will 13364250Sericonly use the NEWDB file; the NDBM format file is used only by the 13464250SericNIS subsystem. 13564250Seric 13664250SericIf NDBM and NIS are defined (regardless of the definition of NEWDB 13764250Sericor the existance of /var/yp/Makefile), sendmail adds the special 13864250Serictokens "YP_LAST_MODIFIED" and "YP_MASTER_NAME", both of which are 13964250Sericrequired if the NDBM file is to be used as an NIS map. 14064250Seric 14164250SericAll of -DNEWDB, -DNDBM, and -DNIS are normally defined in the DBMDEF 14264250Sericline in the Makefile. 14364250Seric 14464250Seric 14564035Seric+---------------+ 14664035Seric| COMPILE FLAGS | 14764035Seric+---------------+ 14864035Seric 14960565SericWhereever possible, I try to make sendmail pull in the correct 15060584Sericcompilation options needed to compile on various environments based on 15160584Sericautomatically defined symbols. Some machines don't seem to have useful 15260584Sericsymbols availble, requiring the following compilation flags in the 15360584SericMakefile: 15460565Seric 15560565SericSOLARIS Define this if you are running Solaris 2.0 or higher. 15665000SericSOLARIS_2_3 Define this if you are running Solaris 2.3 or higher. 15765108SericSUNOS403 Define this if you are running SunOS 4.0.3. 15864077SericNeXT Define this if you are on a NeXT box. (This one may 15964072Seric be pre-defined for you.) There are other hacks you 16064072Seric have to make -- see below. 16160565Seric_AIX3 Define this if you are IBM AIX 3.x. 16263965SericRISCOS Define this if you are running RISC/os from MIPS. 16366335SericIRIX Define this if you are running IRIX from SGI. 16464501Seric_SCO_unix_ Define this if you are on SCO UNIX. 16565095Seric_SCO_unix_4_2 Define this if you are on SCO Open Server 3.2v4. 16667427SericDGUX Define this if you are on DG/UX 5.4.3 or later 16767427SericDGUX_5_4_2 Define this if you are on DG/UX systems prior to 5.4.3. 16867434SericNonStop_UX_BXX Define this if you are on a Tandem NonStop-UX release 16967434Seric Bxx system. 17060565Seric 17160584SericIf you are a system that sendmail has already been ported to, you 17260584Sericprobably won't have to touch these. But if you are porting, you may 17363962Serichave to tweak the following compilation flags in conf.h in order to 17463962Sericget it to compile and link properly: 17560565Seric 17665195SericSYSTEM5 Adjust for System V (not necessarily Release 4). 17764035SericSYS5SIGNALS Use System V signal semantics -- the signal handler 17864035Seric is automatically dropped when the signal is caught. 17964035Seric If this is not set, use POSIX/BSD semantics, where the 18064035Seric signal handler stays in force until an exec or an 18164035Seric explicit delete. Implied by SYSTEM5. 18264706SericSYS5SETPGRP Use System V setpgrp() semantics. Implied by SYSTEM5. 18364035SericHASFLOCK Set this if you prefer to use the flock(2) system call 18464035Seric rather than using fcntl-based locking. Fcntl locking 18564035Seric has some semantic gotchas, but many vendor systems 18664035Seric also interface it to lockd(8) to do NFS-style locking. 18764035Seric For this reason, this should not be set unless you 18864035Seric don't have an alternative. 18960565SericHASUNAME Set if you have the "uname" system call. Implied by 19060565Seric SYSTEM5. 19163962SericHASUNSETENV Define this if your system library has the "unsetenv" 19263962Seric subroutine. 19360565SericHASSETSID Define this if you have the setsid(2) system call. This 19460565Seric is implied if your system appears to be POSIX compliant. 19560565SericHASINITGROUPS Define this if you have the initgroups(3) routine. 19663753SericHASSETVBUF Define this if you have the setvbuf(3) library call. 19763753Seric If you don't, setlinebuf will be used instead. This 19863753Seric defaults on if your compiler defines __STDC__. 19963902SericHASSETREUID Define this if you have setreuid(2) ***AND*** root can 20063902Seric use setreuid to change to an arbitrary user. This second 20163902Seric condition is not satisfied on AIX 3.x. You may find that 20263902Seric your system has setresuid(2), (for example, on HP-UX) in 20363902Seric which case you will also have to #define setreuid(r, e) 20463902Seric to be the appropriate call. Some systems (such as Solaris) 20565000Seric have a compatibility routine that doesn't work properly, 20665000Seric but may have "saved user ids" properly implemented so you 20765000Seric can ``#define setreuid(r, e) seteuid(e)'' and have it work. 20863902Seric The important thing is that you have a call that will set 20965000Seric the effective uid independently of the real or saved uid 21065000Seric and be able to set the effective uid back again when done. 21165000Seric There's a test program in ../test/t_setreuid.c that will 21265000Seric try things on your system. Setting this improves the 21365000Seric security, since sendmail doesn't have to read .forward 21465000Seric and :include: files as root. There are certain attacks 21565000Seric that may be unpreventable without this call. 21665000SericHASLSTAT Define this if you have symbolic links (and thus the 21765000Seric lstat(2) system call). This improves security. Unlike 21865000Seric most other options, this one is on by default, so you 21965000Seric need to #undef it in conf.h if you don't have symbolic 22065000Seric links (these days everyone does). 22167430SericHASSETRLIMIT Define this to 1 if you have the setrlimit(2) syscall. 22267430Seric You can define it to 0 to force it off. It is assumed 22367430Seric if you are running a BSD-like system. 22467430SericHASULIMIT Define this if you have the ulimit(2) syscall (System V 22567430Seric style systems). HASSETRLIMIT overrides, as it is more 22667430Seric general. 22765206SericNEEDGETOPT Define this if you need a reimplementation of getopt(3). 22865206Seric On some systems, getopt does very odd things if called 22965206Seric to scan the arguments twice. This flag will ask sendmail 23065206Seric to compile in a local version of getopt that works 23165206Seric properly. 23265206SericNEEDSTRTOL Define this if your standard C library does not define 23365206Seric strtol(3). This will compile in a local version. 23465206SericNEEDVPRINTF Define this if your standard C library does not define 23565206Seric vprintf(3). Note that the resulting fake implementation 23665206Seric is not very elegant and may not even work on some 23765206Seric architectures. 23866792SericNEEDFSYNC Define this if your standard C library does not define 23966792Seric fsync(2). This will try to simulate the operation using 24066792Seric fcntl(2); if that is not available it does nothing, which 24166792Seric isn't great, but at least it compiles and runs. 24265211SericHASGETUSERSHELL Define this to 1 if you have getusershell(3) in your 24365211Seric standard C library. If this is not defined, or is defined 24465211Seric to be 0, sendmail will scan the /etc/shells file (no 24565211Seric NIS-style support, defaults to /bin/sh and /bin/csh if 24665211Seric that file does not exist) to get a list of unrestricted 24765211Seric user shells. This is used to determine whether users 24865211Seric are allowed to forward their mail to a program or a file. 24963937SericGIDSET_T The type of entries in a gidset passed as the second 25063937Seric argument to getgroups(2). Historically this has been an 25163937Seric int, so this is the default, but some systems (such as 25263937Seric IRIX) pass it as a gid_t, which is an unsigned short. 25363937Seric This will make a difference, so it is important to get 25463937Seric this right! However, it is only an issue if you have 25563937Seric group sets. 25663968SericSLEEP_T The type returned by the system sleep() function. 25763968Seric Defaults to "unsigned int". Don't worry about this 25863968Seric if you don't have compilation problems. 25963974SericARBPTR_T The type of an arbitrary pointer -- defaults to "void *". 26063974Seric If you are an very old compiler you may need to define 26163974Seric this to be "char *". 26260584SericLA_TYPE The type of load average your kernel supports. These 26366301Seric can be one of: 26466301Seric LA_ZERO (1) -- it always returns the load average as 26566301Seric "zero" (and does so on all architectures). 26666301Seric LA_SUBR (4) if you have the getloadavg(3) routine, 26764376Seric LA_MACH (5) to use MACH-style load averages (calls 26866301Seric processor_set_info()), 26966301Seric LA_PROCSTR (7) to read /proc/loadavg and interpret it 27066301Seric as a string representing a floating-point 27166301Seric number (Linux-style), 27266301Seric LA_FLOAT (3) if you read kmem and interpret the value 27366301Seric as a floating point number, 27466301Seric LA_INT (2) to interpret as a long integer, 27566301Seric LA_SHORT (6) to interpret as a short integer. 27666301Seric These last three have several other parameters that they 27766301Seric try to divine: the name of your kernel, the name of the 27866301Seric variable in the kernel to examine, the number of bits of 27966301Seric precision in a fixed point load average, and so forth. 28066301Seric In desperation, use LA_ZERO. The actual code is in 28166301Seric conf.c -- it can be tweaked if you are brave. 28265752SericSFS_TYPE Encodes how your kernel can locate the amount of free 28365752Seric space on a disk partition. This can be set to SFS_NONE 28465752Seric (0) if you have no way of getting this information, 28565752Seric SFS_USTAT (1) if you have the ustat(2) system call, 28665752Seric SFS_4ARGS (2) if you have a four-argument statfs(2) 28765752Seric system call (and the include file is <sys/statfs.h>), 28867161Seric SFS_VFS (3), SFS_MOUNT (4), SFS_STATFS (5) if you have 28967161Seric the two-argument statfs(2) system call with includes in 29067161Seric <sys/vfs.h>, <sys/mount.h>, or <sys/statfs.h> respectively, 29167161Seric or SFS_STATVFS (6) if you have the two-argument statvfs(2) 29267161Seric call. The default if nothing is defined is SFS_NONE. 293*67770SericSPT_TYPE Encodes how your system can display what a process is doing 294*67770Seric on a ps(1) command (SPT stands for Set Process Title). Can 295*67770Seric be set to: 296*67770Seric SPT_NONE (0) -- Don't try to set the process title at all. 297*67770Seric SPT_REUSEARGV (1) -- Pad out your argv with the information; 298*67770Seric this is the default if none specified. 299*67770Seric SPT_BUILTIN (2) -- The system library has setproctitle. 300*67770Seric SPT_PSTAT (3) -- Use the PSTAT_SETCMD option to pstat(2) 301*67770Seric to set the process title; this is used by HP-UX. 302*67770Seric SPT_PSSTRINGS (4) -- Use the magic PS_STRINGS pointer (4.4BSD). 303*67770SericSPT_PADCHAR Character used to pad the process title; if undefined, 304*67770Seric the space character (0x20) is used. This is ignored if 305*67770Seric SPT_TYPE != SPT_REUSEARGV 30663962SericERRLIST_PREDEFINED 30763962Seric If set, assumes that some header file defines sys_errlist. 30863962Seric This may be needed if you get type conflicts on this 30963962Seric variable -- otherwise don't worry about it. 31064562SericWAITUNION The wait(2) routine takes a "union wait" argument instead 31164562Seric of an integer argument. This is for compatibility with 31264562Seric old versions of BSD. 31365000SericSCANF You can set this to extend the F command to accept a 31465000Seric scanf string -- this gives you a primitive parser for 31565000Seric class definitions -- BUT it can make you vulnerable to 31665000Seric core dumps if the target file is poorly formed. 31765095SericSYSLOG_BUFSIZE You can define this to be the size of the buffer that 31865095Seric syslog accepts. If it is not defined, it assumes a 31965095Seric 1024-byte buffer. If the buffer is very small (under 32065095Seric 256 bytes) the log message format changes -- each 32165095Seric e-mail message will log many more messages, since it 32265095Seric will log each piece of information as a separate line 32365095Seric in syslog. 32466318SericBROKEN_RES_SEARCH 32566318Seric On Ultrix (and maybe other systems?) if you use the 32666318Seric res_search routine with an unknown host name, it returns 32766318Seric -1 but sets h_errno to 0 instead of HOST_NOT_FOUND. If 32866318Seric you set this, sendmail considers 0 to be the same as 32966318Seric HOST_NOT_FOUND. 33067436SericNAMELISTMASK If defined, values returned by nlist(3) are masked 33167436Seric against this value before use -- a common value is 33267436Seric 0x7fffffff to strip off the top bit. 33360565Seric 33464035Seric 33567436Seric 33664035Seric+-----------------------+ 33764035Seric| COMPILE-TIME FEATURES | 33864035Seric+-----------------------+ 33964035Seric 34060584SericThere are a bunch of features that you can decide to compile in, such 34160584Sericas selecting various database packages and special protocol support. 34260584SericSeveral are assumed based on other compilation flags -- if you want to 34360584Seric"un-assume" something, you probably need to edit conf.h. Compilation 34460584Sericflags that add support for special features include: 34560565Seric 34660565SericNDBM Include support for "new" DBM library for aliases and maps. 34764250Seric Normally defined in the Makefile. 34860565SericNEWDB Include support for Berkeley "db" package (hash & btree) 34964250Seric for aliases and maps. Normally defined in the Makefile. 35066843SericOLD_NEWDB If non-zero, the version of NEWDB you have is the old 35166843Seric one that does not include the "fd" call. This call was 35266843Seric added in version 1.5 of the Berkeley DB code. If you 35366843Seric use -DOLD_NEWDB=0 it forces you to use the new interface. 35460565SericNIS Define this to get NIS (YP) support for aliases and maps. 35564250Seric Normally defined in the Makefile. 35660565SericUSERDB Include support for the User Information Database. Implied 35764250Seric by NEWDB in conf.h. 35865000SericIDENTPROTO Define this as 1 to get IDENT (RFC 1413) protocol support. 35960565Seric This is assumed unless you are running on Ultrix or 36060565Seric HP-UX, both of which have a problem in the UDP 36165000Seric implementation. You can define it to be 0 to explicitly 36265000Seric turn off IDENT protocol support. 36360565SericMIME Include support for MIME-encapsulated error messages. 36460565SericLOG Set this to get syslog(3) support. Defined by default 36560584Seric in conf.h. You want this if at all possible. 36660565SericNETINET Set this to get TCP/IP support. Defined by default 36760584Seric in conf.h. You probably want this. 36860565SericNETISO Define this to get ISO networking support. 36960565SericSMTP Define this to get the SMTP code. Implied by NETINET 37060565Seric or NETISO. 37160565SericNAMED_BIND Define this to get DNS (name daemon) support, including 37260565Seric MX support. The specs you must use this if you run 37360565Seric SMTP. Defined by default in conf.h. 37460565SericQUEUE Define this to get queueing code. Implied by NETINET 37560584Seric or NETISO; required by SMTP. This gives you other good 37660584Seric stuff -- it should be on. 37760565SericDAEMON Define this to get general network support. Implied by 37860584Seric NETINET or NETISO. Defined by default in conf.h. You 37960584Seric almost certainly want it on. 38060565SericMATCHGECOS Permit fuzzy matching of user names against the full 38160565Seric name (GECOS) field in the /etc/passwd file. This should 38260565Seric probably be on, since you can disable it from the config 38360584Seric file if you want to. Defined by default in conf.h. 38460565Seric 38564035Seric 38665000Seric+---------------------+ 38765000Seric| DNS/RESOLVER ISSUES | 38865000Seric+---------------------+ 38965000Seric 39065000SericMany systems have old versions of the resolver library. At a minimum, 39165000Sericyou should be running BIND 4.8.3; older versions may compile, but they 39265000Serichave known bugs that should give you pause. 39365000Seric 39465000SericCommon problems in old versions include "undefined" errors for 39565000Sericdn_skipname. 39665000Seric 39765000SericSome people have had a problem with BIND 4.9; it uses some routines 39865000Sericthat it expects to be externally defined such as strerror(). It may 39965000Serichelp to link with "-l44bsd" to solve this problem. 40065000Seric 40165095Seric!PLEASE! be sure to link with the same version of the resolver as 40265095Sericthe header files you used -- some people have used the 4.9 headers 40365095Sericand linked with BIND 4.8 or vice versa, and it doesn't work. 40465095SericUnfortunately, it doesn't fail in an obvious way -- things just 40565954Sericsubtly don't work. 40665000Seric 40765095Seric 40864035Seric+-------------------------------------+ 40964035Seric| OPERATING SYSTEM AND COMPILE QUIRKS | 41064035Seric+-------------------------------------+ 41164035Seric 41265095SericGCC 2.5.x problems *** IMPORTANT *** 41365095Seric Date: Mon, 29 Nov 93 19:08:44 PST 41465095Seric From: wilson@cygnus.com (Jim Wilson) 41565095Seric Message-Id: <9311300308.AA04608@cygnus.com> 41665095Seric To: kenner@vlsi1.ultra.nyu.edu 41765095Seric Subject: [cattelan@thebarn.com: gcc 2.5.4-2.5.5 -O bug] 41865095Seric Cc: cattelan@thebarn.com, rms@gnu.ai.mit.edu, sendmail@cs.berkeley.edu 41965095Seric 42065095Seric This fixes a problem that occurs when gcc 2.5.5 is used to compile 42165095Seric sendmail 8.6.4 with optimization on a sparc. 42265095Seric 42365095Seric Mon Nov 29 19:00:14 1993 Jim Wilson (wilson@sphagnum.cygnus.com) 42465095Seric 42565095Seric * reload.c (find_reloads_toplev): Replace obsolete reference to 42665095Seric BYTE_LOADS_*_EXTEND with LOAD_EXTEND_OP. 42765095Seric 42865095Seric *** clean-ss-931128/reload.c Sun Nov 14 16:20:01 1993 42965095Seric --- ss-931128/reload.c Mon Nov 29 18:52:55 1993 43065095Seric *************** find_reloads_toplev (x, opnum, type, ind 43165095Seric *** 3888,3894 **** 43265095Seric force a reload in that case. So we should not do anything here. */ 43365095Seric 43465095Seric else if (regno >= FIRST_PSEUDO_REGISTER 43565095Seric ! #if defined(BYTE_LOADS_ZERO_EXTEND) || defined(BYTE_LOADS_SIGN_EXTEND) 43665095Seric && (GET_MODE_SIZE (GET_MODE (x)) 43765095Seric <= GET_MODE_SIZE (GET_MODE (SUBREG_REG (x)))) 43865095Seric #endif 43965095Seric --- 3888,3894 ---- 44065095Seric force a reload in that case. So we should not do anything here. */ 44165095Seric 44265095Seric else if (regno >= FIRST_PSEUDO_REGISTER 44365095Seric ! #ifdef LOAD_EXTEND_OP 44465095Seric && (GET_MODE_SIZE (GET_MODE (x)) 44565095Seric <= GET_MODE_SIZE (GET_MODE (SUBREG_REG (x)))) 44665095Seric #endif 44765095Seric 44865095Seric 44964376SericSunOS 4.x (Solaris 1.x) 45064376Seric You may have to use -lresolv on SunOS. However, beware that 45164376Seric this links in a new version of gethostbyname that does not 45264376Seric understand NIS, so you must have all of your hosts in DNS. 45364035Seric 45464798Seric Some people have reported problems with the SunOS version of 45564798Seric -lresolv and/or in.named, and suggest that you get a newer 45664798Seric version. The symptoms are delays when you connect to the 45765000Seric SMTP server on a SunOS machine or having your domain added to 45865000Seric addresses inappropriately. There is a version of BIND 45964798Seric version 4.9 on gatekeeper.DEC.COM in pub/BSD/bind/4.9. 46064798Seric 46164400Seric There is substantial disagreement about whether you can make 46264400Seric this work with resolv+, which allows you to specify a search-path 46364400Seric of services. Some people report that it works fine, others 46464400Seric claim it doesn't work at all (including causing sendmail to 46564400Seric drop core when it tries to do multiple resolv+ lookups for a 46664400Seric single job). I haven't tried resolv+, as we use DNS exclusively. 46764400Seric 46864400Seric Should you want to try resolv+, it is on ftp.uu.net in 46964400Seric /networking/ip/dns. 47064400Seric 47167161Seric Apparently getservbyname() can fail under moderate to high 47267161Seric load under some circumstances. This will exhibit itself as 47367161Seric the message ``554 makeconnection: service "smtp" unknown''. 47467161Seric The problem has been traced to one or more blank lines in 47567161Seric /etc/services on the NIS server machine. Delete these 47667161Seric and it should work. This info is thanks to Brian Bartholomew 47767161Seric <bb@math.ufl.edu> of I-Kinetics, Inc. 47867161Seric 47964376SericSolaris 2.x (SunOS 5.x) 48064376Seric To compile for Solaris, be sure you use -DSOLARIS. 48164376Seric 48266329Seric To the best of my knowledge, Solaris does not have the 48366329Seric gethostbyname problem described above. However, it does 48466329Seric have another one: 48566329Seric 48664364Seric From a correspondent: 48764364Seric 48864364Seric For solaris 2.2, I have 48964364Seric 49064364Seric hosts: files dns 49164364Seric 49264364Seric in /etc/nsswitch.conf and /etc/hosts has to have the fully 49364364Seric qualified host name. I think "files" has to be before "dns" 49464364Seric in /etc/nsswitch.conf during bootup. 49564364Seric 49666329Seric From another correspondent: 49764376Seric 49866329Seric When running sendmail under Solaris, the gethostbyname() 49966329Seric hack in conf.c which should perform proper canonicalization 50066329Seric of host names could fail. Result: the host name is not 50166329Seric canonicalized despite the hack, and you'll have to define $j 50266329Seric and $m in sendmail.cf somewhere. 50366329Seric 50466329Seric The reason could be that /etc/nsswitch.conf is improperly 50566329Seric configured (at least from sendmail's point of view). For 50666329Seric example, the line 50766329Seric 50866329Seric hosts: files nisplus dns 50966329Seric 51066329Seric will make gethostbyname() look in /etc/hosts first, then ask 51166329Seric nisplus, then dns. However, if /etc/hosts does not contain 51266329Seric the full canonicalized hostname, then no amount of 51366329Seric gethostbyname()s will work. 51466329Seric 51566329Seric Solution (or rather, a workaround): Ask nisplus first, then 51666329Seric dns, then local files: 51766329Seric 51866329Seric hosts: nisplus dns [NOTFOUND=return] files 51966329Seric 52064385Seric The Solaris "syslog" function is apparently limited to something 52164385Seric about 90 characters because of a kernel limitation. If you have 52266023Seric source code, you can probably up this number. You can get patches 52366023Seric that fix this problem: the patch ids are: 52464385Seric 52566023Seric Solaris 2.1 100834 52666023Seric Solaris 2.2 100999 52766024Seric Solaris 2.3 101318 52866023Seric 52966023Seric Be sure you have the appropriate patch installed or you won't 53066023Seric see system logging. 53166023Seric 53264250SericOSF/1 53365000Seric If you are compiling on OSF/1 (DEC Alpha), you must use 53465616Seric -L/usr/shlib (otherwise it core dumps on startup). You may also 53565000Seric need -mld to get the nlist() function, although some versions 53665000Seric apparently don't need this. 53765000Seric 53865000Seric Also, the enclosed makefile removed /usr/sbin/smtpd; if you need 53965000Seric it, just create the link to the sendmail binary. 54057977Seric 54166335SericIRIX 54266335Seric The header files on SGI IRIX are completely prototyped, and as 54366335Seric a result you can sometimes get some warning messages during 54466335Seric compilation. These can be ignored. There are two errors in 54566335Seric deliver only if you are using gcc, both of the form ``warning: 54666335Seric passing arg N of `execve' from incompatible pointer type''. 54766335Seric Also, if you compile with -DNIS, you will get a complaint 54866335Seric about a declaration of struct dom_binding in a prototype 54966335Seric when compiling map.c; this is not important because the 55066335Seric function being prototyped is not used in that file. 55166335Seric 55267674Seric In order to compile sendmail you will have had to install 55367674Seric the developers' option in order to get the necessary include 55467674Seric files. 55567674Seric 55664250SericNeXT 55764250Seric If you are compiling on NeXT, you will have to create an empty 55864250Seric file "unistd.h" and create a file "dirent.h" containing: 55963753Seric 56064250Seric #include <sys/dir.h> 56164250Seric #define dirent direct 56264035Seric 56364250Seric (The Makefile.NeXT should try to do both of these for you.) 56464077Seric 56564364Seric Apparently, there is a bug in getservbyname on Nextstep 3.0 56664364Seric that causes it to fail under some circumstances with the 56764364Seric message "SYSERR: service "smtp" unknown" logged. You should 56864364Seric be able to work around this by including the line: 56964364Seric 57064670Seric OOPort=25 57164364Seric 57264364Seric in your .cf file. 57364364Seric 57464376Seric You may have to use -DNeXT. 57564376Seric 57665000SericBSDI (BSD/386) 1.0, NetBSD 0.9, FreeBSD 1.0 57765000Seric The "m4" from BSDI won't handle the config files properly. 57865000Seric I haven't had a chance to test this myself. 57957943Seric 58065000Seric The M4 shipped in FreeBSD and NetBSD 0.9 don't handle the config 58165000Seric files properly. One must use either GNU m4 1.1 or the PD-M4 58265000Seric recently posted in comp.os.386bsd.bugs (and maybe others). 58365000Seric NetBSD-current includes the PD-M4 (as stated in the NetBSD file 58465000Seric CHANGES). 58565000Seric 58665000Seric FreeBSD 1.0 RELEASE has uname(2) now. Use -DUSEUNAME in order to 58765000Seric use it (look into Makefile.FreeBSD). NetBSD-current may have 58865000Seric it too but it has not been verified. 58965000Seric 59065000Seric You cannot port the latest version of the Berkeley db library 59165000Seric and use it with sendmail without recompiling the world. This 59265000Seric is because C library routines use the older version which have 59365000Seric incompatible header files -- the result is that it can't read 59465000Seric other system files, such as /etc/passwd, unless you use the 59565000Seric new db format throughout your system. You should normally just 59665000Seric use the version of db supplied in your release. You may need 59766843Seric to use -DOLD_NEWDB=1 to make this work -- this turns off some 59865000Seric new interface calls (for file locking) that are not in older 59965000Seric versions of db. You'll get compile errors if you need this 60065000Seric flag and don't have it set. 60165000Seric 60264364Seric4.3BSD 60364364Seric If you are running a "virgin" version of 4.3BSD, you'll have 60464364Seric a very old resolver and be missing some header files. The 60564364Seric header files are simple -- create empty versions and everything 60664364Seric will work fine. For the resolver you should really port a new 60764364Seric version (4.8.3 or later) of the resolver; 4.9 is available on 60864364Seric gatekeeper.DEC.COM in pub/BSD/bind/4.9. If you are really 60964364Seric determined to continue to use your old, buggy version (or as 61064364Seric a shortcut to get sendmail working -- I'm sure you have the 61164364Seric best intentions to port a modern version of BIND), you can 61264364Seric copy ../contrib/oldbind.compat.c into src and add 61364364Seric oldbind.compat.o to OBJADD in the Makefile. 61464364Seric 61564718SericA/UX 61664718Seric Date: Tue, 12 Oct 1993 18:28:28 -0400 (EDT) 61764718Seric From: "Eric C. Hagberg" <hagberg@med.cornell.edu> 61864718Seric Subject: Fix for A/UX ndbm 61964718Seric 62064718Seric I guess this isn't really a sendmail bug, however, it is something 62164718Seric that A/UX users should be aware of when compiling sendmail 8.6. 62264718Seric 62364718Seric Apparently, the calls that sendmail is using to the ndbm routines 62464718Seric in A/UX 3.0.x contain calls to "broken" routines, in that the 62564718Seric aliases database will break when it gets "just a little big" 62664718Seric (sorry I don't have exact numbers here, but it broke somewhere 62764718Seric around 20-25 aliases for me.), making all aliases non-functional 62864718Seric after exceeding this point. 62964718Seric 63064718Seric What I did was to get the gnu-dbm-1.6 package, compile it, and 63164718Seric then re-compile sendmail with "-lgdbm", "-DNDBM", and using the 63264718Seric ndbm.h header file that comes with the gnu-package. This makes 63364718Seric things behave properly. 63464718Seric 63564718Seric I suppose porting the New Berkeley db package is another route, 63664718Seric however, I made a quick attempt at it, and found it difficult 63764718Seric (not easy at least); the gnu-dbm package "configured" and 63864718Seric compiled easily. 63964718Seric 64064718SericDG/UX 64164718Seric Apparently, /bin/mail doesn't work properly for delivery on 64264718Seric DG/UX -- the person who has this working, Douglas Anderson 64367427Seric <dlander@afterlife.ncsc.mil>, used procmail instead. The 64467427Seric problem is that DG/UX /bin/mail requires that an environment 64567427Seric variable be set (_FORCE_MAIL_LOCAL_=yes); sendmail has no 64667427Seric mechanism for this. Several people report that procmail works 64767427Seric beautifully. 64864718Seric 64965820SericApollo DomainOS 65065820Seric If you are compiling on Apollo, you will have to create an empty 65165820Seric file "unistd.h" and create a file "dirent.h" containing: 65265820Seric 65365820Seric #include <sys/dir.h> 65465820Seric #define dirent direct 65565820Seric 65665820Seric (The Makefile.DomainOS will attempt to do both of these for you.) 65765820Seric 65865910SericHP-UX 8.00 65965910Seric Date: Mon, 24 Jan 1994 13:25:45 +0200 66065910Seric From: Kimmo Suominen <Kimmo.Suominen@lut.fi> 66165910Seric Subject: 8.6.5 w/ HP-UX 8.00 on s300 66265910Seric 66365910Seric Just compiled and fought with sendmail 8.6.5 on a HP9000/360 (ie. a 66465910Seric series 300 machine) running HP-UX 8.00. 66565910Seric 66665910Seric I was getting segmentation fault when delivering to a local user. 66765910Seric With debugging I saw it was faulting when doing _free@libc... *sigh* 66865910Seric It seems the new implementation of malloc on s300 is buggy as of 8.0, 66965910Seric so I tried out the one in -lmalloc (malloc(3X)). With that it seems 67065910Seric to work just dandy. 67165910Seric 67265910Seric When linking, you will get the following error: 67365910Seric 67465910Seric ld: multiply defined symbol _freespace in file /usr/lib/libmalloc.a 67565910Seric 67665910Seric but you can just ignore it. You might want to add this info to the 67765910Seric README file for the future... 67865910Seric 67965910SericLinux 68065910Seric Something broke between versions 0.99.13 and 0.99.14 of Linux: 68165910Seric the flock() system call gives errors. If you are running .14, 68265910Seric you must not use flock. You can do this with -DHASFLOCK=0. 68365910Seric 68465910SericAIX 68565910Seric This version of sendmail does not support MB, MG, and MR resource 68665910Seric records, which are supported by AIX sendmail. 68765910Seric 68866335SericRISC/os 68966335Seric RISC/os from MIPS is a merged AT&T/Berkeley system. When you 69066335Seric compile on that platform you will get duplicate definitions 69166335Seric on many files. You can ignore these. 69266335Seric 69365195SericSystem V Release 4 Based Systems 69465195Seric There is a single Makefile that is intended for all SVR4-based 69565195Seric systems (called Makefile.SVR4). It defines __svr4__, which is 69665195Seric predefined by some compilers. If your compiler already defines 69765195Seric this compile variable, you can delete the definition from the 69865195Seric Makefile. 69965195Seric 70065195Seric It's been tested on Dell Issue 2.2. 70165195Seric 70265095SericDELL SVR4 70365095Seric Date: Mon, 06 Dec 1993 10:42:29 EST 70465095Seric From: "Kimmo Suominen" <kim@grendel.lut.fi> 70565095Seric Message-ID: <2d0352f9.lento29@lento29.UUCP> 70665095Seric To: eric@cs.berkeley.edu 70765166Seric Cc: sendmail@cs.berkeley.edu 70865095Seric Subject: Notes for DELL SVR4 70965095Seric 71065095Seric Eric, 71165095Seric 71265095Seric Here are some notes for compiling Sendmail 8.6.4 on DELL SVR4. I ran 71365095Seric across these things when helping out some people who contacted me by 71465095Seric e-mail. 71565095Seric 71665095Seric 1) Use gcc 2.4.5 (or later?). Dell distributes gcc 2.1 with their 71765095Seric Issue 2.2 Unix. It is too old, and gives you problems with 71865095Seric clock.c, because sigset_t won't get defined in <sys/signal.h>. 71965095Seric This is due to a problematic protection rule in there, and is 72065095Seric fixed with gcc 2.4.5. 72165095Seric 72265095Seric 2) If you don't use the new Berkeley DB (-DNEWDB), then you need 72365095Seric to add "-lc -lucb" to the libraries to link with. This is because 72465095Seric the -ldbm distributed by Dell needs the bcopy, bcmp and bzero 72565095Seric functions. It is important that you specify both libraries in 72665095Seric the given order to be sure you only get the BSTRING functions 72765095Seric from the UCB library (and not the signal routines etc.). 72865095Seric 72965095Seric 3) Don't leave out "-lelf" even if compiling with "-lc -lucb". 73065095Seric The UCB library also has another copy of the nlist routines, 73165095Seric but we do want the ones from "-lelf". 73265095Seric 73365095Seric If anyone needs a compiled gcc 2.4.5 and/or a ported DB library, they 73465095Seric can use anonymous ftp to fetch them from lut.fi in the /kim directory. 73565095Seric They are copies of what I use on grendel.lut.fi, and offering them 73665095Seric does not imply that I would also support them. I have sent the DB 73765095Seric port for SVR4 back to Keith Bostic for inclusion in the official 73865095Seric distribution, but I haven't heard anything from him as of today. 73965095Seric 74065095Seric - gcc-2.4.5-svr4.tar.gz (gcc 2.4.5 and the corresponding libg++) 74165095Seric - db-1.72.tar.gz (with source, objects and a installed copy) 74265095Seric 74365095Seric Cheers 74465095Seric + Kim 74565095Seric -- 74665095Seric * Kimmo.Suominen@lut.fi * SysVr4 enthusiast at GRENDEL.LUT.FI * 74765095Seric * KIM@FINFILES.BITNET * Postmaster and Hostmaster at LUT.FI * 74865095Seric * + 358 200 865 718 * Unix area moderator at NIC.FUNET.FI * 74965095Seric 75067267SericConvexOS 10.1 and below 75167267Seric In order to use the name server, you must create the file 75267267Seric /etc/use_nameserver. If this file does not exist, the call 75367267Seric to res_init() will fail and you will have absolutely no 75467267Seric access to DNS, including MX records. 75565095Seric 75664718SericNon-DNS based sites 75764718Seric This version of sendmail always tries to connect to the Domain 75864718Seric Name System (DNS) to resolve names, regardless of the setting 75964718Seric of the `I' option. On most systems that are not running DNS, 76064718Seric this will fail quickly and sendmail will continue, but on some 76164718Seric systems it has a long timeout. If you have this problem, you 76264718Seric will have to recompile without NAMED_BIND. Some people have 76364718Seric claimed that they have successfully used "OI+USEVC" to force 76464718Seric sendmail to use a virtual circuit -- this will always time out 76564718Seric quickly, but also tells sendmail that a failed connection 76664718Seric should requeue the message (probably not what you intended). 76764718Seric A future release of sendmail will correct this problem. 76864718Seric 76964250SericBoth NEWDB and NDBM 77064250Seric If you use both -DNDBM and -DNEWDB, you must delete the module 77164250Seric ndbm.o from libdb.a and delete the file "ndbm.h" from the files 77264250Seric that get installed (that is, use the OLD ndbm.h, not the new 77364250Seric ndbm.h). This compatibility module maps ndbm calls into DB 77464250Seric calls, and breaks things rather badly. 77558709Seric 77664559SericGNU getopt 77764559Seric I'm told that GNU getopt has a problem in that it gets confused 77864559Seric by the double call. Use the version in conf.c instead. 77964250Seric 78066350SericBIND 4.9.2 and Ultrix 78167206Seric If you are running on Ultrix, be sure you read conf/Info.Ultrix 78267206Seric in the BIND distribution very carefully -- there is information 78367206Seric in there that you need to know in order to avoid errors of the 78467206Seric form: 78564559Seric 78666350Seric /lib/libc.a(gethostent.o): sethostent: multiply defined 78766350Seric /lib/libc.a(gethostent.o): endhostent: multiply defined 78866350Seric /lib/libc.a(gethostent.o): gethostbyname: multiply defined 78966350Seric /lib/libc.a(gethostent.o): gethostbyaddr: multiply defined 79066350Seric 79166350Seric during the link stage. 79266350Seric 79366350Seric 79464820Seric+--------------+ 79564820Seric| MANUAL PAGES | 79664820Seric+--------------+ 79764820Seric 79864820SericThe manual pages have been written against the -mandoc macros 79964820Sericinstead of the -man macros. The latest version of groff has them 80064820Sericincluded. You can also get a copy from FTP.UU.NET in directory 80164820Seric/systems/unix/bsd-sources/share/tmac. 80264820Seric 80364820Seric 80465151Seric+-----------------+ 80565151Seric| DEBUGGING HOOKS | 80665151Seric+-----------------+ 80765151Seric 80865151SericAs of 8.6.5, sendmail daemons will catch a SIGUSR1 signal and log 80965151Sericsome debugging output (logged at LOG_DEBUG severity). The 81065151Sericinformation dumped is: 81165151Seric 81265151Seric * The value of the $j macro. 81365151Seric * A warning if $j is not in the set $=w. 81465151Seric * A list of the open file descriptors. 81565151Seric * The contents of the connection cache. 81665151Seric * If ruleset 89 is defined, it is evaluated and the results printed. 81765151Seric 81865151SericThis allows you to get information regarding the runtime state of the 81965151Sericdaemon on the fly. This should not be done too frequently, since 82065151Sericthe process of rewriting may lose memory which will not be recovered. 82165151SericAlso, ruleset 89 may call non-reentrant routines, so there is a small 82265151Sericnon-zero probability that this will cause other problems. It is 82365151Sericreally only for debugging serious problems. 82465151Seric 82565151SericA typical formulation of ruleset 89 would be: 82665151Seric 82765151Seric R$* $@ $>0 some test address 82865151Seric 82965151Seric 83064035Seric+-----------------------------+ 83164035Seric| DESCRIPTION OF SOURCE FILES | 83264035Seric+-----------------------------+ 83364035Seric 8349881SericThe following list describes the files in this directory: 8355369Seric 83657418SericMakefile The makefile used here; this version only works with 83757418Seric the new Berkeley make. 83857418SericMakefile.dist A trimmed down version of the makefile that works with 83957418Seric the old make. 8405369SericREAD_ME This file. 84160565SericTRACEFLAGS My own personal list of the trace flags -- not guaranteed 84260565Seric to be particularly up to date. 8435369Sericalias.c Does name aliasing in all forms. 8449881Sericarpadate.c A subroutine which creates ARPANET standard dates. 8459881Sericclock.c Routines to implement real-time oriented functions 8469881Seric in sendmail -- e.g., timeouts. 8475369Sericcollect.c The routine that actually reads the mail into a temp 8485369Seric file. It also does a certain amount of parsing of 8495369Seric the header, etc. 8505369Sericconf.c The configuration file. This contains information 8515369Seric that is presumed to be quite static and non- 8525369Seric controversial, or code compiled in for efficiency 8535369Seric reasons. Most of the configuration is in sendmail.cf. 8549881Sericconf.h Configuration that must be known everywhere. 8555369Sericconvtime.c A routine to sanely process times. 8569881Sericdaemon.c Routines to implement daemon mode. This version is 8579881Seric specifically for Berkeley 4.1 IPC. 8585369Sericdeliver.c Routines to deliver mail. 85960565Sericdomain.c Routines that interface with DNS (the Domain Name 86060565Seric System). 8615369Sericerr.c Routines to print error messages. 8629881Sericenvelope.c Routines to manipulate the envelope structure. 8635369Sericheaders.c Routines to process message headers. 8645369Sericmacro.c The macro expander. This is used internally to 8655369Seric insert information from the configuration file. 8665369Sericmain.c The main routine to sendmail. This file also 8675369Seric contains some miscellaneous routines. 86860565Sericmap.c Support for database maps. 86960565Sericmci.c Routines that handle mail connection information caching. 8709881Sericparseaddr.c The routines which do address parsing. 8715369Sericqueue.c Routines to implement message queueing. 8725369Sericreadcf.c The routine that reads the configuration file and 8735369Seric translates it to internal form. 8749881Sericrecipient.c Routines that manipulate the recipient list. 8755369Sericsavemail.c Routines which save the letter on processing errors. 8765369Sericsendmail.h Main header file for sendmail. 8775369Sericsrvrsmtp.c Routines to implement server SMTP. 8785369Sericstab.c Routines to manage the symbol table. 8795369Sericstats.c Routines to collect and post the statistics. 8805369Sericsysexits.c List of error messages associated with error codes 8815369Seric in sysexits.h. 8829881Serictrace.c The trace package. These routines allow setting and 8839881Seric testing of trace flags with a high granularity. 88460565Sericudb.c The user database interface module. 8855369Sericusersmtp.c Routines to implement user SMTP. 8865369Sericutil.c Some general purpose routines used by sendmail. 88760565Sericversion.c The version number and information about this 88860565Seric version of sendmail. Theoretically, this gets 88960565Seric modified on every change. 8905369Seric 8915369SericEric Allman 8925369Seric 893*67770Seric(Version 8.71, last update 09/09/94 16:46:51) 894