shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2025-02-09 13:57:42 +03:00
Code
systemd/tools/meson-build.sh

22 lines
581 B
Bash
Raw Normal View History

Hook up oss-fuzz test cases as tests 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
2018-01-19 17:54:30 +11:00
#!/bin/sh
tree-wide: add spdx header on all scripts and helpers Even though many of those scripts are very simple, it is easier to include the header than to try to say whether each of those files is trivial enough not to require one.
2021-01-27 13:37:10 +01:00
# SPDX-License-Identifier: LGPL-2.1-or-later
Hook up oss-fuzz test cases as tests 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
2018-01-19 17:54:30 +11:00
set -eux
fuzz: pass -Dc_args=/-Dcpp_args= to fuzzer targets Prompted by #29972, because right now it's practically impossible to pass -fno-sanitize=function to the fuzzer targets without some extensive sed'ing. This splits both c_args and cpp_args to separate arguments for tools/meson-build.sh, because the other way would be to use `eval`, so the space-separated but quoted strings passed to these options are not split where they shouldn't, and I'd rather avoid using `eval` if possible. Also, this switches the positional arguments we pass to `meson setup`, as they were in incorrect order (docs say it should be buildir followed by sourcedir); meson is apparently clever enough to figure this out and switch the arguments around if necessary, so it didn't complain.
2023-11-10 16:38:01 +01:00
sourcedir="${1:?}"
builddir="${2:?}"
target="${3:?}"
c_args="${4:?}"
cpp_args="${5:?}"
options="${6:?}"
CC="${7:?}"
fuzz: don't panic without a C++ compiler meson's `cpp_args` option is defined only if it detects a C++ compiler, otherwise we get an error: ../test/fuzz/meson.build:56:28: ERROR: Tried to access unknown option 'cpp_args'.
2023-11-15 11:41:45 +01:00
CXX="$8"
Hook up oss-fuzz test cases as tests 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
2018-01-19 17:54:30 +11:00
fuzz: pass -Dc_args=/-Dcpp_args= to fuzzer targets Prompted by #29972, because right now it's practically impossible to pass -fno-sanitize=function to the fuzzer targets without some extensive sed'ing. This splits both c_args and cpp_args to separate arguments for tools/meson-build.sh, because the other way would be to use `eval`, so the space-separated but quoted strings passed to these options are not split where they shouldn't, and I'd rather avoid using `eval` if possible. Also, this switches the positional arguments we pass to `meson setup`, as they were in incorrect order (docs say it should be buildir followed by sourcedir); meson is apparently clever enough to figure this out and switch the arguments around if necessary, so it didn't complain.
2023-11-10 16:38:01 +01:00
if [ ! -f "$builddir/build.ninja" ]; then
# shellcheck disable=SC2086
CC="$CC" CXX="$CXX" meson setup -Dc_args="$c_args" -Dcpp_args="$cpp_args" "$builddir" "$sourcedir" $options
oss-fuzz: Fallback to `ninja-build` when available (#8641) The ninja binary is deployed as `ninja-build` in older distros such as RHEL 7/CentOS 7. Detect that and use `ninja-build` instead of `ninja` when it's available.
2018-04-04 00:32:59 -07:00
fi
fuzz: pass -Dc_args=/-Dcpp_args= to fuzzer targets Prompted by #29972, because right now it's practically impossible to pass -fno-sanitize=function to the fuzzer targets without some extensive sed'ing. This splits both c_args and cpp_args to separate arguments for tools/meson-build.sh, because the other way would be to use `eval`, so the space-separated but quoted strings passed to these options are not split where they shouldn't, and I'd rather avoid using `eval` if possible. Also, this switches the positional arguments we pass to `meson setup`, as they were in incorrect order (docs say it should be buildir followed by sourcedir); meson is apparently clever enough to figure this out and switch the arguments around if necessary, so it didn't complain.
2023-11-10 16:38:01 +01:00
# Locate ninja binary, on CentOS 7 it is called ninja-build, so use that name if available.
command -v ninja-build >/dev/null && ninja="ninja-build" || ninja="ninja"
"$ninja" -C "$builddir" "$target"
Copy Permalink