gcjwebplugin-devel
[Top][All Lists]
Advanced

[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: 29 Jul 2003 10:23:56 -0400

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.

Tom






reply via email to

[Prev in Thread] Current Thread [Next in Thread]