I have a jar file 'myApp.jar' that I need to run through command line. When I run the jar on linux server it working perfect. However, when I tried to the same jar on mac terminal I am getting this error message:
Exception in thread "main" java.lang.UnsatisfiedLinkError: while loading kognac-core: Stream closed
at karmaresearch.vlog.VLog.loadLibrary(VLog.java:72)
at karmaresearch.vlog.VLog.<clinit>(VLog.java:22)
at org.semanticweb.rulewerk.reasoner.vlog.VLogReasoner.<init>(VLogReasoner.java:82)
at org.semanticweb.rulewerk.client.picocli.MyApp.someMethod(MyApp.java:150)
at org.semanticweb.rulewerk.client.picocli.MyApp.main(MyApp.java:110)
The command that I used to run the jar is:
java -jar myApp.java
The jar file is compiled and created by javaSE-1.8 through Eclipse on Mac.
The java version of Linux server is openjdk version "1.8.0_292"
The java versions on Mac are 3: Java SE 11.0.1(default version) , 1.8.0_202, 1.8.0_201 by these commands:
/Library/Java/JavaVirtualMachines/jdk1.8.0_201.jdk/Contents/Home/bin/java -jar myApp.java
/Library/Java/JavaVirtualMachines/jdk1.8.0_202.jdk/Contents/Home/bin/java -jar myApp.java
I tried to run the jar file on mac with all 3 java versions, but still getting the same error above.
How could I resolve this error on Mac terminal?
The problem isn't related to your app or how you run it.
Your app uses the karmaresearch project which I'm not familiar with (possibly, that's your own code, that you / your team wrote?) and this code attempts to load a so-called native library: These are libraries compiled straight for the OS/architecture your JVM is running on top of.
These take the form of a .jnilib file on mac, .dll on windows, and .so on linux and other posix-based OSes.
Native libraries are incredibly convoluted to ship: You need 1 such file for each combination of OS and underlying architecture. So, these days, you'd need at a minimum to make a reasonable claim that you're 'portable':
Mac AAarch64
Mac x84
Windows x64
Linux AArch64
Linux x64
Linux x32
BSD x64
and that's just a bare bones minimum.
These files cannot be inside the jar when you load them. The usual procedure is to obtain a location you can write to and load code out of (tricky), unpack the right file for the host OS to this folder, and then loadLibrary it. This is all very complicated. In general, either [A] you wrote karmaresearch and you need to think long and hard about using native libraries first, and if you truly need it, follow a tutorial, or [B] it's not your code, in which case you can't run this on a mac, at all, and there's nothing you can do about that, other than contact the makers of this library and ask them to add support for this.
Related
I tried GCJ and it compiled fine. I tried both for Ubuntu and windows. The compiled file is running on my Ubuntu machine as well the .exe with wine. But if I tried to run in on my Ubuntu server I got this error:
error while loading shared libraries: libgcj.so.14: cannot open shared object file: No such file or directory
But I thought I would not need to install anything to run "native" code. I also could not run the .exe on a windows machine.
Could you please tell me why this is happening? Maybe I'm compiling wrong. I use this: gcj --main=Hello -o hello.exe Hello.jar for windows.
When you run an executable it is very common to need a shared library, whether you use Visual Studio .NET or Java or C++.
When you compile a program for a specific platform, it usually only works on that platform or similar. If you want to run this program on Windows, you need to compile it for windows.
BTW GCJ is pretty old and out of date. I suggest you use Java 7 or 8. This will avoid the need to install additional libraries and will run on Windows or Linux without re-compiling.
I am working on an application in which I am using Tesseract for OCR.
My code is working absolutely fine in windows 32 bit system.
But when I try to run the same code in 64 bit machine using the 32 bit .dll files, the code is running but then the code is not giving the accurate results.
So I am running it in 64 bit machine using the 64 bit .dll files.
Now when I tried to run the same program, I got the following error in Console(Eclipse Kepler).
Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: %1 is not a
valid Win32 application.
at com.sun.jna.Native.open(Native Method)
at com.sun.jna.Native.open(Native.java:1759)
at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:260)
at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:398)
at com.sun.jna.Library$Handler.<init>(Library.java:147)
at com.sun.jna.Native.loadLibrary(Native.java:412)
at com.sun.jna.Native.loadLibrary(Native.java:391)
at net.sourceforge.tess4j.TessAPI.<clinit>(TessAPI.java:38)
at net.sourceforge.tess4j.Tesseract.init(Tesseract.java:293)
at net.sourceforge.tess4j.Tesseract.doOCR(Tesseract.java:227)
at net.sourceforge.tess4j.Tesseract.doOCR(Tesseract.java:176)
at net.sourceforge.tess4j.Tesseract.doOCR(Tesseract.java:159)
I have downloaded the 64 bit .dll files (https://github.com/charlesw/tesseract/tree/master/src/lib/TesseractOcr/x64) compatible with 64 bit system but still i am getting the same error.
I am using GhostScript v-8.71 on 64 bit machine. I have installed this in both Program Files and Program Files(x86). I have also set the environment variables accordingly.But still not working.
Please please provide me with some solution!
Tess4J only currently supports 32-bit JVM
This is the creator, nguyenq, responding to a similar issue on a sourceforge forum.
Similarly, in the tutorial it points out that only 32-bit DLL's are included in the distro.
To run with a JVM 64-bit, you'll need to use Tesseract and Leptonica 64-bit DLLs.
One solution: Tell your IDEto use a 32-bit JVM instead.
-- downside is that you may be mixing 32 bit and 64 bit environments, in a complicated app or env this could be odd... (I don't think it's too bad, but might be a pain in your IDE)
In an update found here, it seems you can find DLL's for 64-bit Java here, as part of the Tesseract wrapper for .NET (oddly enough). However, I haven't tried out those 64-bit DDL's yet and in the sourceforge link, it says they depend on the Visual C++ Redistributable for VS2012 or Visual C++ Redistributable for VS2013 ... which sucks....
I'll update this post if I figure out a cleaner solution.
UPDATE
Note that I did this working with Amazon Web Services instances.
I was able to get Tess4J to work on a 64-bit Ubuntu 14.04. It was actually very simple once I gave up on my Red Hat distro and went to Ubuntu.
sudo apt-get install tesseract-ocr will get tesseract set up completely. You can check by typing tesseract -v. I also needed GhostScript because I was working with PDF's. sudo apt-get install ghostscript again got everything set up. Verify with gs -v.
Now in your Java app, all you need to include are the JAR's from Tess4J's download in your path -- jna-4.1.0j.ar, jai_imageio.jar, tess4j.jar, and ghost4j-0.5.1.jar if you are working with PDF.
In your Java app, you need to set the data path so your Tesseract instance knows where tesseract is installed. Even while I had the environment variable set, it never worked for me. I needed to explicitly set the data path like so:
Tesseract tessInstance = Tesseract.getInstance();
tessInstance.setDatapath(System.getenv("TESSDATA_PREFIX"));
ImageIO.scanForPlugins(); // make sure it knows about GhostScript, to work with PDFs
String result = tessInstance.doOCR(myFile);
Be sure that setDatapath() sets to the parent folder of the tessdata folder of your tesseract installation (on my Ubuntu this was /usr/share/tesseract-ocr/`).
That was all I needed. No worrying about DLL's in class path.
tl;dr:
Use up-to-date Ubuntu
sudo apt-get tesseract-ocr
sudo apt-get ghostscript if working with PDF
include proper Tess4J JAR's (jna-4.1.0j.ar, jai_imageio.jar, tess4j.jar, and ghost4j-0.5.1.jar if you are working with PDF)
call tess.setDataPath() to point to your tesseract installation (/usr/share/tesseract-ocr/ for my Ubuntu 14.04)
ImageIO.scanForPlugins() if using GhostScript
That's it. You are good to go call tess.doOCR(MyFile) happily
I've been working on Aptana Studio and some JRE required software for a bit of time now , but since yesterday something quite odd happened, as suddenly the software that requires it threw me an error No Java virtual machine was found . Last thing I did before that was restoring my system files permissions thought safe mode as I had some trouble with that , could this have anything to do with it ?
I've tried installing JRE once again , no results. However when I run
/Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java -version
I do get the following
java version "1.7.0_55"
Java(TM) SE Runtime Environment (build 1.7.0_55-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)
Aptana gives me the following error
No Java virtual machine
was found after searching the following locations:
/Applications/Aptana Studio 3/AptanaStudio3.app/Contents/MacOS/jre/bin/java
java in your current PATH
And other software such as Spine won't simply start.
My .bash_profile is the following :
PATH="/Library/Frameworks/Python.framework/Versions/3.4/bin:${PATH}"
PATH="/Library/Java/JavaVirtualMachines/jdk1.7.0_55.jdk/Contents/Home/bin:${PAT$
export PATH
export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.7.0_55.jdk/Contents/Home
The output of echo $PATHis the following
/Library/Java/JavaVirtualMachines/jdk1.7.0_55.jdk/Contents/Home/bin:/Library/Frameworks/Python.framework/Versions/3.4/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/git/bin
The output of echo $JAVA_HOME is the following
/Library/Java/JavaVirtualMachines/jdk1.7.0_55.jdk/Contents/Home
And Java invocations on the terminal work.
Guidance will be highly appreciated.
After trying Peter's suggestion the problem persisted but now in another context : "/System/Library/Frameworks/JavaVM.framework" does not contain the JNI_CreateJavaVM symbol"
After struggling for many hours, and reading about people with the same issue opting to re-install the entire OS , decided to examine the issue from another perspective, the thing I first mentioned here that I believe went unnoticed was that I restored my permissions before this happening, so what I did was the following.
After reading a bunch of articles about Apple no longer providing Java support themselves but Oracle providing it, reasoned through it and realized that perhaps paths (Often called directories) from Apple's final Java release may have not been strictly the same as the new Oracle releases, so decided to wipe out all recent Oracle Java Runtime Environment that I found on /Library/Java/JavaVirtualMachines and delete the Java Applet Plugin from /Applications (Just search for it on your /Applications path) .
Installed Apple's last stable release from the following link.
Located where Apple located their Java releases : /System/Library/Frameworks/
My particular interest was the Java Runtime Environment , so I explored the JavaVM directory on /System/Library/Frameworks/
Found out that all Apple's JRE previous releases reside on a directory called Versions that is within /System/Library/Frameworks/JavaVM.framework directory, here's where I noticed something rare, for some reason at the moment I restored file permissions from my Disk Utility Application , this directory was made inaccessible (By not giving the root user permissions to access anything in itself).
Went to my terminal console and inside the JavaVM.framework directory modified the permissions to that directory to be accessible for all users by running the following command chmod -R 777 Versions.
After executing these actions I went straight to my JRE-Required software and attempted to open it , success!
Things to learn from the issue.
Oracle's Java JDK/JRE are located in different paths from Apple's. (If you are struggling with some other issue, verify your Java version to determine your Java installation directory)
Apple's disk utility application might define different permissions than expected for some files. (After restoring permissions verify that everything's working fine, if not this may be the cause of your problems.)
Looks like AptanaStudio (Eclisebased right?) assumes that you have a JRE inside the Aptana directory (/Applications/Aptana Studio 3/AptanaStudio3.app/Contents/MacOS/jre/bin/java)
I assume that there is nothing there. Simplest way would be to symlink your existing JRE installation to that directory:
ln -s /Library/Java/JavaVirtualMachines/jdk1.7.0_55.jdk/Contents/Home/jre /Applications/Aptana\ Studio\ 3/AptanaStudio3.app/Contents/MacOS/jre
Or you could start Aptana from the terminal and specify the path to java with -vm:
./aptana -vm "/path/to/java/bin/directory"
Environment variables that must be available to GUI applications are a bit tricky in OsX (at least in my experience).
It is possible to set global PATH (and other variables) in /etc/launchd.conf, see for example here and /etc/paths.d see here.
Simple Solution
For Windows:
1.download the JAVA runtime environment x86(32bit) version else you will get an error with dll file from here http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html
Extract the folder out of the .tar file you downloaded.
Rename the JRE folder to "jre"
Then paste it in to this directory
C:\Users\"User Name"\AppData\Roaming\Appcelerator\Aptana Studio
This worked for me
I uninstalled all my Java JREs and JDK for Windows 10. Then I downloaded Aptana again and let it install Java for me. I think JAVA 8 was my problem, but this worked and I can still install the other versions again.
I use;
Windows 7 64 bit,
JAVA_HOME= JDK1.7 64 bit,
Tomcat-7 64 bit version
When I start tomcat from commandline it works ok, but when I use it within IntelliJ I get this error;
java.lang.UnsatisfiedLinkError: tcnative-1 (.\tcnative-1.dll is not a valid Win32 application.
I also point to an IBM 32bit JDK1.6 from IntelliJ in project settings, but this could not be a problem since this setup works on some other collegae's computers
I have read similar questions here, but none of them offers a solution for my case, any ideas, how can I fix this?
Here is a link which describes the problem :
Cause:
You get this message when you start Tomcat. Tomcat is looking for a shared object call tcnative (dll or so depending on the platform). If it doesn't find it, it'll revert to java libs. Either way, this shouldn't affect your application. tcnative dll is needed to address scalability in Tomcat.
Solution:
Turn down debugging level for Tomcat or
Get tcnative from http://tomcat.apache.org/native-doc/ (windows users can download the binary) and place it in your library path.
Lib path is usually: C:\Program Files\Apache Software Foundation{Apache Tomcat directory}\lib; for windows
Basically It seems that you may have an incorrect version.
Are you using multiple java on your machines if yes then try to look into environment variables for JAVA_HOME & PATH. Secondly, also paste the complete version of java and tomcat
Also run following commands at command prompt
java -version
javac -version
echo %JAVA_HOME%
And are you using MSI installer of tomcat or just a zip version of tomcat. Because in many cases MSI installer never work for some ghost reasons.
I have started to build a java service which incorporates JNA to load a native C/C++ lib and i want to run the java service on the Raspberry PI aka arm platform. I have successfully built a stable ground of the service and it runs on both Windows7 and linux-amd64/debian but.. on the RPI platform i get the above stated error:
Exception in thread "main" java.lang.UnsatisfiedLinkError: JNA native support (/com/sun/jna/linux-arm/libjnidispatch.so) not found in resource path
On the RPI i have done the following:
* Installed both openjdk7 and java8 beta with arm hard float support.
* Installed libjna-java lib.
Following are set:
Java
root#pisces:/opt/TellstickReplay# java -version
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b36e)
Java HotSpot(TM) Client VM (build 25.0-b04, mixed mode)
root#pisces:/opt/TellstickReplay#
LD_LIBRARY_PATH
root#pisces:/opt/TellstickReplay# echo $LD_LIBRARY_PATH
/opt/lib/jna
CLASSPATH
root#pisces:/opt/TellstickReplay# echo $CLASSPATH
/usr/lib/jna
None of the settings seems to satisfy JAVA with JNA support. I have even tried to export both jna.jar and linux-arm.jar into the project in Eclipse and all together rebuild the jars into the exported jar still getting the same error. The exported jar has been tested successfully on both windows and linux so the jar file is working.
I have also tried to just use CLASSPATH in the Manifest in the jar file but with no success. I have also tried to explicitly load the libjnidispatch.so from the absolute path but JAVA then starts to complain that it cannot find the file to libjnidispatch.so even that the path is 100% correct.
So.. does anyone know HOW to correctly get JNA support on the Raspberry PI platform to work?? Please, im getting tremendously frustrated and soon giving up hope to fix this..
Where is libjnidispatch.so on your system? If it's not on your system, JNA will attempt to unpack it from jna.jar from the indicated resource path. If it's not there either, you'll get the UnsatisfiedLinkError.
It's recommended that you explicitly install libjnidispatch.so on your system where possible; the jna.jar bundling is mostly there to facilitate usage on the more common desktop platforms.
linux-arm.jar contains the most recent build of libjnidispatch.so, but only WebStart knows how to automatically load the native from a jar like that. If you unpack it into /opt/lib/jna (or elsewhere on LD_LIBRARY_PATH), you should avoid the link error.
I am re-compiling Apache Spark for RPI2 and I've spent a couple of days to fix the issue. Then I've found the easiest possible solution. All you need to have is a libjnidispatch.so link in your default JVM's native lib path.
sudo -s ln -s /usr/lib/arm-linux-gnueabihf/jni/libjnidispatch.so /usr/lib/jvm/default-java/jre/lib/arm/libjnidispatch.so
I packaged the new jna.jar (4.0) and it includes the linux-arm/libjnidispatch.so. The code I was trying to run now works.
I'd say its more of "glitch of configuration of the location for the "libjnidispatch.so" in the OS your using or that particular JRE systems internal folder/package/JNDI-structure, it may not be an identically laid out Debian or Java JRE.
I do the following:
sudo apt-get install libjna-java
get the installed jar /usr/share/java/jna.jar
Install jna.jar as a maven dependency
They worked to me...