In RHEL 10 and ELN, pipewire-jack-audio-connection-kit-libs provides the sole implementation of libjack.so.0()(64bit), and pw-j-a-c-k-devel wrt pkgconfig(jack), but its libjack is not installed into the default search path, and the ld.so.conf.d snippet in pw-j-a-c-k is not pulled in by default. As a result, libraries and executables which are built against them cannot find libjack:

/usr/bin/ld: warning: libjack.so.0, needed by /usr/lib64/libmpv.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: /usr/lib64/libmpv.so: undefined reference to `jack_activate'
/usr/bin/ld: /usr/lib64/libmpv.so: undefined reference to `jack_client_close'
/usr/bin/ld: /usr/lib64/libmpv.so: undefined reference to `jack_set_graph_order_callback'
/usr/bin/ld: /usr/lib64/libmpv.so: undefined reference to `jack_get_buffer_size'
/usr/bin/ld: /usr/lib64/libmpv.so: undefined reference to `jack_set_process_callback'
/usr/bin/ld: /usr/lib64/libmpv.so: undefined reference to `jack_get_sample_rate'
/usr/bin/ld: /usr/lib64/libmpv.so: undefined reference to `jack_connect'
/usr/bin/ld: /usr/lib64/libmpv.so: undefined reference to `jack_set_buffer_size_callback'
/usr/bin/ld: /usr/lib64/libmpv.so: undefined reference to `jack_port_get_buffer'
/usr/bin/ld: /usr/lib64/libavdevice.so.60: undefined reference to `jack_set_xrun_callback'
/usr/bin/ld: /usr/lib64/libmpv.so: undefined reference to `jack_client_open'
/usr/bin/ld: /usr/lib64/libavdevice.so.60: undefined reference to `jack_deactivate'
/usr/bin/ld: /usr/lib64/libavdevice.so.60: undefined reference to `jack_frames_since_cycle_start'
/usr/bin/ld: /usr/lib64/libmpv.so: undefined reference to `jack_get_ports'
/usr/bin/ld: /usr/lib64/libmpv.so: undefined reference to `jack_port_name'
/usr/bin/ld: /usr/lib64/libmpv.so: undefined reference to `jack_port_register'
/usr/bin/ld: /usr/lib64/libavdevice.so.60: undefined reference to `jack_on_shutdown'

e.g. https://koji.fedoraproject.org/koji/taskinfo?taskID=121573415

RHEL 10 and ELN itself have not seen this because only one package (SDL2) has a libjack dependency, and it {{dlopen()}}s it rather than linking against it.

Fedora and EPEL 9 have not seen this, because they also have the standalone j-a-c-k, which provides the same libjack.so.0()(64bit) and pkgconfig(jack) etc. installed into the standard paths, and it gets chosen by default at build- and runtime because its version number is higher.

This will affect EPEL 10, until somebody builds the standalone j-a-c-k, at which point it will do the same as other releases. However, that should not be a requirement for an OOTB working experience, only an option.

(ELN Extras is also affected, and building a standalone j-a-c-k there won't help, as fedora-release-eln suggests the pipewire implementations to keep the standalone out of ELN. But this is not just an ELN Extras problem, just where it first appeared.)

Ultimately, this is all due to the split between pw-j-a-c-k (which provides the ld.so.conf.d snipped) and pw-j-a-c-k-libs which is not installed into %_libdir. I'm not entirely sure what the "proper" fix for this is without changing the current paradigms. Having pw-j-a-c-k-devel also require pw-j-a-c-k (and not just pw-j-a-c-k-libs) would cover up the build issues but wouldn't fix the runtime issues. Simply reuniting the pw-j-a-c-k and pw-j-a-c-k-libs packages might be the only workable solution.