Dependency problem : libstdc++ GLIBCXX_3.4.9

You have to install your own JXGrabkey for your system.

In the libs folder replace the respective ..xxx...so

I fetched JXGrabkey source code and compiled both C++/Java projects with Netbeans successfully but I can't find any generated .so file.

As shown :

# pwd
/usr/local/src/jxgrabkey-code/JXGrabKey
# find . -name *.so
./C++/dist/Debug/GNU-Linux-x86/libC__.so

What am I missing out?

If you run a build with C++ code as a Netbeans project, usually the target is stored a
..project.../dist/(Debug | Release)/<CompilerSuite>

the target in your environment can be /usr/lib64, in which case you simply have to delete the bundled jx...so from the Sikuli libs folder.
You do not need a newly compiled/built JX...java (the bundled JX.. Java stuff will find the lib either in Sikuli/libs or in your standard library folder /user/lib64)

Sorry I've just realized I could just try replacing that libC__.so with libJXGrabkey.so and here's what I got :

# ./runIDE
running SikuliX-IDE: -Xmx512M -Dapple.laf.useScreenMenuBar -Dfile.encoding=UTF-8 -Dsikuli.FromCommandLine
-jar ./sikuli-ide.jar
[error] ResourceLoaderBasic: loadLib: Fatal Error 110: loading: libJXGrabKey.so
[error] ResourceLoaderBasic: loadLib: Since native library was found, it might be a problem with needed dependent libraries
/root/sikuli/libs/libJXGrabKey.so: /root/sikuli/libs/libJXGrabKey.so: undefined symbol: _ZTVSt19basic_ostringstreamIcSt11char_traitsIcESaIcEE

simply no.

The bundled libJXGrabkey.so expects a /usr/lib64/libstdc++.so.6 on your system.

It complains, that it is not found (which also might mean, that the one is not compatible.
What is missing here is the standard C internal support.

So yo have to build a libJXGrabkey.so from the sources to get the correct compiler support and put it in Sikuli/libs or put it in /user/lib64 and delete the one in Sikuli/libs.

If you succeed, I guess you will run into the next similar problem for the bundled libVisionProxy.so.
To solve it, we have the https://launchpad.net/sikuli/sikulix/1.0.1/+download/Sikuli-1.0.1-Supplemental-LinuxVisionProxy.zip

The problem is solved for libJXGrabkey.so thank you for your precious help. However I'm struggling a bit with tesseract.
I did something very similar to http://paramountideas.com/tesseract-ocr-30-and-leptonica-installation-centos-55-and-opensuse-113 but I still get the no such file error on libtesseract.so.3 when trying to run a Sikuli script.

However when I locate libtesseract I get http://pastebin.com/KMa1TNn2 but as I got a 64 bits archi I suppose sikuli look for the tesseract libray in /usr/local/lib64 ?

Sorry if this is kind of a newbie question but I guess I am...

Sikuli does not expect anything about dependent libs like libtesseract.

Where it is searched to full fill the external refs from libVisionProxy.so (the Sikuli module) solely depends on your loader configuration (loader search path), which seems to be at least in your installation /usr/lib64.

So the the safest way seems to be to built everything (the final .so stuff) into /usr/lib64

I've tried setting the "configure" --prefix directive so it would build the libraries to /usr/lib64 instead of /usr/local/lib but it just results in the "make install" failing with :

error: cannot install `libtesseract_main.la' to a directory not ending in /usr/local/lib

I've also tried with /usr/local/lib64 and same error.

However I spotted a message during the "make install", when building to /usr/local/lib : http://pastebin.com/Ec7AEk0x

Does that make sense to you? I had already tried "export LD_LIBRARY_PATH=/usr/local/lib" but Sikuli didn't take it into account.

Forgot to mention, I'm using tesseract 3.00 (https://code.google.com/p/tesseract-ocr/downloads/detail?name=tesseract-3.00.tar.gz).

The later versions do not compile for some reason so I've chosen to stick with 3.00 since it compiles fine.

Sorry, but this is beyond my scope (to little experience, too much effort to dive in).

I am happy enough, to get the stuff running on Ubuntu and have a working script for building libVisionProxy.so.

I guess, the CentOS community should have the solutions for you.