I am unable to use my own libVision.so (Linux)

Asked by David Inman

Forgive me if this has been asked before, but I have googled and found what was supposed to be an answer that did not work for me. This was what I was following: https://answers.launchpad.net/sikuli/+question/249653

I have my own libVision.so on Linux RH5. I have built this myself. It internally references tesseract such that no additional information is required to find libTesseract.so at run time.

What seems to fail is a swig interface from Java to libVision (guessing here).

The error I get at run time:
    Exception in thread "Thread-5" java.lang.NoClassDefFoundError: org/sikuli/natives/VisionProxyJNI
            at org.sikuli.natives.FindInput.<init>(FindInput.java:39)
            at org.sikuli.script.Finder.<init>(Finder.java:33)
            at org.sikuli.script.Region.checkLastSeenAndCreateFinder(Region.java:2419)
            at org.sikuli.script.Region.doFind(Region.java:2334)
           ...

I am running Java version "1.7.0_45".

My biggest problem is that I don't understand the build system enough to be confident with debugging.

My goal is to take the ruby gem sikuli-server, which is very incomplete and improve it so that Ruby users
(rather than just JRuby users) can script sikuli. I have already written a fair amount of Java needed to do
this, but I'm unable to make sikuli work to run my tests. I'm happy to share my results, but I need to get
quite a bit farther. I'm strong with Linux and Ruby; new to Maven; OK with Java.

Any help understanding the build environment to fix the libVision.so issue would be appreciated.

Thanks,
Dave

Question information

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

-- 1. version 1.1.0 already has a Ruby scripting support, that is even supported in the IDE.
The stuff is available as a gem online (not at head of development though)

-- 2. libVisionProxy.so
the above question is related to version 1.1 in an early stage.
Are you using version 1.1.0-Beta4 or is it version 1.0.1?
The build depends on the version.

-- 3. sikuli-server
this is an implementation, that motivated Roman to contribute the Ruby support to SikuliX 1.1 ;-)

This would really help me currently:
- test the nightly build on Linux and report problems directly on github
- look into the Ruby support in 1.1, test it and contribute if needed (pull requests to github)

the best point to start: sikulix.com

Revision history for this message
David Inman (dave-inman) said :
#2

1. If 1.1.0 already has Ruby support, that would be great. JRuby support, however, does not work for me. I use it sometimes,
but its not viable for some applications - the VM can be both slow and fast, not to mention a perpetual list of problems with gems that include C extensions. Ideally I would like both. Are both JRuby and Ruby supported (may in the fashion of the sikuli-server gem)?

2. I was using 1.0.1 and had some luck with libVision.so there. However, 1.1.0-Beta4 is what I'm trying to use now because of its feature set. When I started modifying the sikuli-server gem to support more commands I quickly gained appreciation for what I would need and found 1.1.0 desirable. I'm able to get the 1.1.0-Beta4 IDE to start, but it does not work with libVision.so.

3. I did not know. I wish I did. I'll see if I can find the Ruby-related code.

RE: helping. I'm thrilled to help, but I'm quite frustrated with the build system, I cannot tell what I'm doing wrong versus what might be broken due to development changes. I really don't know what commands I'm supposed to run to get a libVision.so to work. I have read suggestions on this site and via google, but when I try the suggestions I simply get too many errors, don't
know if they are real, and the result does not work. I don't know enough about the maven targets (or maven) to address only what I need. If I were to be given a little direction on how libVision is incorporated, I think I could fix what is broken either in my code or Sikuli.

Thanks,
Dave

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

at 1: of course it is "only" JRuby, that is supported in version 1.1.0 (any scripting language, that can be easily integrated must be based on Java and cannot have any C-based elements that are not integrated via JNI/JNA)

at 2: the libVisionProxy.so from 1.0.1 is not usable in 1.1.0.
If you worked with the Linux Supplemental package:
Here is a version for 1.1.0:
https://dl.dropboxusercontent.com/u/42895525/SikuliX-1.1/SikuliX-1.1.0-Beta-Supplemental-Linux.zip
Carefully read through the contained README
From tomorrow on it will be available at the nightly build page as well

at 3: JRuby related code:
org.sikuli.scriptrunner.JRubyScriptRunner
/JRubyGem/lib

at RE:
If you do not want to change anything on the Java level, then you do not have the need to fully understand the Maven build of the project for now. In a few days I will have the usage docs of the github project up to date, then you might try again.
The included native stuff (for Linux it is only libVisionProxy and in some cases the JXGrabKey lib) is not built in the Maven run of the project. This currently only includes the packaging of the prebuilt libraries into the sikulixsetup.jar.
Prebuilt means: I am doing this on my machines offline and copy the libs to the Maven project.
So for now it is sufficient for you to take the stuff from nightly build.
Since I am planning to eliminate the native stuff anyway, I will not document the native build for Mac and Windows.
The only needed native build is that for libVisionProxy on Linux - which is the mentioned supplemental package.

Revision history for this message
David Inman (dave-inman) said :
#4

Thank you for supplemental zip file. I'll see if it works for me. I was trying to use my own which uses an rpath properly to reference a tesseract trained by me. I did not try to use the the libVisionProxy of 1.0.1 in 1.1.0 - I assumed it would not work.