Windows: Path problem when running sikuli-script.jar from command line in a non-standard Sikuli setup

Asked by amy cheng

I am able to run sikuli with command line on my developement box with below setting:

set PATH=%PATH%;"c:/sikulix\libs";"c:/jre6\bin"

then run "c:/jre6\bin\java.exe" -jar "c:/sikulix\sikuli-script.jar" myScript.sikuli and it succeeds.

However I do same thing on our build machine, it always give me error "can't find defendency library VisionProxy.dll".

if I run "c:/jre6\bin\java.exe" -jar "c:/sikulix\sikuli-script.jar" myScript.sikuli from c:\SikuliX\libs folder, it succeeds.

So seems like that it doesn't search library inside of PATH.

Very appreciated in advance!

Question information

Language:
English Edit question
Status:
Solved
For:
SikuliX Edit question
Assignee:
No assignee Edit question
Solved by:
amy cheng
Solved:
Last query:
Last reply:
Revision history for this message
RaiMan (raimund-hocke) said :
#1

This is from evaluations on Windows 7 32-Bit.

If you do not install Sikuli in its (currently) standard place ( c:\Program Files\Sikuli X ), then things get a bit tricky:

- Sikuli first looks for the primary DLL's (VisionProxy, Win32 and VdictProxy) in c:\Program Files\Sikuli X\libs (which is hard coded :-(
- If there, these DLL's are loaded from there
- if not there (which is the case if you never installed Sikuli in its standard way), then it copies these 3 DLL's from inside sikuli-script.jar to the users temp directory into the folder tmplib (Java standard environment property), usually
c:\Users\user-name\AppData\Local\Temp\tmpdir
from where the Java native loader loads these primary DLL's (since native code cannot be loaded from the jar directly)
- all the secondary DLL's are then found on the PATH at runtime, no matter how this was setup before and where the original contents of the Sikuli\libs folder might be.

Conclusion: Sikuli does not look for the 3 primary DLL's on the PATH , but hardcoded at c:\Program Files\Sikuli X\libs and if it is not there, it copies the DLL's to a temp folder to load it from there, no matter what the PATH might tell.

So usually in these cases (there is no c:\Program Files\Sikuli X\libs), the problem might be, that for some reason the creation of the above mentioned tmplib folder is not possible (e.g. access right problems).

Revision history for this message
RaiMan (raimund-hocke) said :
#2

CORRECTION:

Conclusion: Sikuli does not look for the 3 primary DLL's on the PATH , but hardcoded at c:\Program Files\Sikuli X\libs and if it is not there, it copies the DLL's from inside sikuli-script.jar to a temp folder to load it from there, no matter what the PATH might tell.

Revision history for this message
amy cheng (cheng-yue) said :
#3

Thanks Reiman for your quick answer.

I found 3 primary libraries are already in folder c:\user\AppData\Local\Temp folder after I manually copy sikuli X folder to c:\program files\. however I still get same error like before.

When I use dependency walker to open VisionProxy.dll, it shows me that following dll are not found:

MSVCR90.dll, CV210.dll, Cxcore.dll, GPSVC.dll, HighGUI.dll.

On my development box which is working, I do install Java and Sikuli in standard way and then I copy Java and Sikuli to folder c:\JRE6 and c:\SikuliX and no problem.

On Build machine we don't install sikuli and java in standard way and just copy folders. so do we have to install it in standard way first?

Revision history for this message
RaiMan (raimund-hocke) said :
#4

Since you have a standard setup in your DevMachine, this does not make any problems, as long as the Sikuli/libs folder is in the Path at runtime (where ever it might be, or how it is named).

dependency walker:
MSVCR90.dll, CV210.dll are in the libs folder as msvcr90.dll, cv210.dll
Cxcore.dll, HighGUI.dll should be called cxcore210.dll, highgui210.dll and are in the libs folder

As far as i know: The Windows filenaming is still case insensitive, so these differences should not matter.

But that a gpsvc.dll is reported is strange, since this is not in the libs folder.

So is this stuff on the build machine really from an original Sikuli package?

This should work on the build machine with original stuff from Sikuli X (preferably latest version r930):
- having a JRE 6 installed and running
- in a folder e.g. c:\SikuliX
-- sikuli-script.jar
-- a copy of the original libs folder
- in Path at runtime: c:\SikuliX\libs;path-to-java\jre6\bin
- access rights to let Java/Sikuli create a folder tmplib in the users temp folder

the on using on commandline this should work (java.exe should be found on path!):
java -jar c:\SikuliX\sikuli-script.jar path-to-your-script.sikuli

Revision history for this message
amy cheng (cheng-yue) said :
#5

Hi, ReiMan,

I installed Java 6 and Sikuli X in standard way on build machine and right now when I run
java -jar c:\SikuliX\sikuli-script.jar path-to-your-script.sikuli, it works!

After these standard installation, two windows environment variable are created
Path = C:\Program Files (x86)\Sikuli X\libs;C:\Program Files (x86)\Java\jre6\\bin
SIKULI_HOME = C:\Program Files (x86)\Sikuli X\.

After I removed these environment variable manually, it stops working again.

Then I create a batch file with following content:
set SIKULI_HOME="C:\Program Files (x86)\Sikuli X\"
set PATH=c:/sikulix\libs";"c:/jre6\bin";%PATH%;"
"c:/jre6\bin\java.exe" -jar "c:/sikulix\sikuli-script.jar" "my.sikuli"

but still failed.

Since we have 6 build machines and each build will pick idle one from them to make build . this is the reason we want to just pull java and sikuli folder to these computers instead of having standard installation for Java and Sikuli on them.

Is there any solution for these purpose? thanks a lot!

Revision history for this message
RaiMan (raimund-hocke) said :
#6

What about my comment #4?

Did you read it?

There is no need, to standard install Sikuli on the build machines, as stated in my step-by-step advise in comment #4.

Revision history for this message
amy cheng (cheng-yue) said :
#7

Thanks ReiMan, I followed your comment #4 , then I found that I use quote in set Path too, that cause problem.