Change where Sikuli loads opencv_java342.dll from
I'm currently using Sikuli with the sikulixapi-
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\
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(
This works, but not as intended. Two new folders are created in my workspace, %SystemDrive% and SikulixAppDataN
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=
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:/
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.