What's the trick? Cannot load without eclipse some shared objects for browser widget [message #451106] |
Wed, 23 February 2005 05:15  |
Eclipse User |
|
|
|
Hi,
I can use successfully the browser widget in my standalone application -
but only if I start it from Eclipse and not from command line. In both
cases I add the VM argument
"-Djava.library.path=[path-to-swt]:[path-to-mozilla]". I also set the
enviroment variable "MOZILLA_FIVE_HOME". BTH, is it neccessary to set
it? Without setting it, I get a SWTException with the message "no more
handles (MOZILLA_FIVE_HOME is not set)". With setting this variable I
get an UnsatisfiedLinkError ("cannot open shared object file
libxpcom.so"). This so comes from mozilla and should be reachable by
setting "-Djava.library.path" described above. I also set java.policy to
grant all. The behaviour hadn't changed.
Currently, I copy all used shared objects to jre/lib/i386 and then it
works. But this is long-term not acceptable tbh.
Therefore my question: What is the magic formula to make it runnable
without coping any shared objects?
Thanks!
|
|
|
Re: What's the trick? Cannot load without eclipse some shared objects for browser widget [message #451192 is a reply to message #451106] |
Thu, 24 February 2005 09:16   |
Eclipse User |
|
|
|
Check my comments below.
If you are lazy, just read this:
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/plat form-swt-home/faq.html#browserlinuxrcp
and specifically the sentence about the LD_LIBRARY_PATH.
> In both
> cases I add the VM argument
> "-Djava.library.path=[path-to-swt]:[path-to-mozilla]". I also set the
> enviroment variable "MOZILLA_FIVE_HOME".
[path-to-mozilla] is not needed in -Djava.library.path
> BTH, is it neccessary to set
> it? Without setting it, I get a SWTException with the message "no more
> handles (MOZILLA_FIVE_HOME is not set)".
Yes, you need to do this. I can explain why, but it will be a pretty long
explanation.
> With setting this variable I
> get an UnsatisfiedLinkError ("cannot open shared object file
> libxpcom.so"). This so comes from mozilla and should be reachable by
> setting "-Djava.library.path" described above.
No. libxpcom.so, as far as I remember is linked dynamically "C-style" to
swt-mozilla-whatever.so. (Just do 'ldd swt-mozilla-whatever.so' and you'll
see.)
libxpcom.so is NOT loaded by Java code using System.loadLibrary(), so having
the [path-to-mozilla] in -Djava.library.path has no point whatsoever.
> Currently, I copy all used shared objects to jre/lib/i386 and then it
> works. But this is long-term not acceptable tbh.
> Therefore my question: What is the magic formula to make it runnable
> without coping any shared objects?
I think you need to have the libxpcom.so in a location like '/usr/lib' or
otherwise the Linux ld loader cannot serve load-requests for this library to
other .so/executables. One way would be to NOT move this .so (which also
depends on the Netscape Portable Ruintime, I think) but instead to put the
mozilla home path in the LD_LIBRARY_PATH variable that the ld linker uses,
thus informing the ld linker, that it needs to also consider the mozilla
directory when loading dynamic libraries.
-Ivan
|
|
|
Re: What's the trick? Cannot load without eclipse some shared objects for browser widget [message #451285 is a reply to message #451192] |
Thu, 24 February 2005 10:50  |
Eclipse User |
|
|
|
Ivan pointed you to the right SWT FAQ. On Linux (and Linux only),
LD_LIBRARY_PATH and MOZILLA_FIVE_HOME must both be pointing to the location
of a supported mozilla build you want to embed to get the SWT Browser to
work.
When MOZILLA_FIVE_HOME is not set, the eclipse launcher provides default
values for these 2 environmental variables in some cases - when Linux
distributions install a Mozilla configuration file /etc/gre.conf that
contains the location of the Mozilla. E.g. RedHat 9, RH EL3, Fedora Core,
Suse support that configuration file. This explains why the Browser worked
for you when running from within Eclipse but not standalone.
Chris
|
|
|
Powered by
FUDForum. Page generated in 0.02939 seconds