Debian Bug report logs - #377468
djvulibre-plugin: undefined symbol XtShellStrings in nsdejavu.so

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Max <relf@os2.ru>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: djvulibre-plugin: undefined symbol XtShellStrings in nsdejavu.so

Date: Sun, 09 Jul 2006 02:26:43 -0700

Package: djvulibre-plugin
Version: 3.5.17-1
Severity: grave
Justification: renders package unusable

I constantly get complains from Mozilla Seamonkey:

LoadPlugin: failed to initialize shared library 
/usr/lib/netscape/plugins-libc6/nsdejavu.so 
[/usr/lib/netscape/plugins-libc6/nsdejavu.so: undefined symbol: 
XtShellStrings]

To get rid of these complains I'm forced to use 
LD_PRELOAD=/usr/lib/libXt.so.6.0.0 while running Seamonkey.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'sarge-unsupported')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17.64
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)

Versions of packages djvulibre-plugin depends on:
ii  djview                        3.5.17-1   Viewer for the DjVu image format
ii  libc6                         2.3.6-15   GNU C Library: Shared libraries

Versions of packages djvulibre-plugin recommends:
ii  mozilla-browser             2:1.7.13-0.2 The Mozilla Internet application s

-- debconf-show failed

Message #12 received at 377468@bugs.debian.org (full text, mbox, reply):

From: "Barak A. Pearlmutter" <barak@cs.nuim.ie>

To: Max <relf@os2.ru>

Cc: 377468@bugs.debian.org

Subject: Re: Bug#377468: djvulibre-plugin: undefined symbol XtShellStrings in nsdejavu.so

Date: Sun, 09 Jul 2006 11:10:01 +0100

Thanks for the report.  (I have lowered the severity for purely
technical reasons: (1) the issue affects only some users, (2) there is
a simple workaround, and (3) it does not render the entire system
unusable.  This does not imply any reluctance to fix the problem in a
timely fashion.)

In any case, I would like to make a request.  Could I trouble you to
please include sufficient detail to allow replication of the bug by
someone---like me---who normally uses firefox?  Best would be a
precise list of relevant installed packages, any relevant
configuration information, and whatever commands/keystrokes/URLS are
needed to manifest this problem.  Similarly precise details concerning
the workaround you found would also be helpful.

Also, I am not using an amd64 machine.  Do you happen to know if the
issue also manifests under i386?
--
Barak A. Pearlmutter
 Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
 http://www.bcl.hamilton.ie/~barak/

Message #17 received at 377468@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: 377468@bugs.debian.org

Subject: Re: djvulibre-plugin: undefined symbol XtShellStrings in nsdejavu.so

Date: Sun, 9 Jul 2006 10:35:09 -0700

> In any case, I would like to make a request.  Could I trouble you to
> please include sufficient detail to allow replication of the bug by
> someone---like me---who normally uses firefox?

This bug is easily demonstrable using the command:

$ ldd -d -r /usr/lib/netscape/plugins-libc6/nsdejavu.so 

The plugin is not properly linked against the libraries that it depends on.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Message #22 received at 377468@bugs.debian.org (full text, mbox, reply):

From: "Barak A. Pearlmutter" <barak@cs.nuim.ie>

To: Steve Langasek <vorlon@debian.org>

Cc: 377468@bugs.debian.org

Subject: Re: Bug#377468: djvulibre-plugin: undefined symbol XtShellStrings in nsdejavu.so

Date: Mon, 10 Jul 2006 11:02:22 +0100

> This bug is easily demonstrable using the command:
>
> $ ldd -d -r /usr/lib/netscape/plugins-libc6/nsdejavu.so 
>
> The plugin is not properly linked against the libraries that it depends on.

I've consulted with upstream, and the issue may be a little more
complex.  What if the browser itself already uses libXt, and links to
a different version of the library than the plugin?  Why does the
problem only manifest on some platforms?  I'd like to understand
what's going on before doing some patch-up solution which may do more
harm than good, eg mess up the plugin when used with some browser with
which it is currently working, or mess things up when some broswer is
upgraded, or cause mysterious failures in the future due to silent
conflicting library breakage.

Datapoint: the following plugins on my system fail your "all symbols
resolve" test:

  $ cd /usr/lib/mozilla/plugins
  $ for f in *.so; do echo $f; ldd -r $f 2>&1; done | more

gives at least one "undefined symbol" for:

  mozplugger.so
  nsdejavu.so

one plugin reports a versioning issue:

  libvlcplugin.so
  ./libvlcplugin.so: /usr/lib/libtheora.so.0: no version information available (required by ./libvlcplugin.so)
	  linux-gate.so.1 =>  (0xffffe000)
	  libXt.so.6 => /usr/lib/libXt.so.6 (0xa7cd2000)
	  libX11.so.6 => /usr/lib/libX11.so.6 (0xa7c0c000)
	  libSM.so.6 => /usr/lib/libSM.so.6 (0xa7c03000)

and some non-Debian plugins have undefined symbols:

  libflashplayer.so
  nphelix.so

The helix-player plugins also have unresolved symbols.

One thought would be to have a "plugin installation" process, similar
in spirit to the process by which emacs lisp code is compiled for
individual emacsen.  The idea would be to re-link plugins for each
browser as necessary.  Seems like overkill though.  Thoughts?
--
Barak A. Pearlmutter
 Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
 http://www.bcl.hamilton.ie/~barak/

Message #27 received at 377468@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: "Barak A. Pearlmutter" <barak@cs.nuim.ie>

