It appears that once libgstimxaudio.so has been linked to lib_mp3_enc_arm12_elinux.so.2, at runtime this library can not be resolved by the dynamic linker - resulting in failure of loading the plugin:
Failed to load plugin '/usr/lib/arm-linux-gnueabihf/gstreamer-1.0/libgstimxaudio.so': lib_mp3_enc_arm12_elinux.so.2: cannot open shared object file: No such file or directory
By using strace it can be verified that the shared library is found, opened, it's elf header parsed, and finally closed.
I haven't finished researching the root cause of this, but it appears that the dynamic linker (glibc) checks the elf header against a set of expected values, including VALID_FLOAT_ABI (ehdr->e_flags) which is defined as eabi v5 and either soft or hard fp convention.
Quick testing has shown that dlopening the library is possible though, and might be the required method for using this mp3 decoder, at least on Debian Buster where I tested this.
It appears that once libgstimxaudio.so has been linked to lib_mp3_enc_arm12_elinux.so.2, at runtime this library can not be resolved by the dynamic linker - resulting in failure of loading the plugin: Failed to load plugin '/usr/lib/arm-linux-gnueabihf/gstreamer-1.0/libgstimxaudio.so': lib_mp3_enc_arm12_elinux.so.2: cannot open shared object file: No such file or directory
By using strace it can be verified that the shared library is found, opened, it's elf header parsed, and finally closed.
I haven't finished researching the root cause of this, but it appears that the dynamic linker (glibc) checks the elf header against a set of expected values, including VALID_FLOAT_ABI (ehdr->e_flags) which is defined as eabi v5 and either soft or hard fp convention.
Quick testing has shown that dlopening the library is possible though, and might be the required method for using this mp3 decoder, at least on Debian Buster where I tested this.