I added them in 41afb5eb72 without too
much explanation. Most likely the idea was to get rid of unused code
in libsystemd.so [1]. But now that I'm testing this, it doesn't seem
to have an effect. LTO is needed to get rid of unused functions, and
it's enough to have LTO without those options. Those options might have
some downsides [2], so let's disable them since there are doubts and no
particularly good reason to have them.
But keep the -Wl,--gc-sections option. Without this, libsystemd.so
grows a little:
-rwxr-xr-x 1 zbyszek zbyszek 5532424 07-08 13:24 build/libsystemd.so.0.40.0-orig
-rwxr-xr-x 1 zbyszek zbyszek 5614472 07-08 13:26 build/libsystemd.so.0.40.0-no-sections
-rwxr-xr-x 1 zbyszek zbyszek 5532392 07-08 13:27 build/libsystemd.so.0.40.0
Let's apply the --gc-sections option always to make the debug and final
builds more similar.
We need to verify that distro packages don't unexpectedly grow after this.
[1] https://unix.stackexchange.com/a/715901
[2] https://stackoverflow.com/a/36033811
Currently, when running "systemctl preset-all --root=xxx" in mkosi
to enable/disable units for initrds, the system presets are used.
The problem with this approach is that the system presets are written
for the system, and that is not necessarily ideal for an initrd, but we
still want to use the same packages in the initrd that we install in the
system, so let's introduce a separate directory for initrd presets which
is used to pick up preset files from when we detect that we're configuring
an initrd (by looking for /etc/initrd-release).
We also introduce a systemd preset file for the initrd, which is based on
the system one, except with all the stuff unnecessary for the initrd removed.
[1] says:
> Since 0.60.0 the name argument is optional and defaults to the basename of
> the first output
We specify >= 0.62 as the supported version, so drop the duplicate name in all cases
where it is the same as outputs[0], i.e. almost all cases.
[1] https://mesonbuild.com/Reference-manual_functions.html#custom_target
Looking at aecb6eaed7, it seems that we
want build paths with spaces to be supported. Let's use 'printf %q' here
to make that work. Also, use capture:true to make the command less complicated.
The format is not specific to gpg, it's defined by the pgp
protocols. Lintian even warns about it:
systemd-container: openpgp-file-has-implementation-specific-extension [usr/lib/systemd/import-pubring.gpg]
Rename it accordingly, as new pgp implementations are slowly becoming
more popular.
Keep using /etc/systemd/import-pubring.gpg for backward compatibility.
This partially reverts e86a492ff0.
The function getdents64() was introduced in glibc-2.30, and our baseline
on glibc is 2.31. Hence, we can assume the function always exists.
The posix_getdents() wrapper was introduced for compatibility with musl.
However, even the latest release of musl does not provide posix_getdents()
yet. Also, even with musl, by defining _LARGEFILE64_SOURCE, we can get
getdents64() and struct dirent64. Hence, the wrapper is anyway not
necessary.
The check existed for musl. Let's remove it, as we explicitly request glibc.
While removing the check, this also drops generic_mallinfo, introduces
a tiny converter from struct mallinfo to struct mallinfo2 if mallinfo2()
does not exist, and renames mallinfo-util.h to malloc.h.
With this change, we can drop many ifdefs and casts in .c files.
It was added in 1a40a3393e for autotools,
sadly with no explanation, and forward-ported to meson in
5c23128dab. Things seems to work fine without
it now so drop it.
Tested with clang-20.1.5-1.fc43.x86_64.
Depending on which optional features are enabled, the NSS module
might not have been built, which means the custom install script
will fail to remove the file. Let's pass -f so it succeeds regardless
of whether the file exists or not.
blkid, libmount and openssl are not used in src/basic or src/libsystemd,
and so shouldn't be required as deps of libsystemd static, so let's drop
them.
Follow-up for ab29e77aa9.
For gcc, flex-array-member-not-at-end was enabled by the commit,
but the option for clang with the same effect was still disabled.
Let's reenable it.
Prompted by #37497.
In multi-seat scenarios, a display manager might need to start multiple
greeter sessions. But systemd allows at most one graphical session per
user. So, display managers now have a range of UIDs to dynamically
allocate users for their greeter sessions.
Even if -fno-finite-math-only is specified, -ffinite-math-only,
-ffast-math, or -Ofast may be also specified after that. In that case,
-fno-finite-math-only has no effect, and test-json will fail.
Replaces #37603.
We're very limited in our ability to change these due to backwards
compat, so let's skip them from analysis since we won't be able to
fix the errors anyway.
These are built from the same sources as the regular binaries, so we
end up with the same sources multiple times in the compilation database
but with different command line arguments, which trips up tooling that
uses the compilation database. Let's not define the standalone targets if
the option is not enabled to avoid this problem.
Instead of using run-clang-tidy.py with its own scheduling, let's
just gather a list of source files ourselves and then use that to
add a unit test for each source file that runs clang-tidy on the
source file.
We also add a bit of logic to run clang-tidy on most header files
as well for extra coverage. This uncovered various header files that
were not standalone so this commit also includes fixes to make sure
the clang-tidy tests are all green.
We can also use this in a later commit to run clang-include-cleaner
on each source file in the same way.
fuzz-tests is enabled by default now but we still don't build the fuzz
executables by default. Let's change that so that we always make sure these
still compile when we make changes.
While we don't build these by default, all the source files still
get added to the compile_commands.json file by meson, which can confuse
tools as they might end up analyzing the source files twice or analyzing
the wrong one.
To avoid this issue, only define the static library target if the
corresponding option is enabled.
meson by default adds the current source and build directory as include
directories. Because we structure our meson code by gathering a giant dict
of everything we want to do and then doing all the actual target generation
in the top level meson.build, this behavior does not make sense at all because
we end up adding the top level repository directory as an include directory
which is never what we want.
At the same time, let's also make sure the top level directory of the build
directory is not an include directory, by moving the version.h generation
into the src/version subdirectory and then adding the src/version subdirectory
of the build directory as an include directory instead of the top level
repository directory.
Making this change means that language servers such as clangd can't get
confused when they automatically insert an #include line and insert
"#include "src/basic/fs-util.h" instead of "#include "fs-util.h".
Currently, when we want to add unit tests for code that is compiled into
an executable, we either compile the code at least twice (once for the
executable, and once for each test that uses it) or we create a static
library which is then used by both the executable and all the tests.
Both of these options are not ideal, compiling source files more than
once slows down the build for no reason and creating the intermediate
static libraries takes a lot of boilerplate.
Instead, let's use the extract_objects() method that meson exposes on
build targets. This allows us to extract the objects corresponding to
specific source files and use them in other executables. Because we
define all executables upfront into a dictionary, we integrate this into
the dictionary approach by adding two new fields:
- 'extract' takes a list of files for which objects should be extracted.
The extracted objects are stored in a dict keyed by the executable name
from which they were extracted.
- 'objects' takes the name of an executable from which the extracted
objects should be added to the current executable.
One side effect of this approach is that we can't build test executables
anymore without building the main executable, so we stop building test
executables unless we're also building the main executable. This allows
us to switch to using subdir_done() in all of these subdirectories to skip
parsing them if the corresponding component is disabled.
These changes get me down from 2439 => 2403 ninja targets on a full rebuild
from scratch.
Currently, when fuzzers are enabled, we run meson from within meson
to build the fuzzer executables with sanitizers. The idea is that
we can build the fuzzers with different kinds of sanitizers
independently from the main build.
The issue with this setup is that we don't actually make use of it.
We only build the fuzzers with one set of sanitizers (address,undefined)
so we're adding a bunch of extra complexity without any benefit as we
can just setup the top level meson build with these sanitizers and get
the same result.
The other issue with this setup is that we don't pass on all the options
passed to the top level meson build to the nested meson build. The only things
we pass on are extra compiler arguments and the value of the auto_features
option, but none of the individual feature options if overridden are passed on,
which can lead to very hard to debug issues as an option enabled in the top
level build is not enabled in the nested build.
Since we're not getting anything useful out of this setup, let's simplify
and get rid of the nested meson build. Instead, sanitizers should be enabled
for the top level meson.build. This currently didn't work as we were overriding
the sanitizers passed to the meson build with the fuzzer sanitizer, so we
fix that as well by making sure we combine the fuzzer sanitizer with the ones
passed in by the user.
We also drop support for looking up libFuzzer as a separate library as
it has been shipped builtin in clang since clang 6.0, so we can assume
that -fsanitize=fuzzer is available.
To make sure we still run the fuzzing tests, we enable the fuzz-tests option
by default now to make sure they still always run (without instrumentation unless
one of llvm-fuzz or oss-fuzz is enabled).
meson's target has a few issues:
- Runs on all source files regardless if they're included in the
build or not
- Doesn't have any dependencies on generated sources which means we
have to do a full build first before we can run clang-tidy
- Doesn't allow us to pass any extra arguments
To work around these, let's define our own clang-tidy target instead
using llvm's run-clang-tidy script. Alongside the clang-tidy target,
let's start keeping track of all generated sources which we make the
clang-tidy target depend on. We also add a new target which will only
generate source files which is useful for setting up the source tree
for running code analysis against it.
Even though these are in our tree, we should still treat them as
system includes which helps various tools (clangd, iwyu, ...) understand
that these are system includes and <> should be used instead of "".
We add a default test setup that excludes the integration-tests suite
so that the integration tests don't run by default. This allows us to
get rid of $SYSTEMD_INTEGRATION_TESTS. Then, we add two extra setups:
'integration' and 'shell'. The 'integration' setup does not exclude the
integration-tests suite, and so can be used to run the integration tests.
The 'shell' setup does the same, but additionally sets $TEST_SHELL=1,
allowing to get rid of $TEST_SHELL in the docs.
vsc_tag() always reruns even if the vcs-tag option is disabled. Let's
use custom_target() instead so that we can only enable build_always_stale
if the vcs-tag option is enabled.
This new tool looks for a three xattr on the root inode of a file system
that encode mount constraints of the file system. The tool is supposed
to be hooke into the mount logic and is supposed to protect against
misappropriating trusted file systems in unintended ways.
Consider the following scenario: we boot up on first boot and create a
tpm-locked pair of /var/ and /srv/ partitions via systemd-repart. An
attacker then offline modifies the partition table, exchanging the
metadata of the /var/ and /srv/ partition. So far we'd happily accept
that, honour the modified metadata and boot up. This could be used to
revert changes to /var/ or similar. And all that even though both
partitions are encrypted and locked to TPM!
With this new mechanism we can encode in the protected contents of the
file systems the ways it can be used: the partition type uuid, the
partition label and the intended mount point can be stored in xattrs,
and we can check them automatically on mount, and take action on
mismatch. (action would typically be immediate reboot).
