Red Hat Bugzilla – Bug 476865
padsp LD_PRELOAD is not set well
Last modified: 2008-12-21 09:18:01 EST
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:22.214.171.124) Gecko/2008111217 Fedora/3.0.4-1.fc10 Firefox/3.0.4
I think the component must be pulseaudio-utils but it is not available in the list.
Anyway, padsp fail to LD_PRELOAD libpulsedsp.so. Changing line 79 and 81 from libpulsedsp.so to /usr/lib/libpulsedsp.so fix the problem
Steps to Reproduce:
1.Try to use padsp
2.See it fail
libpulsedsp.so fail to load and is not used
libpulsedsp.so load and is used
Uh? We explicitly set LD_PRELOAD to only the file name to make sure we get the path rights for 32 vs. 64 bit binaries.
Please set the env var LD_DEBUG=libs to find out where libc looks for libpulsedsp.so and why it doesn't find it.
Also, please be more elaborate in the exact error message you get.
Here is the error :
ERROR: ld.so: object 'libpulsedsp.so' from LD_PRELOAD cannot be preloaded: ignored.
Why don't you use /usr/$LIB/libaoss.so.0 like the alsa-oss wrapper script do?
Have you tried running your app with LD_DEBUG=libs set as requested?
(In reply to comment #2)
> Why don't you use /usr/$LIB/libaoss.so.0 like the alsa-oss wrapper script do?
What shall $LIBS refer to?
Please note that if you run 32bit binaries on amd64 you need a different path than when you run native 64bit binaries. (i.e. /usr/lib/libpulsedsp.so vs. /usr/lib64/libpulsedsp.so) If we leave the path unspecified libc will automatically use the right shared object for architecture of a binary. Except that that doesn't work for you. So please use LD_DEBUG=libs to find out why.
If alsa-oss hardcodes the path independantly of the arch of the process run then it is simply broken.
Hum, good point. I check the aoss wrapper script and $LIB is not defined anywhere. The weird thing is that it work anyway... I will report your solution to the maintainer of the aoss package for compatibility with both 32 and 64 bits.
I run with LD_DEBUG=libs and it load libpulsedsp.so just fine with most applications.
I cannot reproduce the problem right now. Yesterday it was not working and now padsp load libpuldsp.so just fine.
I guess we can close the bug for now.
OK, closing then. Feel free to reopen if you encounter the problem again and you can provide the LD_DEBUG=libs output.