Bug 476865 - padsp LD_PRELOAD is not set well
padsp LD_PRELOAD is not set well
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: pulseaudio (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Lennart Poettering
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-17 11:16 EST by Jean-Francois Saucier
Modified: 2008-12-21 09:18 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-21 09:18:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jean-Francois Saucier 2008-12-17 11:16:37 EST
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.4) 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

Reproducible: Always

Steps to Reproduce:
1.Try to use padsp
2.See it fail
3.Check /usr/bin/padsp
Actual Results:  
libpulsedsp.so fail to load and is not used

Expected Results:  
libpulsedsp.so load and is used
Comment 1 Lennart Poettering 2008-12-17 15:40:31 EST
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.
Comment 2 Jean-Francois Saucier 2008-12-17 19:52:06 EST
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?
Comment 3 Lennart Poettering 2008-12-18 06:50:13 EST
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.
Comment 4 Jean-Francois Saucier 2008-12-18 16:18:57 EST
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.

Thank you.
Comment 5 Lennart Poettering 2008-12-21 09:18:01 EST
OK, closing then. Feel free to reopen if you encounter the problem again and you can provide the LD_DEBUG=libs output.

Note You need to log in before you can comment on or make changes to this bug.