test-alsa-ctl fails with bluealsa-mock: W: Couldn't get HCI device info: Address family not supported by protocol about bluez-alsa

[arkq]

It seems that the problem is indeed with libsandbox.so being preloaded.

Maybe you are more familiar with running application in Gentoo's sandbox. When running tests, in bluez-alsa, I'm preloading custom library to catch calls to ALSA library in order not to use system-wide ALSA configuration. This works fine outside of the sandbox, but when running ebuild bluez-alsa-9999.ebuild test it fails to work. The flow is as follows:

1. Run test application.
2. The getenv(LD_PRELOAD) shows: libsandbox.so
3. Customize LD_PRELOAD (prepend .libs/aloader.so to it)
4. Call execve() on self with modified env.
5. The getenv(LD_PRELOAD) shows: .libs/aloader.so:libsandbox.so
6. The aloader.so is detected in LD_PRELOAD, so test application proceeds with tests
7. Run ldd on self (i.e.: sprintf(command, "ldd %s", argv[0])), which shows:

   linux-vdso.so.1 (0x00007ffdcb7e8000)
   libsandbox.so => /usr/lib64/libsandbox.so (0x00007f7ee4320000)
   libasound.so.2 => /usr/lib64/libasound.so.2 (0x00007f7ee4237000)
   libcheck.so.0 => /usr/lib64/libcheck.so.0 (0x00007f7ee4229000)
   libc.so.6 => /usr/lib64/libc.so.6 (0x00007f7ee404a000)
   libm.so.6 => /usr/lib64/libm.so.6 (0x00007f7ee3f69000)
   /lib64/ld-linux-x86-64.so.2 (0x00007f7ee435a000)
   

The custom library is not preloaded.... So, the test will fail if the bluez-alsa is already installed on the system.

@pacho2, have you even seen similar issues when installing packages from portage?

EDIT:
It seems that the issue is within bluez-alsa code.