Cannot build systemd-249 with meson >= 0.60.0

[medhefgo]

git clone https://github.com/systemd/systemd.git
cd systemd
git checkout v249
meson build

With meson < 0.60.0 this bulids fine, while newer versions retuns the following error:

meson.build:38:3: ERROR: Object <[BooleanHolder] holds [bool]: False> of type bool does not support the `+` operator.

[eli-schwartz]

That's... Really not what I meant when I said if an object lost its plus operator, "did you report a bug". I didn't say you should report a bug -- I said you should consider reporting a bug if you think this is a case where something broke that was supposed to work. But okay, let's discuss this.

This was originally brought up in https://github.com/systemd/systemd/issues/20632 via the following code:

want_ossfuzz = get_option('oss-fuzz')
want_libfuzzer = get_option('llvm-fuzz')
if want_ossfuzz + want_libfuzzer > 1

Booleans don't document that they support plus, unlike strings, numbers, and lists which do. Moreover, the result of doing true + true in Meson before 0.60.0 was to type cast bool to int and compare it favorably to 2. This only "worked" because in python, bool casts to 1 because it's technically a kind of int. Python is a nice language for a lot of things, but this is not one of them -- it's horrid.

Anyway, Meson documents:

The syntax of Meson's specification language has been kept as simple as possible. It is strongly typed so no object is ever converted to another under the covers. Variables have no visible type which makes Meson dynamically typed (also known as duck typed).

This explicitly violates that rule, bool cannot be cast to int and string cannot be cast to int and array cannot be cast to int. During routine refactoring, we made bool respect that rule without realizing it? and this broke at least one invalid meson.build out there, which was promptly fixed.

If bug fixes for type-checking invalid code break existing projects in the wild, and the effects are widespread, that's generally a good motivation to add a backwards compat shim with a warning, to give people a chance to fix their projects. I could hear the value in adding a plus operator to BooleanHolder for this reason, but it would have to return a bool, not an int, which means that systemd-249 would still be broken when trying to compare true > 1.

The fix, incidentally, was to use Meson's and operator which is documented specifically for the case of chaining bools together, and which was always the right thing to use there.

[evverx]

The fix, incidentally, was to use Meson's and operator which is documented specifically for the case of chaining bools together, and which was always the right thing to use there.

To be fair and was used there until I replaced it with + in https://github.com/systemd/systemd/commit/87ac55a12996dbe2#diff-30d8f6be6320feeacf686be94f48c70869b52630e01ea625f0f15adc0d57c3e4R36 to cover three booleans. I can't remember why exactly I did it (probably it was shorter than chaining them with and/or) but it worked at the time with no warnings whatsoever. I agree I shouldn't have done it. I also agree that meson>=0.60.0 rejecting stuff like that is kind of expected but on the other hand it means that scripts used to bisect systemd fully automatically have to downgrade meson until systemd is buildable. It would be great if it was possible for meson to downgrade itself in scenarios like that but I have to admit I'm not sure how it can be implemented.

[eli-schwartz]

Yeah, we'd need to know it was possible in order to warn for it. :( But this was a sneaky silent side effect of previously using python's builtin types instead of proper meson ObjectHolders.

I'm sympathetic to the bisect issue, but I just cannot see a way to let that work without violating the principle of strongly typed objects.

(probably it was shorter than chaining them with and/or)

Three of them? Huh.

fuzzer_build = false
foreach f: [want_ossfuzz, want_libfuzzer, want_fuzzbuzz]
    if f and fuzzer_build
        error('only one of oss-fuzz, llvm-fuzz or fuzzbuzz can be specified')
    elif f
        fuzzer_build = true
    endif
endforeach

Bit wordy, feels a bit more explicit in intention too though.

I wonder if maybe you want a combo option instead? -Dfuzzer=[oss-fuzz|libfuzzer|fuzzbuzz|none] and for each possible value do want_ossfuzz = get_option('fuzzer') == 'oss-fuzz' etc.

It would be great if it was possible for meson to downgrade itself in scenarios like that but I have to admit I'm not sure how it can be implemented.

A bisect script could do it. A really kludgy one I just hacked together with jq to get the meson_version node:

