Re: [Gcjwebplugin-devel] LD_PRELOADing libraries

[Thomas Fitzsimmons]

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