New comment by ailiop-git on void-packages repository https://github.com/void-linux/void-packages/pull/31331#issuecomment-858473922 Comment: > It doesn't seem to have created any additional dependency in the binary package, I assume because it dlopens things? Good catch. Yes, ulogd dlopens all the plugins, but that's not all. Wouldn't 04-generate-runtime-deps.sh scan all the shared objects anyway and pick up the deps? I think the issue is that the particular plugin doesn't actually depend on libpcap at runtime: ``` $ ldd ulogd_output_PCAP.so linux-vdso.so.1 (0x00007ffd0b919000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f68d00bc000) /usr/lib64/ld-linux-x86-64.so.2 (0x00007f68d028e000) ``` despite the plugin being compiled with the intention of linking against libpcap: `libtool: link: cc -shared -Wl,--as-needed -fPIC -DPIC .libs/ulogd_output_PCAP.o -lpcap -mtune=generic -O2 -g -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,--as-needed -Wl,-soname -Wl,ulogd_output_PCAP.so -o .libs/ulogd_output_PCAP.so ` That's because from what is seems there's really no actual code dependency to libpcap (the ulog plugin output doesn't use any functionality), so it only needs pcap.h during compilation for some structs. So we really don't need the build option (not for the pcap output plugin at least), so I'll push again making it unconditional. I suppose also a patch is needed for upstream to remove linking against pcap since this is not really needed.