meson introspect --ast -i meson.build | jq -r \
    '.lines[] | select(.name == "project").args.kwargs[] | select(.key.value == "meson_version").val.value'

Gets you the string value which you can then use as an absolute string to reinstall Meson with. Probably as a fallback in case building it with the current version doesn't work.

I'm not sure how generally useful that is.

[evverx]

I wonder if maybe you want a combo option instead?

In retrospect I think it should have been a combo option. I couldn't switch to it to avoid breaking scripts using booleans though. One of those services is no longer used by systemd so and should suffice there for the time being I think.

A really kludgy one I just hacked together with jq to get the meson_version node

As far as I understand it should show the first meson version systemd is supposed to be built with. It's helpful if all else fails but in terms of bisecting systemd I'm usually interested in the latest meson version particular systemd commits can be compiled with so downgrading meson one version at a time is what usually works for me.

I'm not sure how generally useful that is.

I think it depends on how many people use meson and git bisect together. Having said that if git bisect goes far enough the other dependencies have to be downgraded as well so even if meson provided a way to downgrade itself somehow it wouldn't solve all issues.

[eli-schwartz]

In retrospect I think it should have been a combo option. I couldn't switch to it to avoid breaking scripts using booleans though. One of those services is no longer used by systemd so and should suffice there for the time being I think.

This may be easier going forward. :) https://mesonbuild.com/Build-options.html#deprecated-options

[zhangguanzhang]

same issue

[eli-schwartz]

@zhangguanzhang did you have this issue when trying to build systemd, or another software package?

[zhangguanzhang]

@zhangguanzhang did you have this issue when trying to build systemd, or another software package?

build systemd 247:

[root@xxx-0008 systemd-247]# meson cov-build -Dman=false
The Meson build system
Version: 0.61.4
Source dir: /home/xxx/systemd-247
Build dir: /home/xxx/systemd-247/cov-build
Build type: native build
Project name: systemd
Project version: 247
C compiler for the host machine: cc (gcc 4.8.5 "cc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)")
C linker for the host machine: cc ld.bfd 2.27-44
Host machine cpu family: x86_64
Host machine cpu: x86_64
WARNING: You should add the boolean check kwarg to the run_command call.
         It currently defaults to false,
         but it will default to true in future releases of meson.
         See also: https://github.com/mesonbuild/meson/issues/9300

meson.build:46:3: ERROR: Object <[BooleanHolder] holds [bool]: False> of type bool does not support the `+` operator.

A full log can be found at /home/xxx/systemd-247/cov-build/meson-logs/meson-log.txt
NOTICE: You are using Python 3.6 which is EOL. Starting with v0.62.0, Meson will require Python 3.7 or newer
[root@xxx-0008 systemd-247]# cat /home/xxx/systemd-247/cov-build/meson-logs/meson-log.txt
Build started at 2022-05-18T10:15:57.336082
Main binary: /usr/bin/python3
Build Options: -Dman=false
Python system: Linux
The Meson build system
Version: 0.61.4
Source dir: /home/xxx/systemd-247
Build dir: /home/xxx/systemd-247/cov-build
Build type: native build
Project name: systemd
Project version: 247
Sanity testing C compiler: cc
Is cross compiler: False.
Sanity check compiler command line: cc sanitycheckc.c -o sanitycheckc.exe -D_FILE_OFFSET_BITS=64
Sanity check compile stdout:

-----
Sanity check compile stderr:

-----
Running test binary command: /home/xxx/systemd-247/cov-build/meson-private/sanitycheckc.exe
C compiler for the host machine: cc (gcc 4.8.5 "cc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)")
C linker for the host machine: cc ld.bfd 2.27-44
Sanity testing C compiler: cc
Is cross compiler: False.
Sanity check compiler command line: cc sanitycheckc.c -o sanitycheckc.exe -D_FILE_OFFSET_BITS=64
Sanity check compile stdout:

-----
Sanity check compile stderr:

