> 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/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
