I have a project on netbeans that I am trying to run on my mac. The problem is every time it gets to the line:
System.load(libPath + File.separatorChar + "libjdic.jnilib");
It gives me the following error:
Exception in thread "main" java.lang.UnsatisfiedLinkError: {path}/libjdic.jnilib: no suitable image found. Did find: {path}/libjdic.jnilib: no matching architecture in universal wrapper
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1827)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1703)
at java.lang.Runtime.load0(Runtime.java:770)
at java.lang.System.load(System.java:1020)
at ------.-------App.main(--------App.java:113)
Java Result: 1
I have checked, and the paths are all correct. This is working on windows, but I need it to work on mac as well. It is properly determining the OS and deciding which additional files to load (In this case .jnilib). I have seen a similar question on here, but without an answer.
SPECS:
Mac OSX 10.8.4
64bit
Java(TM) SE Runtime Environment (build 1.6.0_45-b06-451-11M4406)
Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01-451, mixed mode)
Netbeans version 7.3.1
Does anyone know why this is happening?
Related
I was running SQL workbench on my mac, and it is complaining that it needs java 8, but instead it found java 10.0.1 on my computer. So I need to locate the java executable and find ways to downgrade the java version. However, I got totally lost when I was looking for the java version.
When I run '/usr/libexec/java_home -V' from terminal, I get this:
Matching Java Virtual Machines (3):
9.0.4, x86_64: "Java SE 9.0.4" /Library/Java/JavaVirtualMachines/jdk-9.0.4.jdk/Contents/Home
When I run 'java -version', I get below, which means that it is pointing to the java 9.0.4 listed above:
java version "9.0.4"
Java(TM) SE Runtime Environment (build 9.0.4+11)
Java HotSpot(TM) 64-Bit Server VM (build 9.0.4+11, mixed mode)
However, when I check java control panel under 'System Preferences', it shows that my current java version is 10.0.1 under the tab 'General'. Under tab 'Desktop Settings', the listed JRE path is '/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java'. So, it looks like the software (SQL workbench) is complaining about this java version. But how come it is not the java version I got from terminal (9.0.4)? Which java is actually running on my Mac in this case? If I want to change the java 10 listed under java control panel, what should I do?
Thanks!
I've been trying to install and successfully run OpenSplice DDS on CentOS, The initial objective is to get it installed and run the HelloWorld Example (In Java),I did make the files necessary, using make, the compilation stage for subscriber and publisher steps which require compilation (of .jar) is very presistant, I've been working on this for almost 2-3 weeks, the problem is, there is very few documents and/ or resources discussing issues related to DDS installation(and there are many), I also tried to consult with my professor, he hinted to me that this could be a compatibility problem,sometime when I fix one issue with this installation another issue comes up, below is my current output:
[root#localhost standalone]# java -jar saj_helloworld_sub.jar
OpenJDK 64-Bit Server VM warning: You have loaded library /root/Downloads/HDE/x86.linux/lib/libdcpssaj.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
org.opensplice.dds.dcps.DomainParticipantFactoryImpl.get_instance() failed: /root/Downloads/HDE/x86.linux/lib/libdcpssaj.so: /root/Downloads/HDE/x86.linux/lib/libdcpssaj.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)
Exception in thread "main" java.lang.NullPointerException
at DDS.DomainParticipantFactory.create_participant(Unknown Source)
at DDSEntityManager.createParticipant(DDSEntityManager.java:67)
at HelloWorldDataSubscriber.main(HelloWorldDataSubscriber.java:38)
Java Version:
# java -version
openjdk version "1.8.0_111"
OpenJDK Runtime Environment (build 1.8.0_111-b15)
OpenJDK 64-Bit Server VM (build 25.111-b15, mixed mode)
System Details :
# uname -a
Linux localhost.localdomain 3.10.0-327.36.1.el7.x86_64 #1 SMP Sun Sep 18 13:04:29 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
So, the wrong ELF class is one of the possible errors that I may get,the difficulty of getting DDS installed and working correctly is not encountered only by me alone, some other friends of mine also having different errors,and since no resources and discussions exist online about OpenSplice DDS installation(except the official website and the readme file), i decided to open this discussion.
You're running a 64bit operating system - the x86_64 indicates this.
You're running a 64bit java VM - OpenJDK 64-Bit Server VM (build 25.111-b15, mixed mode)
You've got a 32-bit library: /root/Downloads/HDE/x86.linux/lib/libdcpssaj.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)
The simplest workaround is to download the 64bit version of OpenSplice DDS to get past this issue.
My intention is to do a bit of modding of Minecraft using MCP. For that, my Java JDK needs to be specified in the system PATH and working. Unfortunately, it isn't working as typing "java -version" returns the version I use for running Minecraft (JRE7), not the one I've specified in the PATH (JDK6). (Note: JDK6 is supposedly what's needed for this, and the JRE obviously wouldn't work for development anyway.)
Here's my full PATH:
C:\Program Files\Java\jdk1.6.0_45\bin;C:\Program Files (x86)\OpenVPN\bin;C:\Program Files (x86)\Google\google_appengine\
The specified JAVA_HOME:
C:\Program Files\Java\jdk1.6.0_45
And here's the result of "java -version", even after a full system restart since installing the JDK and setting the PATH:
java version "1.7.0_45"
java(TM) SE Runtime Environment (build 1.7.0_45-b18)
java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
Help would be massively appreciated, thanks!
x_a_horse_with_no_name's comment got it! I simply renamed java.exe and javaw.exe in C:\Windows\System32 (& in \SysWOW64), thereby forcing Windows to instead read from the PATH. My guess is that the JDK6 install refused to overwrite the JRE7 files as they were newer or something. Regardless, problem solved, thanks!
I'm trying to run a program using Java 3d on a Raspberry Pi and I'm having some problems with the native libraries. I've found a version compiled for ARM on the debian website here
http://packages.debian.org/en/wheezy/armhf/libjava3d-jni/download
I've also tried the 'dfsg-9' version.
When I try and run the program the following output is printed:
java version "1.7.0_40"
Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
Java HotSpot(TM) Client VM (build 24.0-b56, mixed mode)
A fatal error has been detected by the Java Runtime Environment:
SIGILL (0x4) at pc=0xa6e5b9e2, pid=7251, tid=3057575024
JRE version: Java(TM) SE Runtime Environment (7.0_40-b43) (build 1.7.0_40-b43)
Java VM: Java HotSpot(TM) Client VM (24.0-b56 mixed mode linux-arm )
Problematic frame:
C [libj3dcore-ogl.so+0x69e2] Java_javax_media_j3d_NativePipeline_getAWT+0x11
I don't really have any experience debugging problems to do with native code and am hoping for some advice on how to proceed with ths problem.
Thanks for reading.
Raspberry PI is based on an ARMv6 architecture processor. Debian armhf requires ARMv7 (or later). Hence an illegal instruction exception is exactly what I would expect.
Debian armel distribution works on the RPI.
However, if you are adding these packages to something like a raspian installation, that is unlikely to work, and you need to get your packages from a raspian repository.
The stacktrace indicates that your program triggered a SIGILL
SIGILL The SIGILL signal is sent to a process when it attempts to
execute an illegal, malformed, unknown, or privileged instruction.
Unless you wrote native code, this error is not your fault or doing. Try upgrading to the latest JDK (Java7 update 45) to see if this fixes it.
You can also try running your Java process with the -Xint flag to prevent any code from being dynamically compiled. Though not a long term solution, it may help identify where the error is happening. In your trace, it doesn't appear to be crashing in dynamically compiled code.
I'm trying to build the new Java bindings of Open MPI (v.openmpi-1.9a1r29661) on Macbook Pro running Mavericks (OSX 10.9). I have the JDK 7 installed:
^_^:examples demirelo $ java -version
java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
I configured the OMPI with that command:
./configure --enable-mpi-java --with-platform=optimized --with-jdk-dir=/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home --prefix=/Users/demirelo/libs/openmpi
which is followed by the usual suspect:
make all install
When I tried to run the HelloWorld example, I received the following runtime error:
^_^:examples demirelo $ ../bin/mpijavac Hello.java
^_^:examples demirelo $ ../bin/mpirun -np 1 java Hello
JAVA BINDINGS FAILED TO LOAD REQUIRED LIBRARIES
-------------------------------------------------------
Primary job terminated normally, but 1 process returned
a non-zero exit code.. Per user-direction, the job has been aborted.
Moreover, the ~/.bash_profile has the correct path to the /lib folder.
export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/Users/demirelo/libs/openmpi/lib/
It's quite mysterious which libraries failed. Previously, I was able to build slightly older version (openmpi-1.9a1r28578) on Lion and still use it on Mavericks. This time I needed a freshly compiled OMPI but didn't work out. I'm wondering if anyone else had the same issue with Mavericks and was able to fix it.
This appears to be a bug in Open MPI that is comprised of at least two issues:
OMPI is hard-coded to try to dlopen libmpi.so, which is the wrong name on OS X (it should be libmpi.dylib).
Even after I fix that, I'm running into another Java error that I need to run by the Java programmers.
Apparently, we haven't tested the OMPI Java bindings on OS X in a long time. :-(
Such is the life of running against the SVN trunk. Sorry!