The make(1) program is used to compile and install sendmail.
The makesendmail script not only created an obj.
directory, it also copied an appropriate Makefile into that directory.
Before changing anything in Makefile, you should cd into
your object directory and change the permissions of Makefile
so that it is writable by you:
 Actually, it created a symbolic link called Makefile that points to the appropriate file in the ../Makefiles directory.
mv Makefile Makefile.orig%
cp Makefile.orig Makefile%
chmod 644 Makefile
Makefile is tuned by defining or redefining directives (shown in Table 18.1 that begin lines in that file.
|Section 18.4.1, "DBMDEF="||Which database libraries to use|
|Section 18.4.2, "ENVDEF="||Compiler |
|Section 18.4.3, "INCDIRS="||Compiler |
|Section 18.4.4, "LDOPTS="||Linker options, such as |
|Section 18.4.5, "LIBDIRS="||Linker |
|Section 18.4.6, "LIBS="||Linker |
|Section 18.4.7, "BINDIR="||Where to install sendmail|
|Section 18.4.8, "STDIR="||Where the sendmail.st file goes|
|Section 18.4.9, "HFDIR="||Where the sendmail.hf file goes|
|Section 18.4.10, "OBJADD="||Object files that need to be linked in|
We will discuss each of these macros shortly but first note that, in general, you should never have to modify anything after the "end" line (shown in the following example). The only exception might be special requirements created by porting sendmail to a new platform.
################### end of user configuration flags ######################
Finally, before changing anything inside Makefile, be sure to read src/READ_ME. It always contains the latest information about building sendmail. In this book we are forced to speak in generalities, whereas the src/READ_ME file discusses operating systems, compilers, and hardware in specific detail.
The DBMDEF= directive defines the database library support you want. The currently available choices are listed in Table 18.2. Details are given in the indicated section.
|AUTO_NIS_ALIASES||Section 18.8.1, AUTO-NIS-ALIASES||Yes||Add fallback alias techniques|
|HESIOD||Section 18.8.10, HESIOD||Yes||Support hesiod database maps|
|LDAPMAP||Section 18.8.15, LDAPMAP||No||Enable use of ldap databases|
|NDBM||Section 18.8.24, NDBM||Yes||Support UNIX ndbm(3) Databases|
|NETINFO||Section 18.8.27, NETINFO||Yes||Support NeXT netinfo(3) databases|
|NEWDB||Section 18.8.28, NEWDB||Yes||Support db(3), both hash and btree forms|
|NIS||Section 18.8.29, NIS||Yes||Support |
|NISPLUS||Section 18.8.30, NISPLUS||Yes||Support |
|OLD_NEWDB||Section 18.8.33, OLD-NEWDB||n/a||Support the old form of db(3)|
|UDB_DEFAULT_SPEC||Section 18.8.53, UDB-DEFAULT-SPEC||n/a||Default User Database location|
|USERDB||Section 18.8.54, USERDB||n/a||Support the User Database|
 Note that the old dbm(3) form of database is no longer supported.
 If yes, this database format supports aliasing.
Either NDBM or NEWDB must be defined, or sendmail will read the aliases into its symbol table every time it starts. This will make sendmail crawl and is not recommended.
External databases can be extremely valuable, especially in providing easy solutions for complex problems. Therefore we recommend that you include a definition for all databases that your system supports, even if you don't immediately foresee a need for them.
Below, we illustrate the selection of two forms of database:
DBMDEF= -DNEWDB -DNDBM
When these two forms are selected, old databases are read by using NDBM, but new databases are created by using NEWDB. Read src/READ_ME for details about, and exceptions to, this transition process.
The ENVDEF= directive is used primarily to specify code that should either be specially included or excluded. The following example shows support for identd(8) being excluded from the compiled binary:
Note that, once excluded, support cannot
easily be included later by using options. But it may be better to turn
some facilities, such as identd(8),
off and on with options rather than compiling
them out (see Section 220.127.116.11, "Timeout.ident"
for a description of the
(see Section 18.8)
the third column indicates whether it is appropriate to
a particular macro in your Makefile. Where appropriate, most
will be defined with this ENVDEF= directive.
The ENVDEF= directive can also be used to define operating specific support. For example,
Here, support for Sun's Solaris 2.5.1 operating system is being included. In general, operating support is already included in the Makefile selected for your system. You will have only to redefine this if you are porting to a completely new operating system.
The INCDIRS= directive defines the directories searched (using the compiler's
-I switch) for
files. In general this will be empty unless you are using libraries
that are not normally used. For example, you may have installed the db(3)
library in /usr/local/lib and its corresponding include files
in /usr/local/include/db. In this case you would define
-I will be passed to the C compiler. The
be passed to the loader.
Many Makefiles specify /usr/sww in these lines. If you don't need local include files or libraries, you can leave the /usr/sww in place without harm. 
 The sww stands for SoftWare Warehouse. This scheme was used at U.C. Berkeley as a large centrally maintained /usr/local partition.
This tells the loader to exclude dynamic library support for better security.
The LIBDIRS= directive defines the directories searched (using the loader's
-L switch). The libraries in these directories are searched
before the standard system libraries.
An example of its use is given in Section 18.4.3 above.
LIBS= -ldb -lresolv -l44bsd
It is likely that you will have to add or change libraries in this list
depending on your architecture and operating system. To discover
which you need, run make(1) (see the next section)
and observe which routines the linker reports as missing.
-l44bsd is required only if you are using
Paul Vixie's version of
-lresolv as supplied with BIND 4.9.
The BINDIR= directive defines the location (directory) where the sendmail binary will be installed. It is very unlikely that you will ever have to change this from the value predefined for you in your Makefile. One exception might be if you are installing a new sendmail in parallel with the existing one. In that instance you might use
BINDIR=/usr/tests STDIR=/usr/tests HFDIR=/usr/tests ENVDEF= -D_PATH_SENDMAILCF=/usr/tests/sendmail.cf \ -D_PATH_SENDMAILPID=/usr/tests/sendmail.pid
The STDIR= and HFDIR= are described below. The ENVDEF= tells sendmail where its configuration and pid files will be found (see Section 18.8.34, PATH...).
The STDIR= directive defines the location (directory) where the sendmail program's statistics file will be found (see Section 26.2.1, "The sendmail.st File" for a description of this file). It is very unlikely that you will ever have to change this from the value that is predefined for you in your Makefile.
The HFDIR= directive defines the location (directory) where the sendmail
program's SMTP-help file will be found (see Section 34.8.28, HelpFile (H) for
a description of the
HelpFile option and this file).
It is very unlikely that you will ever have
to change this from the value that is predefined for you in your Makefile.
The OBJADD= directive defines additional object files that need to be included in the sendmail program. It is very unlikely that you will ever have to change this from the value that is predefined for you in your Makefile. One exception might be if you need to replace a standard C library function with one that was customized to satisfy some local need. For example, consider a replacement for the syslog(3) routine. First place a copy of syslog.c in the src directory. Then run:
which will create an obj.* directory and populate it with symbolic links.  Finally, edit your Makefile and syslog.o to the OBJADD= directive:
 If you have already run makesendmail, running it again will not create the link. Instead, you will need to soft-link it by hand yourself.
This will cause the syslog.c file to be compiled to produce the needed syslog.o and will cause that syslog.o to be linked in with the sendmail binary.