[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcjwebplugin-devel] LD_PRELOADing libraries
From: |
Thomas Fitzsimmons |
Subject: |
Re: [Gcjwebplugin-devel] LD_PRELOADing libraries |
Date: |
06 Aug 2003 14:30:53 -0400 |
On Tue, 2003-07-29 at 10:23, Thomas Fitzsimmons wrote:
> On Tue, 2003-07-29 at 09:11, Michael Koch wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Am Dienstag, 29. Juli 2003 07:07 schrieb Anthony Green:
> >
> > > After getting the plugin to work the other, I still at a loss as
> > > to why we are required to LD_PRELOAD the gtk peer library (and
> > > libgcj). Is there any chance that Mozilla is changing the way
> > > libltdl searches for shared libraries? Any other theories out
> > > there? (Anybody on this list yet? :-)
> >
> > Sure, I'm on this list.
> >
> > I have to say this problem makes me headaches since some time. Locally
> > I worked around this by explicitely linking the gtk peer library to
> > the plugin. Then you dont need LD_PRELOAD but its a hack anyway.
> >
> > Mozilla seems to change the search paths in two "places" (at least on
> > Debian here it is this way): first in the script "mozilla" and then
> > in "mozilla-bin" again. Someone with the Mozilla sources should
> > really dig into this.
> >
> > BTW: you should use version 0.0.2 of the plugin, it contains a vital
> > fix.
> >
>
> Yes it is a pain that I'd like to eliminate. I haven't looked into it
> deeply yet. I do know that mozilla, when run without the LD_PRELOAD,
> needs LD_LIBRARY_PATH to be pointing to libgcj's installation directory
> in order to properly load the plugin. So everything is as expected up
> to the point where the plugin tries to load
> lib-gnu-java-awt-peer-gtk.so.
>
> This may have something to do with the fact that this is a plugin
> loading another .so. Mozilla may not be feeding the LD_LIBRARY_PATH
> information down to the plugin. I'll look into it.
Hi again,
With the help of other gcj hackers, I found the problem.
To understand the problem, it helps to know the relevant shared
libraries and their dependencies:
Mozilla dlopens libgcjwebplugin.so
libgcjwebplugin.so is linked against libgcj.so
libgcj.so dlopens lib-gnu-java-awt-peer-gtk.so
sometime after libgcjwebplugin.so is loaded.
lib-gnu-java-awt-peer-gtk.so depends on symbols in libgcj.so
The problem is that Mozilla dlopens libgcjwebplugin.so without
specifying the RTLD_GLOBAL flag. Because libgcjwebplugin.so depends on
libgcj.so, libgcj.so is also loaded at this time. Since Mozilla doesn't
specify RTLD_GLOBAL, libgcj.so's symbols are not exported to the global
symbol namespace.
When the first AWT component is shown, libgcj.so attempts to dlopen
lib-gnu-java-awt-peer-gtk.so so that the component's GTK peer may be
instantiated. However, this dlopen fails with an unresolved symbol
error for a libgcj.so symbol (_Jv_intClass); libgcj.so is already loaded
(as a result of Mozilla dlopening libgcjwebplugin.so), but its symbols
are not globally visible, and so are not available to
lib-gnu-java-awt-peer-gtk.so.
The attached patch fixes the problem, but I'm not sure how suitable it
is for inclusion in Mozilla.
Tom
mozrtldglobal.diff
Description: Text Data
- Re: [Gcjwebplugin-devel] LD_PRELOADing libraries,
Thomas Fitzsimmons <=