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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
