Re: [Pan-users] Pan 0.139 refuses to start!

[Duncan]

Maurice Batey posted on Thu, 20 Jun 2013 19:57:14 +0100 as excerpted:

> Just when all seemed to be sorted out, all of a sudden Pan cannot start!
> 
> ----------------------------
> $ pan Gtk -Message: Failed to load module canberra-gtk-module
> Added 0 files to queue. exiting.!
> ----------------------------
> 
> Tried uninstalling/re-installing Pan.
> Tried re-boot.
> 
> Still same thing, so have had to move back onto Mageia-2 and 'old' Pan
> to be able to post this.
> 
> Anyone seen the above before? Know how to prevent it?!

I'm *NOT* a gtk guru and never claimed to be, but I /believe/ canberra is 
the gtk sound event module.  Or maybe it's simply the /event/ module, 
perhaps related to libnotify, etc?  In any case, being kde based here, 
with gtk2 only, I don't have libcanberra installed.  But pan is likely to 
be built against it and thus require it to run on a gtk/gnome based 
distro.

Quick google: http://www.google.com/search?q=libcanberra

Seems to confirm my belief, gtk sound.

So: Did you notice any oddities with sound before/during the problem?  
Did you do an update that might have updated it and screwed things up?

One reasonably simple check you can do is to run...

ldd pan

... (or specify the path, /usr/bin/pan or whatever, if necessary) at a 
command prompt.

That lists all the libraries and their resolutions.  All should have a 
number in parentheses at the right, which I /believe/ is a checksum, and 
MOST should have the name followed by an => arrow pointing to the 
filesystem path to the for that library as well.  There's a couple noted 
exceptions to the path thing, linux-vdso.so.1 (amd64 name, there's a 
similar but not identical x86 version) is a "virtual" library provided by 
the kernel itself, so won't have a path but WILL have the checksum, and 
the dynamic loader library itself, without the arrow resolution as it's 
hard-coded to a specific path (/lib64/ld-linux-x86-64.so.2, amd64 version 
on gentoo/amd64), being the library that actually performs the loading of 
all the other libs, so its path MUST be hard-coded.

If libcanberra shows up in that list, but WITHOUT a corresponding => path 
and checksum resolution, then you've confirmed your problem, either a 
missing library or one that the dynamic loader can't find for some 
reason.  If it shows up with that resolution, then you know the library's 
at least on your system and being found properly, and can look into the 
issue further.  (Maybe a recent incompatible update, for instance, or 
it's loaded but the sound system crashed so the library's going 
unresponsive due to that, or...)

FWIW, a quick grep of the ldd output here doesn't find a "can" at all 
(but does return hits on simply "lib", so I know the grep is working).  
So my build isn't linked against that library at all, which is 
unsurprising as I'm on gentoo so do my own builds, and I don't have it on 
the system to link against.  If it were required, I'd have a build-time 
error, but it's obviously not required by pan, but probably linked in on 
your system due to the build-time options chosen.  (I'd guess it's an 
indirect dep, pan deps on gtk, which deps on libcanberra on that system, 
or some such.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman