Closed pacho2 closed 5 months ago
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:
getenv(LD_PRELOAD)
shows: libsandbox.so
.libs/aloader.so
to it)execve()
on self with modified env.getenv(LD_PRELOAD)
shows: .libs/aloader.so:libsandbox.so
aloader.so
is detected in LD_PRELOAD, so test application proceeds with testsldd
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.
Thanks a lot, it works fine now
Problem
With bluez-alsa-4.2.0, test-alsa-ctl fails on Gentoo (maybe because of it running on a sandboxed environment):
Setup
Gentoo Linux
4.2.0
5.75
1.2.11