--enable-lz4 can be used to force lz4 requirement,
--disable-lz4 can be used to skip lz4 support even if available.
Also, make surrounding checks for bzip2, xz, and zlib similar in structure.
This fixes the check for requested but missing bzip2.
The intent of the assignments around the check for libcap was obviously
to avoid polluting LIBS. To work properly, LIBS must be restored from
the save_LIBS variable.
The practical effect is small though, because pretty much everything
links with libbasic, which links with CAP_LIBS.
We have two AC_CHECK_LIB checks for libdw. The first one has an empty
action-if-found, so it defaults to adding "-ldw" to LIBS. LIBS are
applied to everything we build. But only systemd-coredump needs libdw.
It already links to ELFUTILS_LIBS correctly in Makefile.am.
Drop the first AC_CHECK_LIB check. The second check is sufficient.
Q: Don't we already use "-Wl,--as-needed" to eliminate overlinking?
A: We do, but it is effective only for executables, not for shared
libraries. This is due to a libtool bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=347650
This adds support for caching harddisk passwords in the kernel keyring
if it is available, thus supporting caching without Plymouth being
around.
This is also useful for hooking up "gdm-auto-login" with the collected
boot-time harddisk password, in order to support gnome keyring
passphrase unlocking via the HDD password, if it is the same.
Any passwords added to the kernel keyring this way have a timeout of
2.5min at which time they are purged from the kernel.
If gcrypt's m4 macro files aren't installed, with this change, gcrypt
will be disabled --- unless gcrypt support was explicitly requested by
passing --enable-gcrypt to configure, in which case it will fail.
Without this change, autoconf would fail either way with not being able
to resolve AM_PATH_LIBGCRYPT.
What is the rationale to have AC_FUNC_MALLOC? It does not actually
abort the configure run if an "unsuitable" malloc was found, and
instead just replaces malloc by rpl_malloc, for which systemd however
has no definition, either.
Remove the call.
gcc versions 4.6 and earlier used to complain when a local variable
shadows a global function, 4.7 and above only complain if a local
variable shadows a global variable.
Fix this by checking whether gcc 4.7+ behavior is in place before
deciding to use -Werror=shadow in $(CFLAGS), by using a custom test
program source that shadows a global function with a local variable and
confirming that -Werror=shadow does not make the compile to break.
Tested:
- On gcc 4.7 and 4.8, confirmed nothing changed (other than the order of
the -Werror=shadow argument, going to the end of CFLAGS.)
- On gcc 4.6, confirmed by looking at the config.log output that the
check for -Werror=shadow failed and it was not included in CFLAGS.
- Ran `make V=1` to confirm -Werror=shadow was still in use, introduced
a bogus shadowing issue and confirmed it was caught when building with
a recent gcc.
The current implementation directly monitor /proc/self/mountinfo and
/run/mount/utab files. It's really not optimal because utab file is
private libmount stuff without any official guaranteed semantic.
The libmount since v2.26 provides API to monitor mount kernel &
userspace changes and since v2.27 the monitor is usable for
non-root users too.
This patch replaces the current implementation with libmount based
solution.
Signed-off-by: Karel Zak <kzak@redhat.com>
/etc/mtab should be labeled as "_", even though systemd has its own
smack label using '--with-smack-run-label' configuration. This is mainly
because all processes could read that file and the origin of this file
(i.e. /proc/mounts) is labeled as "_". This labels /etc/mtab as "_" when
'--with-smack-run-label' is enabled.
AC_CHECK_FILE fails when cross-compiling. It is intended to be used to
check for files that are used at runtime during build time (e.g.
/etc/passwd, /dev/*) [1]. For files which are only used at build time
'test -f' is sufficient.
[1]: https://lists.gnu.org/archive/html/autoconf/2000-10/msg00018.html
