Configure a Postfix Source Build with makedefs

You will prepare a Postfix source tree with make makefiles, using documented name=value overrides for compiler flags, optional features and installation paths. The guide uses the installed Postfix 3.8.6 package on this machine as its reference point. Allow 15 minutes for a dry run, plus the time needed to obtain and unpack a matching source tree.

This is a build configuration step, not a way to change the configuration of a running mail server. It does not edit /etc/postfix/main.cf, restart a service or install files. You need a writable Postfix source directory, GNU make and the development libraries required by the features you choose. Run the build preparation as your normal user. Use elevated privileges only for a later installation step that you have reviewed separately.

1. Start in the Postfix source tree

makedefs is the name of the Postfix makefile configuration utility, but the documented entry point is a make target. There is normally no standalone makedefs command to run from an arbitrary directory. Change to the top level of the unpacked source tree, where the Postfix makefiles and templates are present:

$ cd /path/to/postfix-source
$ test -f Makefile && test -d src
$ make --version | head -n 1
GNU Make 4.3

The exact source layout can vary between releases, so the two tests are only a quick check that you are not in an empty temporary directory. If the Makefile test fails, stop and find the source root. Running make makefiles elsewhere produces a misleading "No rule to make target 'makefiles'" error and does not tell you anything about your compiler.

2. Run the default configuration

Let Postfix detect the compilation environment and prepare its makefile definitions:

$ make makefiles

The target identifies the platform and emits macro definitions that can be prepended to template Makefiles. The macros are an internal interface and can change between Postfix releases. Do not copy definitions from one machine into another and assume that the libraries, compiler or filesystem layout match.

For the installed Debian package, the recorded build output is available at /usr/share/postfix/makedefs.out. It identifies Postfix as version 3.8.6 and records settings such as CCARGS, dynamic libraries, dynamic maps and position-independent executables. This file describes how that package was built; it is useful for comparison, not a replacement for running the target in your own source tree.

$ postconf mail_version
mail_version = 3.8.6
$ sed -n '1,24p' /usr/share/postfix/makedefs.out

Do not use sudo for this step. A source-tree configuration should be reproducible and reviewable before any privileged installation action.

3. Add one deliberate override

Pass overrides on the make command line. They take precedence over the defaults detected by the utility. Quote a value when it contains spaces or shell metacharacters:

$ make makefiles CCARGS='-DNO_PCRE'
$ make makefiles DEBUG= OPT=

The first command requests a build without PCRE support. The second disables the default debugging and optimisation settings. These are examples of build policy, not universal recommendations. Removing a library or optimisation can change supported features or performance, so record the reason in your build notes and check the resulting feature set before installation.

Use the same target again when changing an override. Re-running it with a different value is the recovery path for an incorrect choice. If the source tree becomes difficult to audit, return to a fresh unpacked copy of the same source release rather than deleting files from a tree that contains work you need.

4. Configure Postfix 3.0 and later build features

Postfix 3.0 introduced several switches documented by makedefs(1). The following command selects a build with shared libraries, dynamic database maps and position-independent executables disabled:

$ make makefiles shared=no dynamicmaps=no pie=no

dynamicmaps=yes enables the dynamic maps configuration and dynamically loadable database plugins, and implicitly enables Postfix dynamically linked libraries. shared=yes controls those libraries directly. pie=yes controls position-independent executables where the platform supports them. Keep these choices separate in your notes because they affect different parts of the build.

You can override the flags and names used for shared libraries with SHLIB_CFLAGS, SHLIB_RPATH and SHLIB_SUFFIX. For example, a packaging environment with a known library suffix might use:

$ make makefiles SHLIB_SUFFIX=.so.1

Only use a value that matches the packaging and runtime loader rules on the target system. A syntactically successful configuration can still produce a package whose plugins cannot be found at runtime.

5. Set installation paths carefully

Postfix 3.0 and later allow installation parameters such as config_directory, queue_directory, daemon_directory, manpage_directory, meta_directory and shlib_directory to be overridden during this step. A staging build can make those paths explicit:

$ make makefiles \
    config_directory=/opt/postfix/etc \
    queue_directory=/opt/postfix/var/spool \
    daemon_directory=/opt/postfix/libexec \
    manpage_directory=/opt/postfix/share/man

These values become compiled-in defaults used by the resulting Postfix binaries and installation process. They are not equivalent to changing a live server's main.cf. Check that the staging directories, service definitions, permissions and package scripts all agree before installing anything.

6. Use version substitution correctly

If an override ends in the literal string MAIL_VERSION, the target replaces that suffix with the Postfix version. This is useful for a versioned path or package label:

$ make makefiles daemon_directory=/opt/postfix-MAIL_VERSION/libexec

For the stable 3.8.6 package, the resulting suffix is 3.8.6. Development releases use their documented major.minor-date form. Do not write $mail_version in the value. The manual warns that shell expansion and make implementations can produce inconsistent results for that form. The literal MAIL_VERSION token is the supported substitution point.

7. Keep feature toggles in the right layer

Some options disable compile-time support with CCARGS. Examples include -DNO_EPOLL for Linux EPOLL, -DNO_IPV6 for IPv6 and -DNO_DNSSEC for DNSSEC:

$ make makefiles CCARGS='-DNO_EPOLL -DNO_DNSSEC'

These directives change what is built and are mainly for portability, debugging or testing. The manual specifically says that -DNO_IPV6 is not a general runtime setting. If the operational requirement is to use IPv4 on an otherwise IPv6-capable build, set inet_protocols = ipv4 in the appropriate Postfix configuration instead.

Similarly, database support has separate auxiliary library variables such as AUXLIBS_LDAP, AUXLIBS_LMDB, AUXLIBS_MYSQL, AUXLIBS_PGSQL and AUXLIBS_SQLITE. Supply the libraries required by the selected feature, then verify the compiled result. Do not assume that a successful makefile-generation step proves that a database client library is usable.

8. Review before compiling or installing

Inspect the generated definitions and compare them with the command you intended to run:

$ grep -E '^(CC|OPT|DEBUG|SHLIB_|shared|dynamicmaps|POSTFIX_INSTALL_OPTS|.*_directory)' Makefile 2>/dev/null
$ make makefiles
$ make

The first command is only a review aid because the exact generated files and variable layout are version-dependent. The second command restores the default configuration if you were testing an override, and the final command starts compilation. Do not run the final command until the paths, feature choices and available libraries have been checked.

Installation is a separate, potentially system-wide change. Stop after compilation if you only need a package or build artefact. If you do install, use the package's documented installation procedure, review its file list and service integration, and take a backup or package-level recovery route first. A source build can replace mail-server binaries and is not reversible by simply changing main.cf.