Cc: 377468@bugs.debian.org

Subject: Re: Bug#377468: djvulibre-plugin: undefined symbol XtShellStrings in nsdejavu.so

Date: Mon, 10 Jul 2006 03:45:18 -0700

[Message part 1 (text/plain, inline)]

On Mon, Jul 10, 2006 at 11:02:22AM +0100, Barak A. Pearlmutter wrote:
> > This bug is easily demonstrable using the command:

> > $ ldd -d -r /usr/lib/netscape/plugins-libc6/nsdejavu.so 

> > The plugin is not properly linked against the libraries that it depends on.

> I've consulted with upstream, and the issue may be a little more
> complex.  What if the browser itself already uses libXt, and links to
> a different version of the library than the plugin?

Then you're screwed whether or not nsdejavu.so properly declares its own
dependencies, because the browser's version of libXt is not guaranteed to
provide the ABI that the djvu plugin is expecting.  (Indeed, the chances
that it *will* provide the same ABI are rather small, since ABI changes are
precisely why you would *have* two different versions of libXt.)  So
declaring the dependency is still the correct thing to do.

> Why does the problem only manifest on some platforms?

It would entirely depend on whether the particular browser being used is
linked against libXt.  It might not even be a question of architecture, it
might be a question of which browser variant a user chooses to use.  E.g.,
the submitter specifically mentions running "Seamonkey", so may not be using
Debian packages of mozilla at all in this case.

> One thought would be to have a "plugin installation" process, similar
> in spirit to the process by which emacs lisp code is compiled for
> individual emacsen.  The idea would be to re-link plugins for each
> browser as necessary.  Seems like overkill though.  Thoughts?

Um.  *Way* overkill, and the libs that your plugin needs to have loaded at
runtime don't vary with browser -- all that varies is how many of these libs
are pre-loaded for you by the browser.

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

[signature.asc (application/pgp-signature, inline)]

Message #32 received at 377468@bugs.debian.org (full text, mbox, reply):

From: "Barak A. Pearlmutter" <barak@cs.nuim.ie>

To: Steve Langasek <vorlon@debian.org>

Cc: 377468@bugs.debian.org

Subject: Re: Bug#377468: djvulibre-plugin: undefined symbol XtShellStrings in nsdejavu.so

Date: Mon, 10 Jul 2006 12:52:00 +0100

The LD_PRELOAD workaround is an effective workaround for now, so this
isn't actually causing any serious pain at the moment.

It is trivial enough to add the dependency.  I'm just not sure if
that's the correct thing to do.  If you are *positive* I'll believe
you.  I will note that the seamonkey browser is not currently in
Debian, and that this issue does not, to my knowledge, manifest using
any actual Debian browser.  Moreover, since the plugin protocol
sort-of requires libXt, maybe browsers that don't use libXt themselves
should yank in the library anyway in order to service plugins, kind of
like an internal mimic of the effect of an appropriate LD_PRELOAD?  In
fact, maybe that's something they're supposed to be doing already,
making this a seamonkey bug?  I'd really like to get the opinion of
someone actually familiar with this stuff, instead of just guessing.

>> What if the browser itself already uses libXt, and links to a
>> different version of the library than the plugin?

> Then you're screwed whether or not nsdejavu.so properly declares its own
> dependencies, because the browser's version of libXt is not guaranteed to
> provide the ABI that the djvu plugin is expecting.

You know, these are just tiny little plugins!  It seems quite likely
that ABI changes that require an so-lib name rev would be in portions
of the ABI that the plugin does not exercise.  That is a good example
of a situation where an explicit dependency in the plugin itself might
cause trouble in the future.

Upstream has apparently had some actual problematic library conflicts
caused by including an explicit dependency.  Here is what they said
when I asked "why no explicit dependency in build scripts?"

  > The reason was that some browsers were linked with custom or
  > static versions of libXt, and we wanted to use whatever Xt they
  > were using internally.  Note that the plugin protocol sort-of
  > require libXt to capture the events.  Which browser is causing
  > problems?

So, who's a big web plugin expert?
--
Barak A. Pearlmutter
 Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
 http://www.bcl.hamilton.ie/~barak/

Message #37 received at 377468@bugs.debian.org (full text, mbox, reply):

From: "Barak A. Pearlmutter" <barak@cs.nuim.ie>

To: Max Alekseyev <relf@os2.ru>

Cc: 377468@bugs.debian.org

Subject: Re: Bug#377468: djvulibre-plugin: undefined symbol XtShellStrings in nsdejavu.so

Date: Thu, 13 Jul 2006 11:24:42 +0100

Thanks.

My best guess on this right now is that the bug is an
architecture-specific amd64 bug in seamonkey, with seamonkey providing
a correct environment for plugins on i386 but not on amd64.  Seamonkey
isn't a Debian package, so I can't really reassign this bug, or
(without more information from you, like full seamonkey version
details etc) even reproduce it without a lot of guesswork.

I'm therefore going to:

 - leave this bug open for now until I'm not just *guessing*, but
   actually sure about what the underlying problem is.

 - try to find someone who actually knows a lot about how mozilla
   plugins are supposed to work to discuss this with.

You might want to bring the issue up with the seamonkey people; they
may be in a better position to deal with it appropriately.

Thanks again for the bug report,
--
Barak A. Pearlmutter
 Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
 http://www.bcl.hamilton.ie/~barak/

Message #42 received at 377468@bugs.debian.org (full text, mbox, reply):

From: Max Alekseyev <relf@os2.ru>

