I used 'tags' before because this way we avoided a unnecessary
line about 'env' detection. But we cannot use 'env' in test(), so
previous commit added 'env' detection. We might just as well use
it in custom_target().
This is a bit painful because a separate build of systemd is necessary. The
tests are guarded by tests!=false and slow-tests==true. Running them is not
slow, but compilation certainly is. If this proves unwieldy, we can add a
separate option controlling those builds later.
The build for each sanitizer has its own directory, and we build all fuzzer
tests there, and then pull them out one-by-one by linking into the target
position as necessary. It would be nicer to just build the desired fuzzer, but
we need to build the whole nested build as one unit.
[I also tried making systemd and nested meson subproject. This would work
nicely, but meson does not allow that because the nested target names are the
same as the outer project names. If that is ever fixed, that would be the way
to go.]
v2:
- make sure things still work if memory sanitizer is not available
v3:
- switch to syntax which works with meson 0.42.1 found in Ubuntu
Add a new -Dllvm-fuzz=true option that can be used to build against
libFuzzer and update the oss-fuzz script to work outside of the
oss-fuzz build environment.
The fuzz targets are intended to be fast and only target systemd
code, so they don't need to call out to any dependencies. They also
shouldn't depend on shared libraries outside of libc, so we disable
every dependency when compiling against oss-fuzz. This also
simplifies the upstream build environment significantly.
The fuzzers will be used by oss-fuzz to automatically and
continuously fuzz systemd.
This commit includes the build tooling necessary to build fuzz
targets, and a fuzzer for the DNS packet parser.
Currently there is no way to prevent tests from building using meson.
This introduces two problems:
1) It adds a extra 381 files to compile.
2) One of these tests explicitly requires libgcrypt to be built even if systemd
is not using it.
3) It adds C++ to the requirements to build systemd.
When cross-compiling, this is uneccessary.
On a typical system running systemd, the telinit in PATH is very likely to be a symlink
to systemctl. Setting TELINIT to this may result in an infinite recursion if telinit is called
and sd_booted() == 0. This may commonly occur in a chroot environment.
Bug: https://bugs.gentoo.org/642724
[zj:
The path was originally hardcoded as "/lib/upstart/telinit", but was made configurable without
changing the default in 4ad61fd180. Then the default was
changed to `/lib/sysvinit/telinit` in abaaabf40a. Then it
started being autodetected when meson support was added in
5c23128dab. This patch restores the behaviour that was
implemented in configure.ac at the time of its removal.]
This reduces the man=false meson target count from 1281 to 1253.
--
A fully scientific test:
git grep _sources, :/*.build|cut -d: -f2|tr -d ' '|sort|uniq -c
reveals that libudev_sources is the only source list now reused twice. There's
some ugly circular dependency between libudev and libshared, and anyway I'm not
sure if we don't want to use different compilation options (LOG_REALM_…) in
those two cases, so I'm leaving that alone for now.
This reduces the meson man=false target count to 1281.
v2:
- link test-engine with libshared instead of libsystemd_static
Previous version built fine on F27, but fails on F26 with the following error:
/usr/bin/ld: /tmp/ccr8HRGw.ltrans6.ltrans.o: undefined reference to symbol '__start_BUS_ERROR_MAP@@SD_SHARED'
/home/zbyszek/fedora/systemd/systemd-9d5aae75c64f5583a110f03b94816aacc03bbf4d/x86_64-redhat-linux-gnu/src/shared/libsystemd-shared-236.so: error adding symbols: DSO missing from command line
v3:
- add libudev_basic
Instead of compiling those files twice, once for libsystemd and once for
libshared, compile once as a static archive and then link into both.
This reduce the meson target for man=no compile to 1291.
We were including gcrypt-util.[ch] by hand in the few places where it
was used. Create a convenience library to avoid compiling the same
files multiple times.
v2:
- use a separate static library instead of mergin into libbasic
gcrypt_util_sources had to be moved because otherwise they appeared twice
in libshared.so halfproducts, causing an error.
-fvisibility=default is added to libbasic, libshared_static so that the symbols
appear properly in the exported symbol list in libshared.
The advantage is that files are not compiled twice. When configured with -Dman=false,
the ninja target list is reduced from 1588 to 1347 targets. The difference in compilation
time is small (<10%). I think this is because of -O0 and ccache and multiple cores, and
in different settings the compilation time could be reduced. The main advantage is that
errors and warnings are not reported twice.
We of course don't know in which header glibc will export pivot_root()
and if it ever will. But there's a good chance they'll place it where
chroot() is located, given the similarity in the operations, hence let's
try our luck and look for it at the same place.
If we are lucky this means we don't have to patch our code if glibc
decides to expose the call one day.
This reworks how we set _GNU_SOURCE when checking for the availability
of functions:
1. We set it for most of the functions we look for. After all we set it
for our entire built anyway, and it's usually how Linux-specific
definitions in glibc are protected these days. Given that we usually
have checks for such modern stuff only anyway, let's just blanket enable
it.
2. Use "args" instead of "prefix" to set the macro. This is what is
suggested in the meson docs, hence let's do it.
Follow-up for bad7a0c81f501fbbcc79af9eaa4b8254441c4a1f of git
repository for glibc.
Recently glibc added `copy_file_range()`, but to use it,
`_GNU_SOURCE` needs to be defined. This adds the flag in
meson.build to detect the function by meson correctly.
This gets rid of recompilation, making things faster and avoids duplicated warnings.
The result seems to be the same:
$ ls -l build/libsystemd.so.0.20.0 build2/libsystemd.so.0.20.0
-rwxrwxr-x. 1 zbyszek zbyszek 3071312 Dec 19 11:45 build2/libsystemd.so.0.20.0
-rwxrwxr-x. 1 zbyszek zbyszek 3071760 Dec 19 11:11 build/libsystemd.so.0.20.0
$ diff -U1 <(objdump -T build/libsystemd.so.0.20.0|sed -r 's/[0-9a-f]{16}/________________/g') <(objdump -T build2/libsystemd.so.0.20.0|sed -r 's/[0-9a-f]{16}/________________/g')
-build/libsystemd.so.0.20.0: file format elf64-x86-64
+build2/libsystemd.so.0.20.0: file format elf64-x86-64
We already use the "_static" suffix for libshared_static ("shared" is the name
of the library, "static" is the format) and other libs, so let's rename for
consistency.
Also change libsystemd_static_sources to libsystemd_sources, since the same
list is used for both and shorter is better.
Otherwise, setting udev_log=debug in /etc/udev/udev.conf has no effects since
systemd-udevd is built with LOG_REALM=LOG_REALM_UDEV.
However using LOG_REALM_UDEV (for libudev_core) reveals another similar bug for
udevadm which should also define LOG_REALM_UDEV.
We might end up allocating mempools, and when we are unloaded we might
orphan them, thus leaking them. Hence, let's just stick around for good,
so the mempools remain referenced continously and for good, and thus no
memory is leaked (though the memory isn't cleaned up either).
Fixes: #7596
I want to add presets/user/ later. This mirrors the layout for units:
we have units/ and units/user. The advantage is that we avoid having yet
another directory at the top level.
To allow better integration with distributions requiring an explicitly
set gid for the `users` group, provide the new `-Dusers-gid` option to
set to a new numeric value.
In the absence of a specified gid, we'll fallback to the default existing
behaviour of `-` as the gid value, to automatically assign the next available
gid on the system.
In this way, individual errors in files can be treated differently than a
failure of the whole service.
A test is added to check that the expected value is returned.
Some parts are commented out, because it is not. This will be fixed in
a subsequent commit.
I opted to completely generate a unit for both mount points and swaps. For
swaps, it would be possible to use fixed template unit like systemd-mkswap@.service,
because there's no information passed except the device name. For mount points,
that's not possible because both the device name and file system type need to
be passed. Nevertheless, I expect that options will need to passed to both mkfs
and mkswap, in which case it'll be necessary to create units of both types
anyway.
Lennart Poettering