libudev: add "Libs.private: -lrt -pthread" to libudev.pc

[floppym]

This resolves a failure when linking cryptsetup.static against libudev.a.

libtool: link: x86_64-pc-linux-gnu-gcc -Wall -O2 -pipe -march=amdfam10 -static -O2 -o cryptsetup.static lib/utils_crypt.o lib/utils_loop.o lib/utils_io.o lib/utils_blkid.o src/utils_tools.o src/utils_password.o src/utils_luks2.o src/utils_blockdev.o src/cryptsetup.o -pthread -pthread  -Wl,--as-needed ./.libs/libcryptsetup.a -largon2 -lrt -ljson-c -lpopt -luuid -lblkid -lssl -lcrypto -lz -ldl -ldevmapper -lm -lpthread -ludev -pthread
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib64/libudev.a(src_libsystemd_sd-daemon_sd-daemon.c.o): in function `sd_is_mq':
(.text.sd_is_mq+0x3a): undefined reference to `mq_getattr'

[bluca]

lgtm

[bluca]

Thinking about this some more - it's not libudev calling that symbol from lrt, it's libsystemd which gets linked statically in libudev. Which raises the general point - we should have an automated system to percolate these dependencies through from meson to pkgconfig. @keszybz any opinion?

[floppym]

we should have an automated system to percolate these dependencies through from meson

I actually looked into that a bit, and I wasn't able to find any way to enumerate dependencies in meson to be able to pass them into the custom pc files that are merged using jinja.

meson's pkgconfig generator module would handle this automatically, but the structure of meson.build would need to be updated. To get correct output for both shared and static linking in the same pc file, libsystemd and libudev would need to be declared as using the plain library() function, instead of having the shared and static libs split into separate targets.

[bluca]

Ok, let's fix the immediate isssue for now