Hi, On Wed, Feb 25, 2009 at 6:13 PM, Erich Boleyn <erich at uruk.org> wrote: > > Greetings all, > > I tried building and running the new PulseAudio, and it is getting > module load failures for the alsa-related modules. > > For example, in the "/usr/bin/pulseaudio --dump-modules" command, > it get the following failures: > > ? ? ? ?E: modinfo.c: Failed to open module "/usr/lib64/pulse-0.9.15/modules/module-alsa-card": file not found > ? ? ? ?E: modinfo.c: Failed to open module "/usr/lib64/pulse-0.9.15/modules/module-alsa-sink": file not found > ? ? ? ?E: modinfo.c: Failed to open module "/usr/lib64/pulse-0.9.15/modules/module-alsa-source": file not found Ditto here. I pinged Lennart about this on IRC the other day, but unfortunately I had to run before I was able to resolve this. The initial effort suggested by Lennart is to run `strace -eopen` on pulseaudio, and look through the open() calls for NSFD (No Such File or Directory). It's gonna have several of them due to the way resources and libraries are found by searching through a list of paths, but each unique filename it tries to look up should ultimately result in a "good" open() call (i.e., no error). My investigation suggests that it's able to open() these sinks numerous times, so maybe the problem is that it can't open them when it really needs to. I'm just not sure without further investigation. I do have a gut feeling, though, that it has something to do with libtool and its attempt to resolve the symbols in the modules. When PA calls lt_dlopenext(), libltdl will bail out as soon as it fails to resolve a symbol or a link-time library dependency. The problem is occurring because it bails out with a NULL pointer, and the lt_dlerror() call indicates "file not found" (which would indicate that, somewhere along the line, an ENOENT was produced by some code); but I am skeptical about whether "file not found" really means that as such, or whether it means "I tried to resolve a symbol, but couldn't". The string "file not found" is not present in the C library (according to the `strings` program), so a direct libc call can't be producing this message. If a libc call (i.e., fopen()) got an error, the errno would be set so that strerror(ENOENT) yields the text "No such file or directory". I'm thinking that this problem is unusually difficult to debug because libltdl is *not* robust in its error reporting! I'm on Ubuntu 9.04 Alpha, x86_64. What is your platform, out of interest? I'll keep you posted as to whether I make progress towards resolving this issue or not. Thanks, Sean > > > I could probably do a better job debugging what's wrong, but won't > have time to look at it for at least a week (crunch at work). > > -- > ? ?Erich Stefan Boleyn ? ? <erich at uruk.org> ? ? http://www.uruk.org/ > "Reality is truly stranger than fiction; Probably why fiction is so popular" > _______________________________________________ > pulseaudio-discuss mailing list > pulseaudio-discuss at mail.0pointer.de > https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss >
