Unsatisfied Link Error - works on one machine but not the other - HELP!!!

[Mark]

Hello,

I have a JNI dll that I created and have working via our application
on my desktop. However, when I copy that same dll to the laptop, I
get a UnsatisfiedLinkError on the dll in question.

Both machines are windows 2000. Both machines have the system32 path
in their environment path settings. (the dll is in the winnt\system32
dir)

If I rename the dll on the machine that works, I get the same
exception I see all of the time on the laptop. When I put the name
back, the desktop works again. Which leads me to believe that the
laptop is simply not loading the DLL while the desktop is.

Are there any other settings, dlls or lib files I need on the laptop
for JNI calls?

Thanks in advance,
Mark

 

[Steve W. Jackson]

:Hello,
:
:I have a JNI dll that I created and have working via our application
n my desktop. However, when I copy that same dll to the laptop, I
:get a UnsatisfiedLinkError on the dll in question.
:
:Both machines are windows 2000. Both machines have the system32 path
:in their environment path settings. (the dll is in the winnt\system32
:dir)
:
:If I rename the dll on the machine that works, I get the same
:exception I see all of the time on the laptop. When I put the name
:back, the desktop works again. Which leads me to believe that the
:laptop is simply not loading the DLL while the desktop is.
:
:Are there any other settings, dlls or lib files I need on the laptop
:for JNI calls?
:
:Thanks in advance,
:Mark

Unless your DLL is dependent on other files which the second system
doesn't have, it should work (which is why I've linked mine statically
to everything it needed). Otherwise, placing a new DLL into a location
from which Windows would find it when requested is all that's required.

= Steve =

 

[Tony Morris]

Yes, that is all I can think of as well.

Just for clarification:
"a location from which Windows would find it " == "in the PATH environment
variable"

--
Tony Morris
(BInfTech, Cert 3 I.T., SCJP[1.4], SCJD)
Software Engineer
IBM Australia - Tivoli Security Software
(2003 VTR1000F)

 

[Jim Sculley]

Hello,

I have a JNI dll that I created and have working via our application
on my desktop. However, when I copy that same dll to the laptop, I
get a UnsatisfiedLinkError on the dll in question.

Both machines are windows 2000. Both machines have the system32 path
in their environment path settings. (the dll is in the winnt\system32
dir)

If I rename the dll on the machine that works, I get the same
exception I see all of the time on the laptop. When I put the name
back, the desktop works again. Which leads me to believe that the
laptop is simply not loading the DLL while the desktop is.

It would be very helpful if you could post the exact error message.
UnsatisfiedLinkErrors have two typical sources and the solution is very
different in each case.

As a first check, make a small bit of test code that executes the following:

System.out.println("java.library.path");

The DLL file must be in one of the directories listed.

Another test is to specify the library path explicitly on the command
line. Move the DLL to the same directory as your class files and
execute the code like this:

java -Djava.library.path=. MyClass

Jim S.

 

[Ryan Stewart]

As a first check, make a small bit of test code that executes the following:

System.out.println("java.library.path");

I'm no expert here, but I don't think that's what you meant. Maybe:
System.out.println(System.getProperty("java.library.path"));

 

[Tony Morris]

Yes, I think (almost positive) you're right.
I'd assume a typo.

--
Tony Morris
(BInfTech, Cert 3 I.T., SCJP[1.4], SCJD)
Software Engineer
IBM Australia - Tivoli Security Software
(2003 VTR1000F)

 

[Steve W. Jackson]

