|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 14:16
| Ivan Markov
Registered: July 2009
Check my comments below.|
If you are lazy, just read this:
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
> 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
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.
Powered by FUDForum
. Page generated in 0.01548 seconds