-----
Running test binary command: /home/xxx/systemd-247/cov-build/meson-private/sanitycheckc.exe
C compiler for the build machine: cc (gcc 4.8.5 "cc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)")
C linker for the build machine: cc ld.bfd 2.27-44
Build machine cpu family: x86_64
Build machine cpu: x86_64
Host machine cpu family: x86_64
Host machine cpu: x86_64
Target machine cpu family: x86_64
Target machine cpu: x86_64
WARNING: You should add the boolean check kwarg to the run_command call.
         It currently defaults to false,
         but it will default to true in future releases of meson.
         See also: https://github.com/mesonbuild/meson/issues/9300
Running command: /bin/realpath --relative-to=/home/xxx/systemd-247/cov-build /home/xxx/systemd-247
--- stdout ---
..

--- stderr ---

meson.build:46:3: ERROR: Object <[BooleanHolder] holds [bool]: False> of type bool does not support the `+` operator.

[eli-schwartz]

Alright, but we already knew that old versions of systemd had such an issue, it doesn't indicate a more widespread issue.

[zhangguanzhang]

Alright, but we already knew that old versions of systemd had such an issue, it doesn't indicate a more widespread issue.

Could you give me a patch hack to help me build?

[eli-schwartz]

Could you give me a patch hack to help me build?

Just build version 247.10 which is a bugfix release of 247

EDIT: see https://github.com/systemd/systemd/commit/3d0666d9091dd097022f02fae79890b5746285c1 https://github.com/systemd/systemd-stable/commit/3d0666d9091dd097022f02fae79890b5746285c1 for details on the stable backport.

[zhangguanzhang]

Could you give me a patch hack to help me build?

Just build version 247.10 which is a bugfix release of 247

EDIT: see systemd/systemd@3d0666d systemd/systemd-stable@3d0666d for details on the stable backport.

[root@xxx-0008 systemd-249.12]# cat /etc/redhat-release 
CentOS Linux release 7.9.2009 (Core)

[root@xxx-0008 systemd-247.10]# meson build/
The Meson build system
Version: 0.61.4
Source dir: /home/xxx/systemd-247.10
Build dir: /home/xxx/systemd-247.10/build
Build type: native build
Project name: systemd
Project version: 247
C compiler for the host machine: cc (gcc 4.8.5 "cc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)")
C linker for the host machine: cc ld.bfd 2.27-44
Host machine cpu family: x86_64
Host machine cpu: x86_64
WARNING: You should add the boolean check kwarg to the run_command call.
         It currently defaults to false,
         but it will default to true in future releases of meson.
         See also: https://github.com/mesonbuild/meson/issues/9300
