Home » Eclipse Projects » Rich Client Platform (RCP) » Locating dependent DLLs
| Locating dependent DLLs [message #449625] |
Wed, 17 May 2006 00:23  |
Eclipse User |
|
|
|
Originally posted by: Stephen.Egan.csiro.au
Hi,
Some of my plugins require a number of DLLs to execute their native code=
.. =
I haven't had much of a problem locating the initial DLL (specified in t=
he =
System.loadLibrary() call) so long as it is in the top level directory o=
f =
the plugin, but the plugin is unable to load other dependent DLLs that a=
re =
not explicitly loaded from Java code. I have tried setting my =
Bundle-Nativecode to point to the DLLs, but again only the DLL explicitl=
y =
specified from Java code can be located. As a stop-gap, I've copied the=
=
other DLLs into the executable directory (i.e the eclipse directory when=
=
running from a workbench, or the product directory when exported). This=
=
works fine, but is a little messy and I would rather have everything in =
=
the plugin where it belongs. Any ideas? Below is how I set my =
Bundle-Nativecode
Bundle-NativeCode: TKernel.dll; TKBO.dll; TKBool.dll; TKBrep.dll; =
TKFillet.dll; TKG2d.dll; TKG3d.dll; TKGeomAlgo.dll; TKGeomBase.dll; =
TKjcas.dll; TKMath.dll; TKPrim.dll; TKTopAlgo.dll; osname=3DWindowsNT; =
osname=3DWindowsXP; processor=3Dx86
Regards,
Stephen
|
|
|
| Re: Locating dependent DLLs [message #449632 is a reply to message #449625] |
Wed, 17 May 2006 07:06  |
| Eclipse User |
|
|
|
You might want to have a read of http://www.eclipsezone.com/articles/eclipse-vms/
which discusses classloaders and DLLs in annoying detail :-)
The upshot is that the DLLs have to be loaded by a single plugin, since (on Windows, at least) the DLL is tightly bound to that classloader. If another classloader tries to load that DLL, it fails to do so.
Secondly, the DLLs that are mentioned in the java.library.path (or the plugin) are only consulted when you do a System.loadLibrary() call (either automatically or implicitly). However, if those require the loading of further DLLs (E.g. a.dll depends on b.dll and you do System.loadLibrary("a")) then problems can occur. Basically, Windows decides that 'a' needs 'b' to be loaded, but by now, the resolution is in the hands of the Windows path/DLL loading system, so it only consults the PATH (or LD_PATH on Unix, I expect) and therefore can't find the b.dll.
Your stop gap solution (putting them on the path) works because the main DLL that you need is handed onto Windows, which can then find the dependents from the PATH.
The only Java solution is to figure out a dependency graph, and load them in leaf order (e.g. System.loadLibrary("b");System.loadLibrary("a")). I expect that the Bundle-NativeCode approach needs to follow this as well, so that (for example) Bundle-NativeCode: a.dll;b.dll will fail, whilst Bundle-NativeCode: b.dll;a.dll will work. This is speculation on the fact that there is a sequence of System.loadLibrary() calls that need to be done, and that the implementation of Bundle-NativeCode probably goes through in order of the manifest.mf.
Of course, if anyone's willing to help fund me towards a new Mac Mini, I might be tempted to write a parser for Windows DLLs that figures out the dependency graph and performs the appropriate System.loadLibrary calls automatically :-)
Alex.
|
|
|
| Re: Locating dependent DLLs [message #449696 is a reply to message #449632] |
Wed, 17 May 2006 20:51 |
| Eclipse User |
|
|
|
Originally posted by: Stephen.Egan.csiro.au
Thanks Alex. That's definitely cleared that one up for me. Good luck =
getting that Mac Mini.
//Stephen
On Wed, 17 May 2006 21:06:07 +1000, Alex Blewitt <alex_blewitt@yahoo.com=
> =
wrote:
> You might want to have a read of =
> http://www.eclipsezone.com/articles/eclipse-vms/
> which discusses classloaders and DLLs in annoying detail :-)
>
> The upshot is that the DLLs have to be loaded by a single plugin, sinc=
e =
> (on Windows, at least) the DLL is tightly bound to that classloader. I=
f =
> another classloader tries to load that DLL, it fails to do so.
>
> Secondly, the DLLs that are mentioned in the java.library.path (or the=
=
> plugin) are only consulted when you do a System.loadLibrary() call =
> (either automatically or implicitly). However, if those require the =
> loading of further DLLs (E.g. a.dll depends on b.dll and you do =
> System.loadLibrary("a")) then problems can occur. Basically, Windows =
> decides that 'a' needs 'b' to be loaded, but by now, the resolution is=
=
> in the hands of the Windows path/DLL loading system, so it only consul=
ts =
> the PATH (or LD_PATH on Unix, I expect) and therefore can't find the =
> b.dll.
>
> Your stop gap solution (putting them on the path) works because the ma=
in =
> DLL that you need is handed onto Windows, which can then find the =
> dependents from the PATH.
>
> The only Java solution is to figure out a dependency graph, and load =
> them in leaf order (e.g. =
> System.loadLibrary("b");System.loadLibrary("a")). I expect that the =
> Bundle-NativeCode approach needs to follow this as well, so that (for =
=
> example) Bundle-NativeCode: a.dll;b.dll will fail, whilst =
> Bundle-NativeCode: b.dll;a.dll will work. This is speculation on the =
> fact that there is a sequence of System.loadLibrary() calls that need =
to =
> be done, and that the implementation of Bundle-NativeCode probably goe=
s =
> through in order of the manifest.mf.
>
> Of course, if anyone's willing to help fund me towards a new Mac Mini,=
I =
> might be tempted to write a parser for Windows DLLs that figures out t=
he =
> dependency graph and performs the appropriate System.loadLibrary calls=
=
> automatically :-)
>
> Alex.
-- =
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
|
Goto Forum:
Current Time: Sun Aug 31 17:52:51 EDT 2025
Powered by FUDForum. Page generated in 0.03477 seconds |
Home