|
2.5 Build sendmailBefore building sendmail, leap ahead to Chapter 3 and review the many #define macros defined there. Consider those marked as tune, and for any that you find important, include a definition for each in your m4 build file. When your m4 build file is complete, return here. After you have finished configuring your m4 build file, you are ready to build sendmail. First run the following command in the sendmail source directory: # ./Build -f /path/to/your/m4/file -n This command first creates the obj directory in which sendmail will be built, populates that directory with symbolic links, and places a configured Makefile there. It then displays all the commands that make will generate without actually executing them. If you are building a vanilla sendmail, or if you have placed your m4 file in the devtools/Site directory, you can omit the -f and the path to your m4 build file. If you wish to tune sendmail to your custom needs first, before running Build, you need to create an m4 file (as discussed earlier). You can create your Build m4 files either outside the sendmail distribution or inside a special directory inside the distribution. If you maintain them outside, you will have to use the -f switch each time you build, but will avoid having to copy them again for each release of sendmail. If you create a special file inside the devtools/Site directory, that file will be included without the need for a -f. The name of the file is site.config.m4. If you want to maintain several master files in that directory, you can do so depending on your operating system type. When Build runs, it prints a line that looks like the following line split to fit the page: Configuration: pfx=, os=SunOS, rel=4.1.4, rbase=4, rroot=4.1, arch=sun4, sfx=, variant=optimized Here, the name of the operating system is printed following the os=. If you were to create a file in the devtools/Site directory called site.SunOS.m4, it, too, would be automatically found and used without the need for a -f switch. If you have defined the environment variable SENDMAIL_SUFFIX, the sfx= will be assigned that value with a dot in front of it. That value can be used to further tune the name of the files in devtools/Site. For example, if SENDMAIL_SUFFIX is defined as server, the Build script will find and use a file called site.SunOS.server.m4. The devtools/Site directory is first searched for the literal name site.config.m4. If that is not found, it is searched for the file named site.os=sfx=.m4, and after that for the file named site.os=.m4. If all looks well, after running Build with a -n, you can run it again, this time without the -n. 2.5.1 If You Change Your m4 Build FileAfter you run Build you will likely find that you need to change one or more items in your m4 build file. Whenever you change that file, you will need to use the -c switch with Build to force it to create a new Makefile with your new information in it. You do this by adding the -c switch to Build's command line: % ./Build -c -f ../../builds/oursite.m4 % ./Build -c For large compiles, such as sendmail, this process can be lengthy, but it is necessary, for without it your m4 build file changes will mysteriously appear to have no effect. 2.5.2 Use libresolv.aIf, when you compiled sendmail, the linker reported _res_ routines as missing, you might need to specify the resolver library with -lresolv: APPENDDEF(`confLIBS', `-lresolv') This shows one way to include that library with m4 builds. Another way might look like this: APPENDDEF(`confLIBS', `/usr/local/lib/libresolv.a') To ensure that sendmail achieves its optimum use of lookups, make sure your resolver library is derived from the latest BIND release: BIND 8.3.3.[6] You might also need to include -l44bsd on the LIBS= line if you are running BIND 4.9.
The tricky part is finding out which resolver library your system supports. With SunOS systems, for example, resolver support in the standard C library uses nis for name resolution. Although this setup might be good for most applications, it is inappropriate for sendmail. SunOS supplies a libresolv.a, but it is based on BIND 4.3 and so should probably be replaced with a newer version. If your resolver library is not the correct one, you need to compile and install the newest version. You should do this even if it is used only by sendmail. 2.5.3 Badly Defined sys_errlistSome systems define sys_errlist differently than sendmail does. On such systems you might see a spurious warning about sys_errlist being redefined. In general, you should never get this error. But if you are building sendmail on a system that is similar to, but not identical to, one already supported, you might see such a warning. See ERRLIST_PREDEFINED for a description of how to use ERRLIST_PREDEFINED to fix the problem, should it occur. 2.5.4 Error at or Near VariableSome older compilers don't recognize the "void *" expression. With such compilers, you might see an error something like this: "./sendmail.h", line 735: syntax error at or near variable name "void" If you get an error like this, you should define ARBPTR_T (...T) like this: APPENDDEF(`confENVDEF', `-DARBPTR_T="char *"') 2.5.5 Undefined Symbol strtoulIf you are building sendmail using a compiler that claims to be ANSI-compliant, but is not really so, you might see an error like this: ld: Undefined symbol
strtoul
If you do, your compiler is mildly broken. Fortunately, sendmail offers an easy solution. Just edit your Build m4 file, and add a line such as the following: APPENDDEF(`confENVDEF',`-DBROKEN_ANSI_LIBRARY=1') Rebuild with the -c Build switch, and this problem will go away. 2.5.6 warning: & Before ArrayOn old Unix systems and those that run non-ANSI compliant C-language compilers, the following error might appear when compiling sendmail: "daemon.c", line 678: warning: & before array or function: ignored "daemon.c", line 678: warning: illegal pointer combination These warnings are harmless and can be ignored. 2.5.7 Other ConsiderationsAs you watch the output while sendmail builds, you might notice commands being executed that you disagree with. Formatting of manuals, for example, might be a step you would rather skip. For each such problem, review the information in this and the next chapter. Correct your m4 build file and rerun Build, but this time add the -c switch. That switch causes Build to clear out the obj directory, then create a new Makefile with your new m4 build file settings: # ./Build -c -f /path/to/your/m4/file This can be an iterative process, so be patient. Tuning sendmail to exactly fit your particular site's needs can be a learning process. Be patient, as this and the next chapter contain a huge amount of information, and the way various macros interact can be confusing at first.  |
if using devtools/Site |
|