:Mark wrote:
:> Hello,
:>
:> I have a JNI dll that I created and have working via our application
:> on my desktop. However, when I copy that same dll to the laptop, I
:> get a UnsatisfiedLinkError on the dll in question.
:>
:> Both machines are windows 2000. Both machines have the system32 path
:> in their environment path settings. (the dll is in the winnt\system32
:> dir)
:>
:> If I rename the dll on the machine that works, I get the same
:> exception I see all of the time on the laptop. When I put the name
:> back, the desktop works again. Which leads me to believe that the
:> laptop is simply not loading the DLL while the desktop is.
:
:It would be very helpful if you could post the exact error message.
:UnsatisfiedLinkErrors have two typical sources and the solution is very
:different in each case.
:
:As a first check, make a small bit of test code that executes the following:
:
:System.out.println("java.library.path");
:
:The DLL file must be in one of the directories listed.
:
:Another test is to specify the library path explicitly on the command
:line. Move the DLL to the same directory as your class files and
:execute the code like this:
:
:java -Djava.library.path=. MyClass
:
:Jim S.

That last may not be needed, or may not be a good idea. First, Windows
already includes the current directory (the value of the "user.dir"
property) in its search path for DLLs, even though it's not necessarily
in the PATH variable. Secondly, wouldn't doing that last replace the
entire library path? If so, then other DLLs might become inaccessible
to the Java app.

= Steve =

 

[Jim Sculley]

Yes, I think (almost positive) you're right.
I'd assume a typo.

Indeed.

Jim S.

 

[Jim Sculley]

That last may not be needed, or may not be a good idea. First, Windows
already includes the current directory (the value of the "user.dir"
property) in its search path for DLLs, even though it's not necessarily
in the PATH variable. Secondly, wouldn't doing that last replace the
entire library path? If so, then other DLLs might become inaccessible
to the Java app.

Note, this was a test to identify the failure mode of the JNI library.
I did not recommend it as a solution to the problem.

When fixing this sort of problem, one should make no assumptions about
the DLL search path with respect to JNI libraries. In particular, if an
older version of the DLL file exists in a spot earlier on the library
path, it may get loaded and can cause UnsatisfiedLinkErrors.

Jim S.

 

[Steve W. Jackson]

:Steve W. Jackson wrote:
:> In article <[email protected]>,
:>
:>
:>>:Mark wrote:
:>>:> Hello,
:>>:>
:>>:> I have a JNI dll that I created and have working via our application
:>>:> on my desktop. However, when I copy that same dll to the laptop, I
:>>:> get a UnsatisfiedLinkError on the dll in question.
:>>:>
:>>:> Both machines are windows 2000. Both machines have the system32 path
:>>:> in their environment path settings. (the dll is in the winnt\system32
:>>:> dir)
:>>:>
:>>:> If I rename the dll on the machine that works, I get the same
:>>:> exception I see all of the time on the laptop. When I put the name
:>>:> back, the desktop works again. Which leads me to believe that the
:>>:> laptop is simply not loading the DLL while the desktop is.
:>>:
:>>:It would be very helpful if you could post the exact error message.
:>>:UnsatisfiedLinkErrors have two typical sources and the solution is very
:>>:different in each case.
:>>:
:>>:As a first check, make a small bit of test code that executes the
:>>:following:
:>>:
:>>:System.out.println("java.library.path");
:>>:
:>>:The DLL file must be in one of the directories listed.
:>>:
:>>:Another test is to specify the library path explicitly on the command
:>>:line. Move the DLL to the same directory as your class files and
:>>:execute the code like this:
:>>:
:>>:java -Djava.library.path=. MyClass
:>>:
:>>:Jim S.
:>
:>
:> That last may not be needed, or may not be a good idea. First, Windows
:> already includes the current directory (the value of the "user.dir"
:> property) in its search path for DLLs, even though it's not necessarily
:> in the PATH variable. Secondly, wouldn't doing that last replace the
:> entire library path? If so, then other DLLs might become inaccessible
:> to the Java app.
:
:Note, this was a test to identify the failure mode of the JNI library.
:I did not recommend it as a solution to the problem.
:
:When fixing this sort of problem, one should make no assumptions about
:the DLL search path with respect to JNI libraries. In particular, if an
lder version of the DLL file exists in a spot earlier on the library
ath, it may get loaded and can cause UnsatisfiedLinkErrors.
:
:Jim S.
:

Excellent advice. I have personally been bitten by problems similar to
the one where an earlier path resolution "interfered."

= Steve =