tests: add test that dlopen()s our weak shared library deps once - #17884

Prompted by #17769

Nice, this will help a lot! What about also testing libpcre2 (from journalctl.c) and libxkbcommon (from localed.c)?

Nice, this will help a lot! What about also testing libpcre2 (from journalctl.c) and libxkbcommon (from localed.c)?

See comment in second commit msg.

Nice, this will help a lot! What about also testing libpcre2 (from journalctl.c) and libxkbcommon (from localed.c)?

See comment in second commit msg.

Ah sorry, missed it!

Mmh it seems like on CentOS 7 libqrencode is available at build time but not in the testbed, if I'm reading this correctly:

13:37:29 --- test-dlopen-so begin ---
13:37:29 Found container virtualization none.
13:37:29 libqrcode support is not installed: libqrencode.so.4: cannot open shared object file: No such file or directory
13:37:29 Assertion 'dlopen_qrencode() >= 0' failed at src/test/test-dlopen-so.c:34, function run(). Aborting.

@mrc0mmand do we need an update to the CI conf?

Nice, this will help a lot! What about also testing libpcre2 (from journalctl.c) and libxkbcommon (from localed.c)?

See comment in second commit msg.

Ah sorry, missed it!

Mmh it seems like on CentOS 7 libqrencode is available at build time but not in the testbed, if I'm reading this correctly:

13:37:29 --- test-dlopen-so begin ---
13:37:29 Found container virtualization none.
13:37:29 libqrcode support is not installed: libqrencode.so.4: cannot open shared object file: No such file or directory
13:37:29 Assertion 'dlopen_qrencode() >= 0' failed at src/test/test-dlopen-so.c:34, function run(). Aborting.

@mrc0mmand do we need an update to the CI conf?

Not the CI config, but the image config for TEST-02-UNIT-TESTS needs tweaking to pull in these deps explicitly, or simply skip it in TEST-02-UNIT-TESTS and just run it as part of the standard meson test.

The Arch job is going to fail in the same manner. Ubuntu CIs don't run TEST-02.

Nice, this will help a lot! What about also testing libpcre2 (from journalctl.c) and libxkbcommon (from localed.c)?

See comment in second commit msg.

Ah sorry, missed it!
Mmh it seems like on CentOS 7 libqrencode is available at build time but not in the testbed, if I'm reading this correctly:

13:37:29 --- test-dlopen-so begin ---
13:37:29 Found container virtualization none.
13:37:29 libqrcode support is not installed: libqrencode.so.4: cannot open shared object file: No such file or directory
13:37:29 Assertion 'dlopen_qrencode() >= 0' failed at src/test/test-dlopen-so.c:34, function run(). Aborting.

@mrc0mmand do we need an update to the CI conf?

Not the CI config, but the image config for TEST-02-UNIT-TESTS needs tweaking to pull in these deps explicitly, or simply skip it in TEST-02-UNIT-TESTS and just run it as part of the standard meson test.

The Arch job is going to fail in the same manner. Ubuntu CIs don't run TEST-02.

Ah yes indeed. Coming up with a diff shortly.

@poettering this fix for test/test-functions fixes the issue for me:

