Dominique Devienne wrote:
On 1/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
If a .dll depends on another .dll, then it must be found in
the system-specific, on Windows the Path (on *nix,
LD_LIBRARY_PATH usually).
So to be platform "independend" you use both?
<java>
<env value="${thePath}" key="PATH"/>
<env value="${thePath}" key="LD_LIBRARY_PATH"/>
</java>
Jokes appart, to really be as platform "independent" as one can be
when not doing 100% pure Java, using java.library.path only is the way
to go. This implies using JNI native libraries which are mostly
"self-containted", i.e. don't depend on other native libs (.dll, .so,
etc... Steve ;-) except for system libraries found by default.
But even Path/LD_LIBRARY_PATH can be hacked around I think, as I've
seen one clever developer do, by "pre-emptive" loading of the libs
depended upon using System.loadLibrary... You need JNI lib Top, which
depends on Middle, which depends on Bottom, and by
System.loadLibrary("Bottom") first explictly, then "Middle", and then
finally "Top", it seems to work and "Top" has all its dependencies
already satified. Weird, I know, but this developer was using this
hack to work around WebStart limitations regarding Java apps that
required native JNI libs. Not recommended for the faint of heart ;-)
Some developers are too clever for their own good ;-))) I'd never have
thought of this scheme. --DD
We were doing some low-level stuff that demonstrated that
System.loadLibrary on win32 uses ::LoadLibrary() and not ::LoadLibraryEx
to load things. you can see the difference in chained loads. If your DLL
(implicitly) loads another DLL, and you load the first lib using JNI
calls, the second lib only gets loaded if it is in the PATH, even if the
second one is in the same dir as the first one. You need to rework your
native code to do its own DLL loading to deal with it.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
