Failed to load module "libcanberra-gtk-module.so"

[smurf]

Binary package hint: libcanberra-gtk-module

I wrote a little procedure in bash using Xdialog for GUIs.
Xdialog default behaviour is to use STDERR to pass the user input to the script, but in Jaunty I have severe problems because the message "Gtk-WARNING (recursed) **: Failed to load module "libcanberra-gtk-module.so": libcanberra-gtk-module.so: missed shared object" appears at every call of Xdialog.
I know that I can tell to Xdialog to use STDOUT instead of STDERR but in Intrepid everything was ok and now in Jaunty ... I don' t wish to rewrite the procedure.
Any work-around to fix it?

[Menno (m-tjoelker)]

There is a simple bypass, as the man page shows. The option '--stdout' will use STDOUT instead of STDERR.
Don't forget to change the redirection.

I noticed this problem too. What wonders me:
- Xdialog is complaining about a module that is there!
- Why does Xdialog need libcanberra in the first place?
- If Xdialog needs it, why isn't it designated as a dependency?

[smurf (luca-dgh)]

Yes Menno, I know that I can redirect the output on STDOUT instead of STDERR (standard), I wrote it in the first message.
Anyway, I found a workaround, setting to true (or 1) the environment variable XDIALOG_NO_GMSGS all messages from gtk engine are suppressed.
I don' t know if Ubuntu team wants to close this bug, your decision ;-)

[Menno (m-tjoelker)]

On Tue, 05 May 2009 20:56:04 -0000
smurf <email address hidden> wrote:

> Yes Menno, I know that I can redirect the output on STDOUT instead of STDERR (standard), I wrote it in the first message.
> Anyway, I found a workaround, setting to true (or 1) the environment variable XDIALOG_NO_GMSGS all messages from gtk engine are suppressed.
> I don' t know if Ubuntu team wants to close this bug, your decision ;-)
>

Hi Luca,

Indeed you mentioned the workaround by changing the channel used for
output; you were looking for a way to circumvent the issue by without
making changes to the script. Nice to see that you found a solution for
that.

I use Xdialog in a script that allows an end-user without any knowledge to
put a message on his website without active stuff at the server side,
without my intervention. The text is entered in an Xdialog edit-box. Suddenly
the user's message was preceeded by an error message. :-(

My first observation is, that it is strange to use STDERR for other
purposes than outputting error messages. After all, you cannot blame
gtk for sending error messages to STDERR!
Suppressing all error messages is a workaround with undesirable side-
effects: error messages usually are there with a purpose. It would be
much more logical if STDOUT would have been the default, but OK, you
an modify that behaviour (which I did).

