Build Instructions ------------------ * Requirements ------------ - A POSIX-compliant C development environment - GNU make version 3.81 or later - skalibs version 2.9.2.0 or later: http://skarnet.org/software/skalibs/ - Linux-PAM version 1.3.0 or later: http://www.linux-pam.org/library/ This software will run on any operating system that implements POSIX.1-2008, available at: http://pubs.opengroup.org/onlinepubs/9699919799/ as well as Linux-PAM. As of February 2018, this means only Linux. * Standard usage -------------- ./configure && make && sudo make install will work for most users. It will install the pamelad binary in /libexec, the static library in /usr/lib/pamela, and the shared library in /lib. Please note that static libraries in /usr/lib/pamela *will not* be found by a default linker invocation: you need -L/usr/lib/pamela. Other skarnet.org software automatically handles that case if the default configuration is used, but if you change the configuration, remember to use the appropriate --with-lib configure option. You can strip the binaries and libraries of their extra symbols via "make strip" before the "make install" phase. It will shave a few bytes off them. The PAM declarations for applications are available in the pamela/pam.h header. They are not made available in security/pam_appl.h by default in order to avoid conflicting with a Linux-PAM installation. If you want to make pamela your default PAM implementation, run sudo make install-symlink which will make security/pam_appl.h a symlink to pamela/pam.h, possibly overwriting any previous security/pam_appl.h file. Please note that if you try and build pamela again *after* doing this, the pamelad binary (which expects Linux-PAM, not pamela, in security/pam_appl.h) may not be built correctly. * Customization ------------- You can customize paths via flags given to configure. See ./configure --help for a list of all available configure options. * Environment variables --------------------- Controlling a build process via environment variables is a big and dangerous hammer. You should try and pass flags to configure instead; nevertheless, a few standard environment variables are recognized. If the CC environment variable is set, its value will override compiler detection by configure. The --host=HOST option will still add a HOST- prefix to the value of CC. The values of CFLAGS, CPPFLAGS and LDFLAGS will be appended to flags auto-detected by configure. To entirely override the flags set by configure instead, use make variables. * Make variables -------------- You can invoke make with a few variables for more configuration. CC, CFLAGS, CPPFLAGS, LDFLAGS, LDLIBS, AR, RANLIB, STRIP, INSTALL and CROSS_COMPILE can all be overridden on the make command line. This is an even bigger hammer than running ./configure with environment variables, so it is advised to only do this when it is the only way of obtaining the behaviour you want. DESTDIR can be given on the "make install" command line in order to install to a staging directory. * Static binaries --------------- By default, binaries are linked against static versions of all the libraries they depend on, except for the libc. You can enforce linking against the static libc with --enable-static-libc. Note that the pamelad binary needs to be able to load the PAM modules, so it requires dynamic linking. Attempting to statically link the pamela package is strongly discouraged. * Cross-compilation ----------------- skarnet.org packages centralize all the difficulty of cross-compilation in one place: skalibs. Once you have cross-compiled skalibs, the rest is easy. * Use the --host=HOST option to configure, HOST being the triplet for your target. * Make sure your cross-toolchain binaries (i.e. prefixed with HOST-) are accessible via your PATH environment variable. * Make sure to use the correct version of skalibs for your target, and the correct sysdeps directory, making use of the --with-include, --with-lib, --with-dynlib and --with-sysdeps options as necessary. * The slashpackage convention --------------------------- The slashpackage convention (http://cr.yp.to/slashpackage.html) is a package installation scheme that provides a few guarantees over other conventions such as the FHS, for instance fixed absolute pathnames. skarnet.org packages support it: use the --enable-slashpackage option to configure, or --enable-slashpackage=DIR for a prefixed DIR/package tree. This option will activate slashpackage support during the build and set slashpackage-compatible installation directories. If $package_home is the home of the package, defined as DIR/package/$category/$package-$version with the variables read from the package/info file, then: --dynlibdir is set to $package_home/library.so --bindir is set to $package_home/command --sbindir is also set to $package_home/command (slashpackage differentiates root-only binaries by their Unix rights, not their location in the filesystem) --libexecdir is also set to $package_home/command (slashpackage does not need a specific directory for internal binaries) --libdir is set to $package_home/library --includedir is set to $package_home/include --prefix is pretty much ignored when you use --enable-slashpackage. You should probably not use both --enable-slashpackage and --prefix. When using slashpackage, two additional Makefile targets are available after "make install": - "make update" changes the default version of the software to the freshly installed one. (This is useful when you have several installed versions of the same software, which slashpackage supports.) - "make -L global-links" adds links from /command and /library.so to the default version of the binaries and shared libraries. The "-L" option to make is necessary because targets are symbolic links, and the default make behaviour is to check the pointed file's timestamp and not the symlink's timestamp. * Absolute pathnames ------------------ You may want to use fixed absolute pathnames even if you're not following the slashpackage convention: for instance, the Nix packaging system prefers calling binaries with immutable paths rather than rely on PATH resolution. If you are in that case, use the --enable-absolute-paths option to configure. This will ensure that programs calling binaries from this package will call them with their full installation path (in bindir) without relying on a PATH search. * Out-of-tree builds ------------------ skarnet.org packages do not support out-of-tree builds. They are small, so it does not cost much to duplicate the entire source tree if parallel builds are needed.