Program tools/add-git-hook.sh found: YES (/home/xxx/systemd-247.10/tools/add-git-hook.sh)
Program tools/check-compilation.sh found: YES (/home/xxx/systemd-247.10/tools/check-compilation.sh)
Program tools/meson-build.sh found: YES (/home/xxx/systemd-247.10/tools/meson-build.sh)
C++ compiler for the host machine: c++ (gcc 4.8.5 "c++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)")
C++ linker for the host machine: c++ ld.bfd 2.27-44
Compiler for C supports arguments -Wno-unused-parameter: YES 
Compiler for C supports arguments -Wno-missing-field-initializers: YES 
Compiler for C supports arguments -Wno-unused-result: YES 
Compiler for C supports arguments -Wno-format-signedness: NO 
Compiler for C supports arguments -Werror=undef: YES 
Compiler for C supports arguments -Wlogical-op: YES 
Compiler for C supports arguments -Wmissing-include-dirs: YES 
Compiler for C supports arguments -Wold-style-definition: YES 
Compiler for C supports arguments -Wpointer-arith: YES 
Compiler for C supports arguments -Winit-self: YES 
Compiler for C supports arguments -Wfloat-equal: YES 
Compiler for C supports arguments -Wsuggest-attribute=noreturn: YES 
Compiler for C supports arguments -Werror=missing-prototypes: YES 
Compiler for C supports arguments -Werror=implicit-function-declaration: YES 
Compiler for C supports arguments -Werror=missing-declarations: YES 
Compiler for C supports arguments -Werror=return-type: YES 
Compiler for C supports arguments -Werror=incompatible-pointer-types: NO 
Compiler for C supports arguments -Werror=format=2: YES 
Compiler for C supports arguments -Wstrict-prototypes: YES 
Compiler for C supports arguments -Wredundant-decls: YES 
Compiler for C supports arguments -Wmissing-noreturn: YES 
Compiler for C supports arguments -Wimplicit-fallthrough=5: NO 
Compiler for C supports arguments -Wshadow: YES 
Compiler for C supports arguments -Wendif-labels: YES 
Compiler for C supports arguments -Wstrict-aliasing=2: YES 
Compiler for C supports arguments -Wwrite-strings: YES 
Compiler for C supports arguments -Werror=overflow: YES 
Compiler for C supports arguments -Werror=shift-count-overflow: NO 
Compiler for C supports arguments -Werror=shift-overflow=2: NO 
Compiler for C supports arguments -Wdate-time: NO 
Compiler for C supports arguments -Wnested-externs: YES 
Compiler for C supports arguments -Wno-error=#warnings: NO 
Compiler for C supports arguments -Wno-string-plus-int: NO 
Compiler for C supports arguments -Wno-maybe-uninitialized: YES 
Compiler for C supports arguments -ffast-math: YES 
Compiler for C supports arguments -fno-common: YES 
Compiler for C supports arguments -fdiagnostics-show-option: YES 
Compiler for C supports arguments -fno-strict-aliasing: YES 
Compiler for C supports arguments -fvisibility=hidden: YES 
Compiler for C supports arguments -fstack-protector: YES 
Compiler for C supports arguments -fstack-protector-strong: YES 
Compiler for C supports arguments --param=ssp-buffer-size=4: YES 
Compiler for C supports link arguments -Wl,-z,relro: YES 
Compiler for C supports link arguments -Wl,-z,now: YES 
Compiler for C supports link arguments -fstack-protector: YES 
Compiler for C supports arguments -Wzero-length-bounds: NO 
Checking if "-Werror=shadow with local shadowing" compiles: YES 
Compiler for C++ supports arguments -Wno-unused-parameter: YES 
Compiler for C++ supports arguments -Wno-missing-field-initializers: YES 
Compiler for C++ supports arguments -Wno-unused-result: YES 
Compiler for C++ supports arguments -Wno-format-signedness: NO 
Compiler for C supports arguments -Wstringop-truncation: NO 
Checking for size of "dev_t" : 8
Checking for size of "ino_t" : 8
Checking for size of "time_t" : 8
Checking for size of "rlim_t" : 8
Checking for size of "char16_t" : 2
Checking for size of "char32_t" : 4
Checking for size of "struct statx" : -1
Checking for size of "struct statx" : -1
Checking for function "secure_getenv" : YES 
Checking for function "__secure_getenv" : NO 
Checking for function "memfd_create" : NO 
Checking for function "gettid" : NO 
Checking for function "pivot_root" : NO 
Checking for function "name_to_handle_at" : YES 
Checking for function "setns" : YES 
Checking for function "renameat2" : NO 
Checking for function "kcmp" : NO 
Checking for function "keyctl" : NO 
Checking for function "copy_file_range" : NO 
Checking for function "bpf" : NO 
Checking for function "statx" : NO 
Checking for function "explicit_bzero" : NO 
Checking for function "reallocarray" : NO 
Checking for function "set_mempolicy" : NO 
Checking for function "get_mempolicy" : NO 
Checking for function "pidfd_send_signal" : NO 
Checking for function "pidfd_open" : NO 
Checking for function "rt_sigqueueinfo" : NO 
Checking for function "mallinfo" : YES 
Checking for function "close_range" : NO 
Checking for function "getrandom" : NO 
Checking for function "getrandom" : NO 
Program sh found: YES (/bin/sh)
Program echo found: YES (/bin/echo)
Program test found: YES (/bin/test)
Program sed found: YES (/bin/sed)
Program awk found: YES (/bin/awk)
Program m4 found: YES (/bin/m4)
Program stat found: YES (/bin/stat)
Program ln found: YES (/bin/ln)
Program git found: YES (/bin/git)
Program env found: YES (/bin/env)
Program perl found: YES (/bin/perl)
Program rsync found: YES (/bin/rsync)
Program test/test-efi-create-disk.sh found: YES (/home/xxx/systemd-247.10/test/test-efi-create-disk.sh)
Program quotaon found: YES (/sbin/quotaon)
Program quotacheck found: YES (/sbin/quotacheck)
Program kmod found: YES (/bin/kmod)
Program kexec /usr/sbin/kexec /sbin/kexec found: NO
Program sulogin found: YES (/sbin/sulogin)
Program mount found: YES (/bin/mount)
Program umount found: YES (/bin/umount)
Program loadkeys found: YES (/bin/loadkeys)
Program setfont found: YES (/bin/setfont)
Program nologin found: YES (/sbin/nologin)
Program gperf found: YES (/bin/gperf)
Message: gperf len type is unsigned
Has header "sys/capability.h" : YES 
Has header "crypt.h" : YES 
Has header "linux/memfd.h" : YES 
Has header "linux/vm_sockets.h" : YES 
Has header "sys/auxv.h" : YES 
Has header "valgrind/memcheck.h" : NO 
Has header "valgrind/valgrind.h" : NO 
meson.build:754: WARNING: 
The local user with the UID 65534 does not match the configured user name "nobody" of the nobody user (its name is nfsnobody).
Your build will result in an user table setup that is incompatible with the local system.
meson.build:763: WARNING: 
The local user with the configured user name "nobody" of the nobody user does not have UID 65534 (it has 99).
Your build will result in an user table setup that is incompatible with the local system.
meson.build:773: WARNING: 
The local group with the GID 65534 does not match the configured group name "nobody" of the nobody group (its name is nfsnobody).
Your build will result in an group table setup that is incompatible with the local system.
meson.build:782: WARNING: 
The local group with the configured group name "nobody" of the nobody group does not have GID 65534 (it has 99).
Your build will result in an group table setup that is incompatible with the local system.
Program tools/choose-default-locale.sh found: YES (/home/xxx/systemd-247.10/tools/choose-default-locale.sh)
Run-time dependency threads found: YES
Library rt found: YES
Library m found: YES
Library dl found: YES
Library crypt found: YES
Checking for function "crypt_ra" with dependency -lcrypt: NO 
Checking for function "crypt_preferred_method" with dependency -lcrypt: NO 
Checking for function "crypt_gensalt_ra" with dependency -lcrypt: NO 
Found pkg-config: /bin/pkg-config (0.27.1)
Run-time dependency libcap found: YES 2.22
Dependency mount found: NO found 2.23.0 but need: '>= 2.30'
Did not find CMake 'cmake'
Found CMake: NO
Run-time dependency mount found: NO 