The next thing is the error message by itself. The requested module is
simply there, in my installation, so there shouldn't be complaints about
it. Besides, it is not indicated as a dependency of Xdialog (well, maybe
it is an indirect dependency, I haven't checked that). libcanberra
deals with sound and I don't consider that as an essential part of the
functionality of Xdialog.

Summarizing: while this is not a really important bug (considering the
available bypasses), there still are some illogical/faulty things that
should be resolved sometime. Probably, it isn't that difficult either.

Let's wait for the comments of the developers.

Best regards,

Menno
--
Menno Tjoelker <email address hidden>

[smurf (luca-dgh)]

>My first observation is, that it is strange to use STDERR for other
>purposes than outputting error messages. After all, you cannot blame
>gtk for sending error messages to STDERR!

Definitely it is strange to use the STDERR instead of STDOUT, and after seen what happened in this case, I inmediately change it in the new script I' m writing.

>Suppressing all error messages is a workaround with undesirable side-
>effects: error messages usually are there with a purpose.

You are right, but in this case are suppressed only the errors from gtk 1.x.x, and probably if the gtk install is seriously broken your computer will show more problems...

>The next thing is the error message by itself. The requested module is
>simply there, in my installation

In my installation as well

>Besides, it is not indicated as a dependency of Xdialog (well, maybe
>it is an indirect dependency,

Xdialog developper assumes that gtk installation MUST be 100 % ok on each computer, for this reason he doesn' t care about dependencies.

>libcanberra deals with sound and I don't consider that as an essential part of the
>functionality of Xdialog.

Definetely it isn' t

Let's wait for news.
Regards.

 Luca

[Osobimbo (osobimbo01)]

for me feels like ubuntu is going by the way of microsoft

1.- You make an "upgrade" and simple things that used to work perfectly (i.e. Xdialog) all of a sudden stop working .
2.- Nobody knows how to direct you to the solution (i.e. use the STDERR instead of STDOUT) WHERE IN HEAVEN DO YOU DO THAT? /etc/stderr/stderr.config or what
3.- Who can explain why libcanberra is so important (by the way there are several libcanberra this and libcanberra that at synaptic) and if you type apt-get install libcanberra-etc repository does not found it
4.- Curious thing libcanberra IS INSTALLED.

so te solution is...

REINSTALL IBEX

[Menno (m-tjoelker)]

On Mon, 18 May 2009 04:33:40 -0000
Osobimbo <email address hidden> wrote:

> for me feels like ubuntu is going by the way of microsoft
>
> 1.- You make an "upgrade" and simple things that used to work perfectly (i.e. Xdialog) all of a sudden stop working .
> 2.- Nobody knows how to direct you to the solution (i.e. use the STDERR instead of STDOUT) WHERE IN HEAVEN DO YOU DO THAT? /etc/stderr/stderr.config or what
> 3.- Who can explain why libcanberra is so important (by the way there are several libcanberra this and libcanberra that at synaptic) and if you type apt-get install libcanberra-etc repository does not found it
> 4.- Curious thing libcanberra IS INSTALLED.
>
> so te solution is...
>

Hi,

Changing Xdialog to use STDOUT instead of STDERR is a matter of adding
an option to the command: --stdout. See the man page!

Menno

[Osobimbo (osobimbo01)]

Hi,

Changing Xdialog to use STDOUT instead of STDERR is a matter of adding
an option to the command: --stdout. See the man page!

Menno

still at a loss

~$ man stdout
No manual entry for stdout

a step by step would be nice

something in the like:

cd /yourhomedirectory/

cd .xdialog

there you find the configuration file named

xdialog.conf. (if something of the like exists)

change the line that says

using stdrrin and change to

using stdout ,save and you are on your way!!

at least point me to the file or better

say the magic words for

Changing Xdialog to use STDOUT instead of STDERR is a matter of adding
an option to the command:

WHERE?

[Osobimbo (osobimbo01)]

~$ stdout
bash: stdout: command not found

[Osobimbo (osobimbo01)]

Linux / Unix Command: stdout
Command Library
NAME
stdin stdout stderr - standard I/O streams
SYNOPSIS
Fd #include <stdio.h> Fd extern FILE *stdin; Fd extern FILE *stdout; Fd extern FILE *stderr;
DESCRIPTION
Under normal circumstances every Unix program has three streams opened for it when it starts up, one for input, one for output, and one for printing diagnostic or error messages. These are typically attached to the user's terminal (see tty(4)) but might instead refer to files or other devices, depending on what the parent process chose to set up. (See also the ``Redirection'' section of sh(1).)

The input stream is referred to as ``standard input''; the output stream is referred to as ``standard output''; and the error stream is referred to as ``standard error''. These terms are abbreviated to form the symbols used to refer to these files, namely stdin stdout and stderr

Each of these symbols is a stdio(3) macro of type pointer to FILE, and can be used with functions like fprintf(3) or fread(3).

Since FILEs are a buffering wrapper around Unix file descriptors, the same underlying files may also be accessed using the raw Unix file interface, that is, the functions like read(2) and lseek(2). The integer file descriptors associated with the streams stdin stdout and stderr are 0, 1, and 2, respectively. The preprocessor symbols STDIN_FILENO, STDOUT_FILENO, and STDERR_FILENO are defined with these values in <unistd.h>.

Note that mixing use of FILEs and raw file descriptors can produce unexpected results and should generally be avoided. (For the masochistic among you: POSIX.1, section 8.2.3, describes in detail how this interaction is supposed to work.) A general rule is that file descriptors are handled in the kernel, while stdio is just a library. This means for example, that after an exec, the child inherits all open file descriptors, but all old streams have become inaccessible.

Since the symbols stdin stdout and stderr are specified to be macros, assigning to them is non-portable. The standard streams can be made to refer to different files with help of the library function freopen(3), specially introduced to make it possible to reassign stdin stdout and stderr The standard streams are closed by a call to exit(3) and by normal program termination.
SEE ALSO
sh(1), csh(1), open(2), fopen(3), stdio(3)
CONSIDERATIONS
The stream stderr is unbuffered. The stream stdout is line-buffered when it points to a terminal. Partial lines will not appear until fflush(3) or exit(3) is called, or a newline is printed. This can produce unexpected results, especially with debugging output. The buffering mode of the standard streams (or any other stream) can be changed using the setbuf(3) or setvbuf(3) call. Note that in case stdin is associated with a terminal, there may also be input buffering in the terminal driver, entirely unrelated to stdio buffering. (Indeed, normally terminal input is line buffered in the kernel.) This kernel input handling can be modified using calls like tcsetattr(3); see also stty(1), and termios(3).
CONFORMING TO
The stdin stdout and stderr macros conform to St -ansiC , and this standard also stipulates that these three...

[Menno (m-tjoelker)]

On Wed, 20 May 2009 01:50:58 -0000
Osobimbo <email address hidden> wrote:

> still at a loss
>
> ~$ man stdout
> No manual entry for stdout

The command is Xdialog. So all you have to do is adding '--stdout' to
the lines containing the Xdialog command.
Probably you will want to use the output. Since the output stream has now
changed, things referring to the output stream must be changed too.
For instance, the examples have something like 'Xdialog 2>file ...'.
This can be replaced by 'Xdialog >file ...' (redirection of standard out
is the self-evident way).

Kind regards,

Menno Tjoelker

[Osobimbo (osobimbo01)]

Dear Menno I know you mean right but still no cigar
here is my humble script (not a big deal)

#!/bin/bash
#move data to folder
DIALOG=${DIALOG=Xdialog}
tempfile=`tempfile 2>/dev/null` || tempfile=/tmp/test$$
trap "rm -f $tempfile" 0 1 2 5 15

$DIALOG --title "photo control" --clear \
        --inputbox "write your number" 8 25 2> $tempfile
retval=$?

case $retval in
  0)
    echo "making file `cat $tempfile`"
#here is the twolines in question no big deal really (except for the canberra thing)

mkdir Desktop/may`cat $tempfile` #create a folder in Desktop
mv Desktop/videosp2/fot09-05-`cat $tempfile`* Desktop/may`cat $tempfile`/ # move files to created folder

;;
  1)
    echo "operation CANCELED";;
  255)
    if test -s $tempfile ; then
      cat $tempfile
    else
      echo "ABORT"
    fi

    ;;