To: barak@cs.nuim.ie

Subject: Re: Bug#377468: djvulibre-plugin: undefined symbol XtShellStrings in nsdejavu.so

Date: Sun, 09 Jul 2006 04:01:47 -0700

I believe to reproduce the problem it's enough to have djvulibre-plugin installed with any Mozilla software.
In my case it's seamonkey. And it start complaining about undefined symbol XtShellStrings in nsdejavu.so right after I started it. No other action required. Complains go to console from where it was started.

I cannot reproduce the problem under debian-i386 so it may be amd64-specific.

Btw, I noticed the following discrepancy in i386 and amd64 builds of nsdejavu.so:

debian-i386:
$ ldd /usr/lib/netscape/plugins-libc6/nsdejavu.so
        linux-gate.so.1 =>  (0xffffe000)
        libc.so.6 => /lib/tls/libc.so.6 (0xb7e54000)
        /lib/ld-linux.so.2 (0x80000000)

debian-amd64:
$ ldd /usr/lib/netscape/plugins-libc6/nsdejavu.so
        libc.so.6 => /lib64/libc.so.6 (0x00002b9597ab3000)
        /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)

As one can see linux-gate.so.1 is missing in amd64 build.

Max

Barak A. Pearlmutter wrote:
> Thanks for the report.  (I have lowered the severity for purely
> technical reasons: (1) the issue affects only some users, (2) there is
> a simple workaround, and (3) it does not render the entire system
> unusable.  This does not imply any reluctance to fix the problem in a
> timely fashion.)
> 
> In any case, I would like to make a request.  Could I trouble you to
> please include sufficient detail to allow replication of the bug by
> someone---like me---who normally uses firefox?  Best would be a
> precise list of relevant installed packages, any relevant
> configuration information, and whatever commands/keystrokes/URLS are
> needed to manifest this problem.  Similarly precise details concerning
> the workaround you found would also be helpful.
> 
> Also, I am not using an amd64 machine.  Do you happen to know if the
> issue also manifests under i386?
> --
> Barak A. Pearlmutter
>  Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
>  http://www.bcl.hamilton.ie/~barak/
> 

Message #47 received at 377468@bugs.debian.org (full text, mbox, reply):

From: Miroslaw Kwasniak <mirek@zind.ikem.pwr.wroc.pl>

To: 377468@bugs.debian.org

Subject: Re: Bug#377468: djvulibre-plugin: undefined symbol XtShellStrings in nsdejavu.so

Date: Wed, 11 Jun 2008 14:00:43 +0200

found 377468 3.5.20-7
thanks

This bug is stil alive:

  djvulibre-plugin 3.5.20-6/3.5.20-7
  iceape 1.0.11~pre071022-0etch1+lenny1

On Sun, Jul 09, 2006 at 04:01:47AM -0700, Max Alekseyev wrote:
> I believe to reproduce the problem it's enough to have djvulibre-plugin installed with any Mozilla software.
> In my case it's seamonkey. And it start complaining about undefined symbol XtShellStrings in nsdejavu.so right after I started it. No other action required. Complains go to console from where it was started.
>
> I cannot reproduce the problem under debian-i386 so it may be amd64-specific.

> Btw, I noticed the following discrepancy in i386 and amd64 builds of nsdejavu.so:
>
> debian-i386:
> $ ldd /usr/lib/netscape/plugins-libc6/nsdejavu.so

It should be: "ldd -d -r"

Message #52 received at 377468@bugs.debian.org (full text, mbox, reply):

From: Bastien ROUCARIES <roucaries.bastien+debian@gmail.com>

To: debian-devel@lists.debian.org, modestas@vainius.eu, fabo@debian.org, pino@kde.org, debian@pusling.com, pkg-mozilla-maintainers@lists.alioth.debian.org, hjheins@gmail.com, jaldhar@debian.org, glandium@debian.org, asac@debian.org

Cc: 377468@bugs.debian.org, eric@debian.org, glandium@debian.org, lool@dooz.org, debian-qt-kde@lists.debian.org, ana@debian.org

Subject: Help needed for #377468

Date: Sat, 20 Dec 2008 15:50:21 +0100

[Message part 1 (text/plain, inline)]

Hi!

I would like to ask for some help for the bug #377468, if possible,
please. Particularly from a mozilla-plugin wizard.

The problem is that djvulibre in upstream is not linked against a particular libXt 
in order to adapt against different libXt version depending of the browser used.
The question raised by the upsteam is the case of the browser itself already uses libXt, and links to
a different version of the library than the plugin. 

This bug is easily demonstrable using the command [1]:
$ ldd -d -r /usr/lib/netscape/plugins-libc6/nsdejavu.so  

But this behavior is quite fragile and could break [2] and I personally think that on debian browser and plugin 
will use the same version of library.

Does my assertion is always valid? Can I enforce linking against libXt at build time? 

BTW should we contact other plugin developper about bug like this and should we document this issue?

Regards

Bastien
-- 

"ROUCARIÈS Bastien"
                                           roucaries.bastien+debian@gmail.com
-------------------------------------------------------------------------------
DO NOT WRITE TO roucaries.bastien+blackhole@gmail.com OR BE BLACKLISTED

[signature.asc (application/pgp-signature, inline)]

Message #57 received at 377468@bugs.debian.org (full text, mbox, reply):

From: Thomas Viehmann <tv@beamnet.de>

To: Bastien ROUCARIES <roucaries.bastien+debian@gmail.com>

