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. [EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
