That's interesting. I'm not sure I completely understand it though, what component is linked against libraries that have unresolved symbols??
The program that gave the unresolved symbol was SoX's "play" program when trying to use the plugin (user space driver).
The JRMC28 logs did not include any specific details about unresolved symbols. I found the snd_lib_error unresolved symbol by running another application that did dump a detailed enough error statement to point in the right direction. The "fix/linker options" worked for that program and JRMC28 as a bonus.
I grepped the "strings" output on Debian 10 of both the resulting linker options of the driver's .so which yielded same results of [
snd_lib_error@@ALSA_0.9 vs
snd_lib_error@@ALSA_0.9].
I grepped the "strings" output on Debian 11 of both the resulting linker options of the driver's .so which yielded the delta of [
snd_lib_error vs
snd_lib_err@ALSA_0.9], with the latter one addressing the missing symbol.
strings libasound_module_pcm_cdsp.so | grep snd_lib_error
So far it works on both Debian 11's 5.10 default and 5.14 (improved lower latency USB music driver) backports kernels. Hope it doesn't mean it is regressing to an earlier version of ALSA. Version 0.9 appears to be quite old (@ 2003).
Debian 10 alsa-utils is on 1.1.8-2
Debian 11 alsa-utils is on 1.2.4-1
Debian 12 alsa-utils is currently on 1.2.5.1-1