--- a/test/test-functions
+++ b/test/test-functions
@@ -676,6 +676,19 @@ install_missing_libraries() {
     for i in $initdir{,/usr}/{sbin,bin}/* $initdir{,/usr}/lib/systemd/{,tests/{,manual/,unsafe/}}*; do
         LD_LIBRARY_PATH="${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}$(get_ldpath $i):$(get_ldpath $i)/src/udev" inst_libs $i
     done
+
+    # A number of dependencies is now optional via dlopen, so the install
+    # script will not pick them up, since it looks at linkage.
+    for lib in libcryptsetup libidn libidn2 pwquality libqrencode; do
+            if pkg-config --exists ${lib}; then
+                    path=$(pkg-config --variable=libdir ${lib})
+                    if ! [[ ${lib} =~ ^lib ]]; then
+                            lib="lib${lib}"
+                    fi
+                    inst_libs "${path}/${lib}.so"
+                    inst_library "${path}/${lib}.so"
+            fi
+    done
 }
 
 cleanup_loopdev() {

It's using pkg-config so that variability in the libdir don't bite us (hopefully).

@bluca Thanks a lot for tracking this down. Pulled your patch into a new commit now. PTAL!

Mmh computer still says no:

10:06:39 libqrcode support is not installed: libqrencode.so.4: cannot open shared object file: No such file or directory
10:06:39 Assertion 'dlopen_qrencode() >= 0' failed at src/test/test-dlopen-so.c:34, function run(). Aborting.

With the change in the test-fuction, it is working for me on Debian. @mrc0mmand any idea what could be different on CentOS?

Mmh computer still says no:

10:06:39 libqrcode support is not installed: libqrencode.so.4: cannot open shared object file: No such file or directory
10:06:39 Assertion 'dlopen_qrencode() >= 0' failed at src/test/test-dlopen-so.c:34, function run(). Aborting.

With the change in the test-fuction, it is working for me on Debian. @mrc0mmand any idea what could be different on CentOS?

Well, the libqrencode on CentOS 7 is too ancient for systemd, so this test needs to be skipped there:

# rpm -ql qrencode-libs
/usr/lib64/libqrencode.so.3
/usr/lib64/libqrencode.so.3.4.1

Actually, this is kind of an interesting situation - the build is happy with the older libqrencode, but the test isn't:

Run-time dependency libqrencode found: YES 3.4.1
...
          enabled features: libcryptsetup, PAM, p11kit, AUDIT, IMA, SELinux, SECCOMP, SMACK, zlib, xz, lz4, bzip2, ACL, gcrypt, qrencode,...
...
systemd 247-220-gd86219c running in system mode. (+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS -OPENSSL +ACL +BLKID +CURL +ELFUTILS -FIDO2 -IDN2 +IDN +IPTC +KMOD +LIBCRYPTSETUP -LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE ...

Mmh computer still says no:

10:06:39 libqrcode support is not installed: libqrencode.so.4: cannot open shared object file: No such file or directory
10:06:39 Assertion 'dlopen_qrencode() >= 0' failed at src/test/test-dlopen-so.c:34, function run(). Aborting.

With the change in the test-fuction, it is working for me on Debian. @mrc0mmand any idea what could be different on CentOS?

Well, the libqrencode on CentOS 7 is too ancient for systemd, so this test needs to be skipped there:

# rpm -ql qrencode-libs
/usr/lib64/libqrencode.so.3
/usr/lib64/libqrencode.so.3.4.1

Mmmh but it shouldn't be compiled in, in the first place, if that's the case?

Actually, this is kind of an interesting situation - the build is happy with the older libqrencode, but the test isn't:

Run-time dependency libqrencode found: YES 3.4.1
...
          enabled features: libcryptsetup, PAM, p11kit, AUDIT, IMA, SELinux, SECCOMP, SMACK, zlib, xz, lz4, bzip2, ACL, gcrypt, qrencode,...
...
systemd 247-220-gd86219c running in system mode. (+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS -OPENSSL +ACL +BLKID +CURL +ELFUTILS -FIDO2 -IDN2 +IDN +IPTC +KMOD +LIBCRYPTSETUP -LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE ...

Ah yes indeed, we don't set a minimum version in Meson. In this case, the API version matches the ABI revision too, so @poettering this should suffice:

--- a/meson.build
+++ b/meson.build
@@ -1117,6 +1117,7 @@ conf.set10('HAVE_LIBIPTC', have)
 want_qrencode = get_option('qrencode')
 if want_qrencode != 'false' and not skip_deps
         libqrencode = dependency('libqrencode',
+                                 version : '>= 4',
                                  required : want_qrencode == 'true')
         have = libqrencode.found()
 else

Doesn't have to be fixed now, but as a separate change I think we should get the soname of the dlopen'ed libraris from Meson. We are lucky in this case, but ABI revisions can and will change without API breakages at some point in some of these.

Once we do that, we can remove the above restrictions, which will make qrencode unavailable on CentOS 7/RHEL 7 even though it could be supported, since we don't seem to be affected by the API level changes - given it built just fine.

Force pushed a new version, adding your suggested line.