esac

where I should put the '--stdout' in question?

sorry for the inconvenince still working with

ubuntu 9.04 Xaunty jackaloPe or ubuntu XP VISTA

[Menno (m-tjoelker)]

On Wed, 20 May 2009 15:48:28 -0000
Osobimbo <email address hidden> wrote:

Hi,

This is a bit out of order here since it has nothing to do with the actual
problem. It is setting up a bypass to deal with a somewhat clumsy use
of STDERR for other purposes than ouputting error messages.

The problem in your script is in this line:

> $DIALOG --title "photo control" --clear \
> --inputbox "write your number" 8 25 2> $tempfile

The error message is put in $tempfile and causes trouble later. If you
use stdout for the xdialog output instead of stderr, it will be OK again.
Replace the line above by:

> $DIALOG --title "photo control" --clear --stdout\
> --inputbox "write your number" 8 25 >$tempfile

The command option has been added, the redirection of stderr (2)
has been changed in redirection of stdout.

Kind regards,

Menno

[Osobimbo (osobimbo01)]

sorry Menno but there must be something very wrong because it creates a lot of directories (empty) inside the directory
so Ill give it a rest and reinstall ibex as jaunty proved to be a dissapointment (for me) I like to thank you thou for your valuable time but I still think we should not have this conversation al all.

[maccus (maccus)]

I have recently upgraded from Intrepid to Jaunty over the net and I had no problem with Xdialog and libcanberra-gtk. However when I did the upgrade on another machine, which is nearly identical, the problem popped up in Xdialog and I was unable to run my MaxMenu script collection (which by the way is in my PPA).

The thing that worked for me is this line at the beginning of the main script:

grep -q 'jaunty' "/etc/lsb-release" && export XDIALOG_NO_GMSGS=1

Regards, Max

[Ceejay (ceejay-slim)]

OK, back to the bug... I had exactly the same problem - I guess that in writing our scripts we were probably following similar models given in the Xdialog documentation!

Both of the workarounds work for me, so my scripts work again, which is great.

But can someone please remember that there does seem to be a bug here, which is that Xdialog is kicking out these incorrect warnings about an apparently irrelevant file not existing when it does!

Thanks

[Jan Groenewald (jan-aims)]

I get this on Ubuntu 64bit jaunty with backports, up to date:

0 jan@muizenberg:~$grep libcan .xsession-errors
Gtk-Message: Failed to load module "canberra-gtk-module": /usr/lib/gtk-2.0/modules/libcanberra-gtk-module.so: wrong ELF class: ELFCLASS64

[Daniel Hahler (blueyed)]

I am converting this to a question given the original reporter asking for redirection of STDERR to workaround the actual problem.

Please refer to any other bugs about the issue itself, or create a new one, if your specific issue is not handled somewhere already.

Please note that you might just have to install both libcanberra-gtk-module and libcanberra-gtk3-module (bug 872172), or just remove both libcanberra-gtk-module and libcanberra-gtk3-module.