Cc: debian-devel@lists.debian.org, pkg-mozilla-maintainers@lists.alioth.debian.org, 377468@bugs.debian.org, debian-qt-kde@lists.debian.org

Subject: Re: Help needed for #377468

Date: Sat, 20 Dec 2008 16:22:41 +0100

Bastien ROUCARIES wrote:
> I would like to ask for some help for the bug #377468, if possible,
> please. Particularly from a mozilla-plugin wizard.

> The problem is that djvulibre in upstream is not linked against a particular libXt 
> in order to adapt against different libXt version depending of the browser used.
> The question raised by the upsteam is the case of the browser itself already uses libXt, and links to
> a different version of the library than the plugin. 

> This bug is easily demonstrable using the command [1]:
> $ ldd -d -r /usr/lib/netscape/plugins-libc6/nsdejavu.so  

> But this behavior is quite fragile and could break [2] and I personally think that on debian browser and plugin 
> will use the same version of library.

> Does my assertion is always valid? Can I enforce linking against libXt at build time? 

> BTW should we contact other plugin developper about bug like this and should we document this issue?

Just having made this choice w.r.t. to nsdejavu and pthread for properly
fixing #504740, I'd recommend adding the libs to NSDEJAVU_LIBS for the
reasons Steve explained (the pro becomes even more obvious when you
factor in symbol versioning that some libraries may have).

Personally, I'd also recommend to go with Steve's opinion on these
matters when you don't have one of your own, but that's mostly based on
the profound expertise in this area that he demonstrated in Debian over
and over again and not an argument in itself.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/

Message #66 received at 377468@bugs.debian.org (full text, mbox, reply):

From: "roucaries bastien" <roucaries.bastien+debian@gmail.com>

To: "Thomas Viehmann" <tv@beamnet.de>

Cc: debian-devel@lists.debian.org, pkg-mozilla-maintainers@lists.alioth.debian.org, 377468@bugs.debian.org, debian-qt-kde@lists.debian.org

Subject: Re: Help needed for #377468

Date: Sat, 20 Dec 2008 16:37:59 +0100

On Sat, Dec 20, 2008 at 4:22 PM, Thomas Viehmann <tv@beamnet.de> wrote:
> Bastien ROUCARIES wrote:
>> I would like to ask for some help for the bug #377468, if possible,
>> please. Particularly from a mozilla-plugin wizard.
>
> Just having made this choice w.r.t. to nsdejavu and pthread for properly
> fixing #504740, I'd recommend adding the libs to NSDEJAVU_LIBS for the
> reasons Steve explained (the pro becomes even more obvious when you
> factor in symbol versioning that some libraries may have).
>
> Personally, I'd also recommend to go with Steve's opinion on these
> matters when you don't have one of your own, but that's mostly based on
> the profound expertise in this area that he demonstrated in Debian over
> and over again and not an argument in itself.

Ok but I will do for my package.

It seems other plugins have the same problem. Should I open bug report?

