Change where Sikuli loads opencv_java342.dll from

Asked by Landon Alexander on 2020-03-31

I'm currently using Sikuli with the sikulixapi-2.0.3.jar in Eclipse as a maven dependency in a Java project without installing the SikuliX IDE.

I'm on a locked down network and by default it loads the opencv_java342.dll files from AppData which is blocked by my company, resulting in the following error:
"RunTime:loadLib: opencv_java342.dll (failed) probably dependent libs missing:
C:\Users\userName\AppData\Roaming\Sikulix\SikulixLibs\opencv_java342.dll: Access is denied"

I've been able to get around this by forcing it to update my Environment as a runtime configuration with PATH pointing to a lib folder containing the same DLL's it's trying to load and marking it in Eclipse to replace native environment(Appending didn't resolve the error). I've tried adding this folder in native libraries in my build path and other locations, but they all result in the same error.

This works, but not as intended. Two new folders are created in my workspace, %SystemDrive% and SikulixAppDataNotAvailable, the latter of which contains SikulixLibs and the required DLL files I was trying to point to and this allows my scripts to run locally without being blocked by my company.

What I'm trying to do now is create a runnable Fat JAR file that I can use to run the scripts on a separate system with the working scripts I have now. When I generate that file, the scripts start and perform a couple of actions but return to using the default AppData path for opencv_java342.dll which of course is blocked and fails to continue.

Is there a better way to change how Sikuli loads those DLL files in such a way that I can specify the desired location and get it to load both at runtime and when building the Far JAR file? As currently it seems it has two locations by default, one in AppData, and one alternative it creates in the current workspace if it cannot load the first and when building the Fat JAR file it does not use or take into account the second path, instead trying the first path.

Question information

Language:
English Edit question
Status:
Answered
For:
Sikuli Edit question
Assignee:
No assignee Edit question
Last query:
2020-03-31
Last reply:
2020-04-01
RaiMan (raimund-hocke) said : #1

The background on Windows:
The mentioned DLL is contained in the SikuliX jars and exported at runtime to the mentioned standard folders in %APPDATA%

Putting a folder containing the DLL into the PATH does not help in the situation outside Eclipse, since it is checked via %APPDATA%, wether the DLL is available. If not it is tried to export it, which again leads to the mentioned error.

A suitable workaround should be, to specify the %APPDATA% environment variable at runtime to point to a folder, that is accessible (it is created if not already there)

This worked:
set APPDATA=SikulixAppData

which at runtime leads to a folder SikulixAppData created in the users home folder.

I will setup a complete testcase comparable to your situation and revise the handling of the APPDATA folder including possibilities to specify options.

this issue is tracked on GitHub: https://github.com/RaiMan/SikuliX1/issues/340

Version 2.0.5 should have a solution for your case.

RaiMan (raimund-hocke) said : #2

I added a new feature to version 2.0.5

If you want to test it beforehand, give me a note here or on GitHub.

Can you help with this problem?

Provide an answer of your own, or ask Landon Alexander for more information if necessary.

To post a message you must log in.