meson.build:907:0: ERROR: Invalid version of dependency, need 'mount' ['>= 2.30'] found '2.23.0'.

A full log can be found at /home/xxx/systemd-247.10/build/meson-logs/meson-log.txt
NOTICE: You are using Python 3.6 which is EOL. Starting with v0.62.0, Meson will require Python 3.7 or newer
[root@xxx-0008 systemd-247.10]# yum provides valgrind.h
Loaded plugins: fastestmirror
Repository epel is listed more than once in the configuration
Repository epel-debuginfo is listed more than once in the configuration
Repository epel-source is listed more than once in the configuration
Loading mirror speeds from cached hostfile
No matches found
[root@xxx-0008 systemd-247.10]# for p in `echo $PATH | tr ':' ' '` ;do
>     if [ -f "${p}/mount" ];then
>          echo -n "${p}/mount ";
>          ${p}/mount --version
>     fi
> done
/bin/mount mount from util-linux 2.33 (libmount 2.33.0: btrfs, namespaces, assert, debug)
/usr/bin/mount mount from util-linux 2.33 (libmount 2.33.0: btrfs, namespaces, assert, debug)

maybe some errors in the version check 😢

[eli-schwartz]

Maybe, but if so, that's not really an issue with Meson.

[zhangguanzhang]

Maybe, but if so, that's not really an issue with Meson.

😁 Thanks for your help, I built successfully on the new machine

[tristan957]

@eli-schwartz closeable

[eli-schwartz]

Yeah, I don't think there's anything to do here.

If that issue had shown up today, after meson 1.0, there would be grounds to say "this shouldn't break because semver, regardless of whether it obeys the docs or not".

But it did not, so we will not. :D