On Sun, 19 Jul 2020 at 10:14:58 +0200, Arnaldo Pirrone wrote:
> Hi, after the update jackd is not starting anymore. Apparently this is
> related.
>
> Sun Jul 19 10:05:53 2020: ERROR: Can't load "/usr/lib/x86_64-linux-
> gnu/jack/jack_alsa.so": /usr/lib/x86_64-linux-gnu/jack/jack_alsa.so: undefined
> symbol: _ZN4Jack17JackServerGlobals26on_device_reservation_loopE
I looked into this a bit because it is now blocking testing migration
of the version of src:dbus-python that removed python-dbus (see
#936371). Please note that I know very little about JACK and how it's
meant to work, so I'm just working from knowledge of libraries in general.
Attempting to reproduce this:
- Have a Debian 10 VM. I used a minimal autopkgtest VM and installed
jackd and a basic GUI, with:
- apt install openbox xdm xorg xterm jackd2
- reboot
- Log in, open an xterm, and run jackd -d alsa
- If you have PulseAudio, prefix with "pasuspender --"
(my test VM is sufficiently minimal to not have PulseAudio)
- Add a bullseye apt source
- sudo apt update
- sudo apt install jackd2
- jackd -d alsa
- Add a sid apt source
- sudo apt update
- sudo apt install jackd2 (this upgrades libc6, among others)
- jackd -d alsa
- sudo apt dist-upgrade (this upgrades remaining packages to sid versions)
- jackd -d alsa
In each case jackd2 appeared to start successfully for
me, and its output said that it was creating an ALSA driver
"hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit" or similar. I didn't
(know how to) test that it can actually play back audio.
To the bug reporter: some other commands whose output might be useful,
replacing "jackd -d alsa" with however you normally run jackd, are:
find /usr/local -name '*jack*'
dpkg-query -W | grep jack
env LD_DEBUG=files jackd -d alsa
env LD_DEBUG=libs jackd -d alsa
ldd -r /usr/lib/x86_64-linux-gnu/libjackserver.so.0
strace -efile jackd -d alsa
debsums -s jackd2
debsums -s libjack-jackd2-0
(the last few require the strace and debsums packages installed).
To the maintainers:
It looks as though /usr/lib/x86_64-linux-gnu/jack/jack_alsa.so has undefined
symbols, including _ZN4Jack17JackServerGlobals26on_device_reservation_loopE,
that are not provided by any of its dependencies. The symbol
_ZN4Jack17JackServerGlobals26on_device_reservation_loopE appears to be
part of /usr/lib/x86_64-linux-gnu/libjackserver.so.0, which is a dependency
of /usr/bin/jackd; so when jackd dlopens jack_alsa.so, the undefined symbol
should be satisfied by the previously-loaded libjackserver.so.0 as per this
sentence from dlopen(3):
Symbol references in the shared object are resolved using (in order):
symbols in the link map of objects loaded for the main program and
its dependencies; [and some other places that don't matter]
Does that all look like the way it is meant to work?
This would probably be more robust if jack_alsa.so was linked with
-ljackserver so that it was self-contained. Ideally, it would be possible
to link it with the linker option -Wl,-z,defs to assert that all undefined
symbols are present in its dependencies.
I can reproduce lots of undefined symbols in
/usr/lib/x86_64-linux-gnu/jack/jack_alsa.so on a clean
installation in a VM (as above) by running
"ldd -r /usr/lib/x86_64-linux-gnu/jack/jack_alsa.so". The output I
see is similar to what the bug reporter sent. However, if I use
LD_PRELOAD=libjackserver.so.0, the undefined symbols go away, suggesting
that linking with -ljackserver would be sufficient to make the plugin
fully self-contained.
If JACK is portable to Windows, any plugins in the Windows build will
likely already have to be linked to -ljackserver, because Windows shared
libraries work differently - and indeed looking at the wscript, it seems
like driver modules are linked with "serverlib" on Windows and macOS,
so it would probably be a straightforward change to do the same on
all platforms.
Regards,
smcv
