Home / Alt manpages / makedefs(1)

  • makedefs(1)
  • User command
  • linux

Configure a Postfix Source Build with makedefs

makedefs is the Postfix build step that works out your compiler, libraries and platform before anything gets compiled. Getting it wrong here is far cheaper than getting it wrong after install. 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 whatever time it takes to obtain and unpack a matching source tree.

This is a build configuration step, not a way to change a running mail server's configuration. 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 whichever features you choose. Run the build preparation as your normal user; save elevated privileges for a later, separately reviewed installation step.

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 live:

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

Source layout varies between releases, so those two tests are only a quick sanity check that you are not sitting in an empty temporary directory. If the Makefile test fails, stop and find the real source root: running make makefiles elsewhere produces a misleading "No rule to make target 'makefiles'" error that tells you nothing about your compiler.

Checkpoint

The shell is in the source root, the tree is writable by your account, and the input source archive stays untouched so you can start again if an override turns out wrong.

2. Run the Default Configuration

Let Postfix detect the compilation environment and write its own makefile definitions:

$ make makefiles

The target identifies the platform and emits macro definitions that get prepended to template Makefiles. Those macros are an internal interface and can change between Postfix releases, so never copy definitions from one machine to another and assume the libraries, compiler or filesystem layout line up.

For the installed Debian package, the recorded build output lives 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. That file describes how the 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 touches it.

3. Add One Deliberate Override

Pass overrides on the make command line and they take precedence over whatever the utility detected. Quote a value if 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 turns off the default debugging and optimisation settings. Treat these as 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.

Rerun the same target with a different value when you need to change an override; that is the recovery path for a bad choice. If the source tree gets hard to audit, start from a fresh unpacked copy of the same release rather than deleting files from a tree that holds work you need.

Checkpoint

Every non-default value is visible in your command history or build notes, and the development headers and libraries it needs are installed before compilation begins.

4. Configure Postfix 3.0 and Later Build Features

Postfix 3.0 introduced several switches documented by makedefs(1). This command selects a build with shared libraries, dynamic database maps and position-independent executables all 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's 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, since 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. A packaging environment with a known library suffix, for example, 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 let you override installation parameters such as config_directory, queue_directory, daemon_directory, manpage_directory, meta_directory and shlib_directory 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 for the resulting Postfix binaries and installation process. They are not the same as changing a live server's main.cf. Check that staging directories, service definitions, permissions and package scripts all agree before you install anything.

Warning

Do not point a test build at the active server's queue or configuration directory just for convenience. A later install or service start could mix test binaries with production state. To undo a path choice, rerun make makefiles in a fresh source tree with the intended values before compiling.

6. Use Version Substitution Correctly

If an override ends in the literal string MAIL_VERSION, the target replaces that suffix with the Postfix version. That 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 own 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 through CCARGS: -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 gets built, mainly for portability, debugging or testing, and the manual specifically says -DNO_IPV6 is not a general runtime setting. If the actual requirement is to use IPv4 on an otherwise IPv6-capable build, set inet_protocols = ipv4 in the appropriate Postfix configuration instead.

Database support has its own auxiliary library variables too, such as AUXLIBS_LDAP, AUXLIBS_LMDB, AUXLIBS_MYSQL, AUXLIBS_PGSQL and AUXLIBS_SQLITE. Supply the libraries the selected feature needs, then verify the compiled result. A successful makefile-generation step does not by itself prove a database client library is usable.

8. Review Before Compiling or Installing

Inspect the generated definitions and compare them with what 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, since the exact generated files and variable layout are version-dependent. The second restores the default configuration if you were testing an override, and the third starts compilation. Do not run that final command until the paths, feature choices and available libraries have all been checked.

Installation is a separate, potentially system-wide change. Stop after compilation if all you need is 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 it is not reversible by simply changing main.cf.

Done means

  • Ran from the right place. make makefiles was run from the correct Postfix source root.
  • Matched the version. The build uses Postfix 3.8.6-compatible expectations, or the actual source version was recorded.
  • Made overrides intentional. Every override is deliberate, quoted where necessary, and recorded for reproduction.
  • Kept layers separate. Compile-time switches were not used as substitutes for runtime configuration.
  • Protected production. Installation paths do not point test output at a live queue or configuration directory.
  • Reviewed before building. The generated settings were checked before compilation, with no privileged command used for preparation.