$ldd -d -r /usr/lib/mozilla/plugins/* 2>&1 | grep undefined
undefined symbol:
__gxx_personality_v0	(/usr/lib/mozilla/plugins/librhythmbox-itms-detection-plugin.so)
undefined symbol:
gdk_window_invalidate_rect	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
cairo_set_operator	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gdk_cairo_create	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
NS_CStringSetData	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
cairo_destroy	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gtk_widget_get_type	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
NS_StringContainerFinish	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol: NS_Alloc	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
NS_CStringCopy	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
NS_CStringContainerInit	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
cairo_paint	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
cairo_restore	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
NS_GetMemoryManager	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
NS_StringContainerInit	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gdk_draw_rectangle	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
NS_GetComponentManager	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gtk_widget_get_screen	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
NS_CStringContainerFinish	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
NS_StringGetData	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
cairo_translate	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gdk_draw_drawable	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
NS_CStringGetData	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gtk_object_get_type	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gtk_button_get_type	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gdk_window_begin_paint_rect	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gtk_widget_send_expose	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gdk_cairo_rectangle	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gtk_button_get_image	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gdk_cairo_set_source_pixmap	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gdk_pixmap_new	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
NS_CStringGetMutableData	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gtk_settings_get_for_screen	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol: cairo_clip	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
NS_GetServiceManager	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
NS_UTF16ToCString	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
NS_CStringContainerInit2	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol: NS_Free	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol: cairo_save	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gdk_window_end_paint	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
cairo_paint_with_alpha	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gdk_window_process_updates	(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so)
undefined symbol:
gdk_window_invalidate_rect	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
cairo_set_operator	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
gdk_cairo_create	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
NS_CStringSetData	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
cairo_destroy	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
gtk_widget_get_type	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
NS_StringContainerFinish	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol: NS_Alloc	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
NS_CStringCopy	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
NS_CStringContainerInit	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
cairo_paint	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
cairo_restore	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
NS_GetMemoryManager	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
NS_StringContainerInit	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
gdk_draw_rectangle	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
NS_GetComponentManager	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
gtk_widget_get_screen	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
NS_CStringContainerFinish	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
NS_StringGetData	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
cairo_translate	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
gdk_draw_drawable	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
NS_CStringGetData	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
gtk_object_get_type	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
gtk_button_get_type	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
gdk_window_begin_paint_rect	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
gtk_widget_send_expose	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
gdk_cairo_rectangle	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
gtk_button_get_image	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
gdk_cairo_set_source_pixmap	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
gdk_pixmap_new	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
NS_CStringGetMutableData	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
gtk_settings_get_for_screen	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
NS_Realloc	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
cairo_clip	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
NS_GetServiceManager	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
NS_UTF16ToCString	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
NS_CStringContainerInit2	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol: NS_Free	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
cairo_save	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
gdk_window_end_paint	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
cairo_paint_with_alpha	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
gdk_window_process_updates	(/usr/lib/mozilla/plugins/libtotem-complex-plugin.so)
undefined symbol:
gdk_window_invalidate_rect	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
cairo_set_operator	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
gdk_cairo_create	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
NS_CStringSetData	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
cairo_destroy	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
gtk_widget_get_type	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
NS_StringContainerFinish	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol: NS_Alloc	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
NS_CStringCopy	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
NS_CStringContainerInit	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol: cairo_paint	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
cairo_restore	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
NS_GetMemoryManager	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
NS_StringContainerInit	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
gdk_draw_rectangle	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
NS_GetComponentManager	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
gtk_widget_get_screen	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
NS_CStringContainerFinish	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
NS_StringGetData	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
cairo_translate	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
gdk_draw_drawable	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
NS_CStringGetData	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
gtk_object_get_type	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
gtk_button_get_type	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
gdk_window_begin_paint_rect	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
gtk_widget_send_expose	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
gdk_cairo_rectangle	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
gtk_button_get_image	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
gdk_cairo_set_source_pixmap	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
gdk_pixmap_new	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
NS_CStringGetMutableData	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
gtk_settings_get_for_screen	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol: cairo_clip	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
NS_GetServiceManager	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
NS_UTF16ToCString	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
NS_CStringContainerInit2	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol: NS_Free	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol: cairo_save	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
gdk_window_end_paint	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
cairo_paint_with_alpha	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
gdk_window_process_updates	(/usr/lib/mozilla/plugins/libtotem-gmp-plugin.so)
undefined symbol:
gdk_window_invalidate_rect	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
cairo_set_operator	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
gdk_cairo_create	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
NS_CStringSetData	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
cairo_destroy	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
gtk_widget_get_type	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
NS_StringContainerFinish	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol: NS_Alloc	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
NS_CStringCopy	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
NS_CStringContainerInit	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
cairo_paint	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
cairo_restore	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
NS_GetMemoryManager	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
NS_StringContainerInit	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
gdk_draw_rectangle	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
NS_GetComponentManager	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
gtk_widget_get_screen	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
NS_CStringContainerFinish	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
NS_StringGetData	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
cairo_translate	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
gdk_draw_drawable	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
NS_CStringGetData	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
gtk_object_get_type	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
gtk_button_get_type	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
gdk_window_begin_paint_rect	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
gtk_widget_send_expose	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
gdk_cairo_rectangle	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
gtk_button_get_image	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
gdk_cairo_set_source_pixmap	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
gdk_pixmap_new	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
NS_CStringGetMutableData	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
gtk_settings_get_for_screen	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol: cairo_clip	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
NS_GetServiceManager	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
NS_UTF16ToCString	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
NS_CStringContainerInit2	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol: NS_Free	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol: cairo_save	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
gdk_window_end_paint	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
cairo_paint_with_alpha	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
gdk_window_process_updates	(/usr/lib/mozilla/plugins/libtotem-mully-plugin.so)
undefined symbol:
gdk_window_invalidate_rect	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
cairo_set_operator	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
gdk_cairo_create	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
NS_CStringSetData	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
cairo_destroy	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
gtk_widget_get_type	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
NS_StringContainerFinish	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
NS_Alloc	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
NS_CStringCopy	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
NS_CStringContainerInit	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
cairo_paint	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
cairo_restore	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
NS_GetMemoryManager	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
NS_StringContainerInit	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
gdk_draw_rectangle	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
NS_GetComponentManager	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
gtk_widget_get_screen	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
NS_CStringContainerFinish	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
NS_StringGetData	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
cairo_translate	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
gdk_draw_drawable	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
NS_CStringGetData	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
gtk_object_get_type	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
gtk_button_get_type	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
gdk_window_begin_paint_rect	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
gtk_widget_send_expose	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
gdk_cairo_rectangle	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
gtk_button_get_image	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
gdk_cairo_set_source_pixmap	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
gdk_pixmap_new	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
NS_CStringGetMutableData	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
gtk_settings_get_for_screen	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
cairo_clip	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
NS_GetServiceManager	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
NS_UTF16ToCString	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
NS_CStringContainerInit2	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
NS_Free	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
cairo_save	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
gdk_window_end_paint	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
cairo_paint_with_alpha	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol:
gdk_window_process_updates	(/usr/lib/mozilla/plugins/libtotem-narrowspace-plugin.so)
undefined symbol: XtShellStrings	(/usr/lib/mozilla/plugins/nsdejavu.so)
undefined symbol: XtStrings	(/usr/lib/mozilla/plugins/nsdejavu.so)
undefined symbol: XDrawString	(/usr/lib/mozilla/plugins/nsdejavu.so)
undefined symbol: XQueryColors	(/usr/lib/mozilla/plugins/nsdejavu.so)
undefined symbol: XtVaSetValues	(/usr/lib/mozilla/plugins/nsdejavu.so)
undefined symbol: XtRemoveCallback	(/usr/lib/mozilla/plugins/nsdejavu.so)
undefined symbol: XSetFont	(/usr/lib/mozilla/plugins/nsdejavu.so)
undefined symbol: XAllocNamedColor	(/usr/lib/mozilla/plugins/nsdejavu.so)
undefined symbol: XtWindowToWidget	(/usr/lib/mozilla/plugins/nsdejavu.so)
undefined symbol: XFreeColors	(/usr/lib/mozilla/plugins/nsdejavu.so)
undefined symbol: XCreateColormap	(/usr/lib/mozilla/plugins/nsdejavu.so)
undefined symbol: XtRemoveEventHandler	(/usr/lib/mozilla/plugins/nsdejavu.so)
undefined symbol: XtAddCallback	(/usr/lib/mozilla/plugins/nsdejavu.so)
undefined symbol: XSetForeground	(/usr/lib/mozilla/plugins/nsdejavu.so)
undefined symbol: XtRemoveInput	(/usr/lib/mozilla/plugins/nsdejavu.so)
undefined symbol: XAllocColorCells	(/usr/lib/mozilla/plugins/nsdejavu.so)
undefined symbol: XMapWindow	(/usr/lib/mozilla/plugins/nsdejavu.so)
undefined symbol: XCreateGC	(/usr/lib/mozilla/plugins/nsdejavu.so)
undefined symbol: XQueryColor	(/usr/lib/mozilla/plugins/nsdejavu.so)
undefined symbol: XTextWidth	(/usr/lib/mozilla/plugins/nsdejavu.so)
undefined symbol: XSync	(/usr/lib/mozilla/plugins/nsdejavu.so)
undefined symbol: XStoreColors	(/usr/lib/mozilla/plugins/nsdejavu.so)
undefined symbol: XSendEvent	(/usr/lib/mozilla/plugins/nsdejavu.so)
undefined symbol: XtAddEventHandler	(/usr/lib/mozilla/plugins/nsdejavu.so)
undefined symbol:
XtWidgetToApplicationContext	(/usr/lib/mozilla/plugins/nsdejavu.so)
undefined symbol: XLoadQueryFont	(/usr/lib/mozilla/plugins/nsdejavu.so)
undefined symbol: XInstallColormap	(/usr/lib/mozilla/plugins/nsdejavu.so)
undefined symbol: XtAppAddInput	(/usr/lib/mozilla/plugins/nsdejavu.so)
undefined symbol: XAllocColor	(/usr/lib/mozilla/plugins/nsdejavu.so)
undefined symbol: XDefaultVisualOfScreen	(/usr/lib/mozilla/plugins/nsdejavu.so)
undefined symbol: XVisualIDFromVisual	(/usr/lib/mozilla/plugins/nsdejavu.so)
undefined symbol: XStoreColor	(/usr/lib/mozilla/plugins/nsdejavu.so)
undefined symbol: XtVaGetValues	(/usr/lib/mozilla/plugins/nsdejavu.so)

Regards

Bastien

Message #71 received at 377468@bugs.debian.org (full text, mbox, reply):

From: Thomas Viehmann <tv@beamnet.de>

To: roucaries bastien <roucaries.bastien+debian@gmail.com>

Cc: debian-devel@lists.debian.org, 377468@bugs.debian.org

Subject: Re: Help needed for #377468

Date: Sat, 20 Dec 2008 16:47:29 +0100

[dropped even more CCs]

roucaries bastien wrote:
> It seems other plugins have the same problem. Should I open bug report?
Well, that depends a bit:
a) some of the symbols in your list (NS_*) might be from stuff that can
   reasonably be expected to always linked into things loading the
   plugins. (I don't know, but it should be checked before filing bugs,
   also see c) ),
b) otherwise it seems to be a bug,
c) for things that don't break within the set of packages Debian ships,
   I think fixing them for Lenny is not that important. For stuff that
   breaks, well, it might be worth fixing if it's easily fixable, but
   I'd ask for input of the release team before filing.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/

Message #76 received at 377468@bugs.debian.org (full text, mbox, reply):

From: Alexander Sack <asac@debian.org>

To: Bastien ROUCARIES <roucaries.bastien+debian@gmail.com>

Cc: debian-devel@lists.debian.org, modestas@vainius.eu, fabo@debian.org, pino@kde.org, debian@pusling.com, pkg-mozilla-maintainers@lists.alioth.debian.org, hjheins@gmail.com, jaldhar@debian.org, glandium@debian.org, asac@debian.org, 377468@bugs.debian.org, eric@debian.org, lool@dooz.org, debian-qt-kde@lists.debian.org, ana@debian.org

Subject: Re: Help needed for #377468

Date: Sat, 20 Dec 2008 18:45:41 +0100

On Sat, Dec 20, 2008 at 03:50:21PM +0100, Bastien ROUCARIES wrote:
> Hi!
> 
> I would like to ask for some help for the bug #377468, if possible,
> please. Particularly from a mozilla-plugin wizard.
> 
> The problem is that djvulibre in upstream is not linked against a particular libXt 
> in order to adapt against different libXt version depending of the browser used.
> The question raised by the upsteam is the case of the browser itself already uses libXt, and links to
> a different version of the library than the plugin. 
> 

I think it should link against libXt in any case.

AFAIK libXt properly tracks library version, so linking against it
should actually do the right thing. Of course your plugin might only
use a super stable subset of the symbols in libXt, but even then i
think not linking against the system lib causes troubles.

 - Alexander

Message #81 received at 377468@bugs.debian.org (full text, mbox, reply):

From: "Barak A. Pearlmutter" <barak@cs.nuim.ie>

To: 377468@bugs.debian.org

Cc: Alexander Sack <asac@debian.org>, Roucaries Bastien <roucaries.bastien+debian@gmail.com>

Subject: Against Medical Advice

Date: Sat, 20 Dec 2008 20:24:18 +0000

I'm a bit uncomfortable disregarding upstream's advice on this matter.
In the past they used an explicit dynamic link of this plugin against
libXt, which led to some actual bugs, and they then removed the
explicit dynamic link.

It seems unlikely that the plugin will fail on Debian-supplied
browsers due to lack of an explicit dynamic link.  After all, it will
almost certainly be compiled against the header files for the same
version of the library as the browser was, since we compiled them
both.

On the other hand, it is not implausible that people running Debian
systems will download new non-Debian-packaged browsers on their own
(chrome, opera, who knows what) and that some of these browsers may
try to use this plugin, and might even expose the libXt linkages in
some unusual way.  That is the kind of situation where the previous
explicit dynamic link caused trouble.

					--Barak.

Message #86 received at 377468@bugs.debian.org (full text, mbox, reply):

From: "roucaries bastien" <roucaries.bastien+debian@gmail.com>

To: barak@cs.nuim.ie

Cc: 377468@bugs.debian.org, "Alexander Sack" <asac@debian.org>

Subject: Re: Against Medical Advice

Date: Mon, 22 Dec 2008 02:19:53 +0100

> It seems unlikely that the plugin will fail on Debian-supplied
> browsers due to lack of an explicit dynamic link.  After all, it will
> almost certainly be compiled against the header files for the same
> version of the library as the browser was, since we compiled them
> both.
>
> On the other hand, it is not implausible that people running Debian
> systems will download new non-Debian-packaged browsers on their own
> (chrome, opera, who knows what) and that some of these browsers may
> try to use this plugin, and might even expose the libXt linkages in
> some unusual way.  That is the kind of situation where the previous
> explicit dynamic link caused trouble.

And it will crash before. gnash-plugin is linked against libXt. And
flah is really
more common than djvu. That why I ask help. Personnally I think we should link
against libXt.

Regards

Bastien

Message #91 received at 377468@bugs.debian.org (full text, mbox, reply):

From: Leon Bottou <leon@bottou.org>

To: 377468@bugs.debian.org

Date: Sat, 27 Dec 2008 04:46:55 -0500

Let me explain my reasonning as the upstream developper.


The plugin api implicitely mandates that one uses
some basic Xt calls to capture gui events from 
the browser event loop. With some browsers, one can also 
set a flag to use the xembed protocol: it is then 
recommended to capture events using glib calls.

In both cases, these are very basic calls
that are unlikely to be ever removed or changed
from either Xt or GLib. Too many programs depend on them.

However it is most important that these calls
affect the data structures of the browser event loop.
In other words, one should be *certain* to use
the same Xt or GLib version as the browser itself.
Using a different version of libX11
would not be nearly as bad...

In my experience, the danger of linking with a different version of Xt
is greater than the danger of seeing a change in a few Xt functions
that haven't changed in the last 20 years...

This reasonning makes sense for the upstream distribution.

In Debian, if you can be certain that all Debian browsers use the same Xt
version, you can link with that one. Then change is quite trivial
since 'configure.ac' contains code to explicitely remove -lXt and -lXext.  
I think this is slightly unwise, but without hard feelings.

I also would like to point out that the current djvulibre plugin code,
unmodified, produces binaries that have been shown to work with a large 
number of browsers including the original netscape, gecko based browsers, 
khtml based browsers and some versions of opera.  I believe I have
solid experience in that aspect of plugin programming...

Happy new year to all of you 
and thanks for the precious help...

- L.

Message #96 received at 377468@bugs.debian.org (full text, mbox, reply):

From: Michel Briand <michelbriand@free.fr>

To: 377468@bugs.debian.org

Cc: Leon Bottou <leon@bottou.org>

Subject: Plugin architecture & library conflicts

Date: Sun, 28 Dec 2008 04:23:13 +0100

Hi all,

I'd like to add a small comment to the last post from Leon.

I agree that libXt is not changing often. And that many browser would
have loaded it already. So the plugin should "bid" that it's
available... But that's dangerous, and I'll dig into Netscape /
Mozilla specs to assert that it's recommended or not ...

If the plugin is built on the debian machine that it targets
(certainly :)...) it should use the default libXt provided on this
distribution. So I see no problem for all debian built browsers.

If a different browser is used (i.e. not built by debian), then, one
solution could be to test them and mark them "supported" or "not
supported" by this debian-distributed plugin. This clearly out-pass the
debian work, and should be considered a "smart gift" from the
maintainer ;).

But I'd suggest another approach.

The plugin could be a split between a very simple wrapper and a
distinct application. The plugin would swallow the X window of
the "real" plugin : the separate application. That's the design of
FreeWRL's plugin and it works. Even with this design we can receive X
events from the browser (passthrough).

The separate application could have any dependency you can imagine.

I'd recommend to adopt this easier approach. But it has the drawback
to require a new plugin design / implementation from upstream. It also
out-pass the Debian context ;).

Hoping that this make sense.
Best regards,

Michel

Message #101 received at 377468@bugs.debian.org (full text, mbox, reply):

From: Leon Bottou <leon@bottou.org>

To: Michel Briand <michelbriand@free.fr>

Cc: 377468@bugs.debian.org

Subject: Re: Plugin architecture & library conflicts

Date: Sun, 28 Dec 2008 06:31:22 -0500

On Saturday 27 December 2008 22:23:13 Michel Briand wrote:
> The plugin could be a split between a very simple wrapper and a
> distinct application. The plugin would swallow the X window of
> the "real" plugin : the separate application. That's the design of
> FreeWRL's plugin and it works. Even with this design we can receive X
> events from the browser (passthrough).

The djview plugin already works this way.
However it is still necessary to capture a few events to
properly handle the swallowing (window resizing, 
keyboard events propagation, window destruction).
Things may be less fragile with the Xembed plugin option,
but that does not work with all browsers...

- L.

Message #106 received at 377468@bugs.debian.org (full text, mbox, reply):

From: nr@cs.tufts.edu (Norman Ramsey)

To: 377468@bugs.debian.org

Subject: Bug lives on in Google Chrome

Date: Thu, 21 Jan 2010 22:38:23 +0100 (CET)

Just a note that this bug in the nsdejavu plugin manifests in
Google Chrome 4.0.288.1 (a non-Debian browser) on Debian i386.
/etc/debian_version is 5.0.3.


Norman

Message #111 received at 377468@bugs.debian.org (full text, mbox, reply):

From: "Barak A. Pearlmutter" <barak@cs.nuim.ie>

To: Norman Ramsey <nr@eecs.harvard.edu>

Cc: 377468@bugs.debian.org

Subject: Re: Bug#377468: Bug lives on in Google Chrome

Date: Fri, 22 Jan 2010 12:56:07 +0000

Thanks.

Hate to do this to you, but could I ask for sufficient details to
allow me to replicate the problem?  I'm using Google Chrome 4.0.249.43
(Official Build 34537) on amd64 and it doesn't do anything special
with .djvu files, just downloads them.

					--Barak.

Message #116 received at 377468@bugs.debian.org (full text, mbox, reply):

From: A Mennucc <debdev@tonelli.sns.it>

To: 377468@bugs.debian.org

Subject: google chrome, me too

Date: Mon, 15 Mar 2010 15:21:02 +0100

hi,

I am using google-chrome 5.0.307.11 beta, in Debian/lenny, amd64, and 
djvulibre-plugin                           3.5.20-8+lenny1 
and I see the message


[28590:28599:279967731380:ERROR:/usr/local/google/b/slave/chrome-official-linux-64/build/src/base/native_library_linux.cc(24)] 
dlopen failed when trying to open 
/usr/lib/netscape/plugins-libc6/nsdejavu.so: 
/usr/lib/netscape/plugins-libc6/nsdejavu.so: undefined symbol: 
XtShellStrings

a.

-- 
Andrea Mennucc

"The EULA sounds like it was written by a team of lawyers who want to tell 
me what I can't do, and the GPL sounds like it was written by a human 
being who wants me to know what I can do."
Anonymous,    http://www.securityfocus.com/columnists/420

Message #121 received at 377468@bugs.debian.org (full text, mbox, reply):

From: "Barak A. Pearlmutter" <barak@cs.nuim.ie>

To: Leon Bottou <leonb@bottou.org>

Cc: mennucc1@debian.org, 377468@bugs.debian.org

Subject: Re: Bug#377468: google chrome, me too

Date: Mon, 15 Mar 2010 14:44:54 +0000

Leon, this report showed up, see http://bugs.debian.org/377468

> I am using google-chrome 5.0.307.11 beta, in Debian/lenny, amd64, and 
> djvulibre-plugin                           3.5.20-8+lenny1 
> and I see the message
>
> [28590:28599:279967731380:ERROR:/usr/local/google/b/slave/chrome-official-linux-64/build/src/base/native_library_linux.cc(24)] 
> dlopen failed when trying to open 
> /usr/lib/netscape/plugins-libc6/nsdejavu.so: 
> /usr/lib/netscape/plugins-libc6/nsdejavu.so: undefined symbol: 
> XtShellStrings

Is that a Chrome bug for not implementing the required subset of Xt
that browsers are supposed to provide their plugins?  Or is it a
problem with the plugin itself, or its linkage?  Could it be worked
around by not using XtShellStrings?

					--Barak.

Message #126 received at 377468@bugs.debian.org (full text, mbox, reply):

From: "Barak A. Pearlmutter" <barak@cs.nuim.ie>

To: mennucc1@debian.org

Cc: 377468@bugs.debian.org

Subject: Re: Bug#377468: google chrome, me too

Date: Mon, 15 Mar 2010 14:58:55 +0000

According to the Chrome issue tracker, this looks like a Chrome issue.

http://code.google.com/p/chromium/issues/detail?id=25207

> Issue 25207:	/usr/lib/netscape/plugins-libc6/nsdejavu.so: undefined symbol: XtShellStrings
>
> We currently don't support Xt-based plugins, so I wonder if loading
> libXt would actually make these works.

I'd be curious to see what happens with

 env LD_PRELOAD=/usr/lib/libXt.so google-chrome

Cheers,

					--Barak.
--
Barak A. Pearlmutter <barak@cs.nuim.ie>
 http://www.bcl.hamilton.ie/~barak/

Message #131 received at 377468@bugs.debian.org (full text, mbox, reply):

From: "Barak A. Pearlmutter" <barak@cs.nuim.ie>

To: mennucc1@debian.org

Cc: 377468@bugs.debian.org

Subject: Re: Bug#377468: google chrome, me too

Date: Mon, 15 Mar 2010 17:41:26 +0000

I've just uploaded a new version, 3.5.22-9, which may address this
issue.  Please let me know if the plugin now works with Chrome.

					Cheers,

					--Barak.

Send a report that this bug log contains spam.