I am facing an issue when setting the native library path for a Java process (say, com.example.Main), launched via a simple bash script on a 64-bit CentOS 5 machine.
The related script code is as follows:
#!/bin/bash
export JAVA_HOME=/usr/local/java
export EXTRA_LD_LIBRARY_PATH=/opt/extra/lib64:/opt/extra/java/libs
${JAVA_HOME}/bin/java -Djava.library.path=${EXTRA_LD_LIBRARY_PATH}:${LD_LIBRARY_PATH} com.example.Main
In the EXTRA_LD_LIBRARY_PATH, I have placed some 64-bit native libraries that are needed by the Main class.
However, the Main class causes a Java InternalError to be thrown, despite the library files being in /opt/extra/lib64. If, however, I copy these same library files to /usr/lib64, the error goes away and the code works as expected. (Incidentally, env shows that LD_LIBRARY_PATH is not set, so /usr/lib64 is apparently used by some default setting.)
Is that normal behavior?
Thanks!
Related
I had SunOs 5.10 unix server , where i had written a script to execute a java file which is as below
#!/bin/ksh -x
export JAVA_HOME=openjdk1.8.0_331/bin
$JAVA_HOME/java com.myclass.MyClient
in this script there is alot of code which includes log file, and other binaries class path added before exporting JAVA HOME. But when i am executing i am getting the below error
openjdk1.8.0_331/bin/java : Cannot execute
i had changes lot of java versions but getting the same error
Your JAVA_HOME is not an absolute path. This is broken; many tools will just fail when you do this. Just make it an absolute path. It may or may not explain your error, but it's a ticking timebomb.
JAVA_HOME cannot be bin; its the level above bin.
It looks like you're using JAVA_HOME as an ersatz script variable to make your script work, but this is wrong: JAVA_HOME is used by all sorts of tools and has a very specific meaning, and it's not whatever you think it is.
There are 2 obvious explanations for your error:
Some tool sees JAVA_HOME, attempts to run java based on this, and fails, because your JAVA_HOME is broken. There's a ton of infra that is 'custom' per OS, and it may well be that the SunOS setup didn't fail if you set JAVA_HOME to broken values, but it does fail here. The fix is to not have broken JAVA_HOME, not to start looking for a setup on your new OS that can deal with broken JAVA_HOME settings. In other words, your script was always broken, it just so happens that your specific set up on that specific server on that specific version of sun OS so happened to be capable of dealing with the mess.
A much simpler explanation is also possible: That executable does not run on your OS+Architecture combination. trivially testable: Do NOT set JAVA_HOME at all and just try to run that java executable by e.g. cd ing to the path and running ./java -version. See what happens. If that also gives you cannot execute, voila - the script isn't the problem (though it still has a broken JAVA_HOME you should be fixing), you need to install a JVM that works on your OS+Architecture.
I am going through Tiny OS tutorial lesson number 4 "Mote-PC serial communication and SerialForwarder" and I am stuck on the line where it says
"Once you have installed TestSerial, you need to run the corresponding Java application that communicates with it over the serial port. This is built when you build the TinyOS application. From in the application directory, type
$ java TestSerial
However when I type this, I face the following error
Error: Could not find or load main class TestSerial
I tried several things to fix this issue, but none helped.
Solutions that I tried:
set CLASSPATH to the directory that I am currently in, which is
export CLASSPATH=.:/home/wsn/tinyos-main/apps/tests/TestSerial
2)set CLASSPATH to the directory where tinyos.jar is located
export CLASSPATH=.:/home/wsn/tinyos-main/support/sdk/java/tinyos.jar
3)run command using java -cp . TestSerial
however I keep having the same error
Is there any other better way to fix it?
I am using Virtual Machine with Fedora OS
I am trying to run the program on mib520 platform and I use iris motes
my java version
openjdk version "1.8.0_31"
OpenJDK Runtime Environment (build 1.8.0_31-b13)
OpenJDK Server VM (build 25.31-b07, mixed mode)
You must have skipped the step when you had to run the make command.
Navigate to the apps/tests/TestSerial folder and type make [platform] (such as make telosb, make iris e.t.c), the makefile that will be run will be the makefile in the TestSerial folder which is defined as follows:
COMPONENT=TestSerialAppC
TOSMAKE_PRE_EXE_DEPS += TestSerial.class
TOSMAKE_CLEAN_EXTRA = *.class TestSerialMsg.java
TestSerial.class: $(wildcard *.java) TestSerialMsg.java
javac -target 1.4 -source 1.4 *.java
TestSerialMsg.java:
nescc-mig java $(CFLAGS) -java-classname=TestSerialMsg TestSerial.h test_serial_msg -o $#
TINYOS_ROOT_DIR?=../../..
include $(TINYOS_ROOT_DIR)/Makefile.include
So the makefile compiles TestSerial.java. After this you can proceed to installing the application and then running the TestSerial application.
So step by step on a iris mote for example you would
Navigate to the apps/tests/TestSerial Folder
Make the application by typing make iris
Connect your mote and then type motelist. This command will list all connected motes. The name of your mote should be listed under the "Device" section. Note this for use in the next two steps.
Install your application by typing the command make iris install.1 bsl, [DEVICE NAME]. This will make and upload your program to your device.
Run the TestSerial application by running java TestSerial -comm serial#[DEVICE NAME]:iris
If you use another platform such as telosb then just replace all occurances of iris in the commands above with telosb.
I want to make a script starting with a line:
#!java hogehoge.Hoge
In my machines of OS X and CentOS7, it runs.
But machines of CentOS6 give me an error:
./test.sh: bad interpreter: java
(My OS is JP so I omitted some of error messages but anyway it says java does not exist.)
All the environments are under zsh and
of course, every $PATH contains a certain PATH like /usr/bin.
If I try a new script starting with:
#!/usr/bin/java hoge.Hoge
then it runs even in where the script with "java" does not work.
Does the difference come from the one between OSs?
or is there anything else that I do not realize?
Java isn't a script interpreter, but you can run your java process with a script. Something like
#!/usr/bin/env bash
# export JAVA_HOME="/path/to/java_installation"
# export PATH="$PATH:$JAVA_HOME/bin"
java hoge.Hoge
You may need to define JAVA_HOME and add it to your PATH (depending on your installation of Java).
I have a Java program that calls a function in a JNI library. The JNI code statically loads another shared library.
When executing the Java application using Eclipse, I get an error java.lang.UnsatisfiedLinkError: ... Can't find dependent libraries
But, if i execute the same command in commandline, the program works fine. What am I doing wrong in Eclipse?
I made sure to go to Debug View -> Processs -> Process Properties to get the same command string and same working directory as Eclipse execution.
Here is a PD procedure that might help you identify the problem.
Add the following to your program to identify the differences in the arch and load paths between the two runtime environments. Investigate any differences in path/arch.
System.out.println(System.getProperty("java.library.path"));
System.out.println(System.getProperty("sun.arch.data.model"));
You can use the dumpbin.exe utility to identify the dependencies needed by the DLL that is being loaded.
Make sure the dependencies exist.
Example usage:
C:> dumpbin /imports your.dll
Dump of file your.dll
File Type: DLL
Section contains the following imports:
**KERNEL32.dll**
You can use the where.exe command to find the location of the dependencies.
Example usage:
C:>where KERNEL32.dll
C:\Windows\System32\kernel32.dll
If you see:
C:>where KERNEL32.dll
INFO: Could not find files for the given pattern(s)
Investigate why the dependent DLL is not on the path.
You can use the dumpbin.exe command to check 64bit vs 32bit.
Example:
C:>dumpbin /headers yourd.dll
Dump of file yourd.dll
PE signature found
File Type: DLL
FILE HEADER VALUES
14C machine (x86) <-- 32bit DLL
C:>dumpbin /headers yourd.dll
Dump of file yourd.dll
PE signature found
File Type: DLL
FILE HEADER VALUES
8664 machine (x64) <-- 64bit DLL
Investigate any 32bit vs 64bit mismatches between main/dependent. If your JVM is 32bit, you need to use 32bit DLLs. If your JVM is 64bit, you need to use 64bit DLLs. ( It is okay to run a 32bit JVM on a 64bit OS but the JNI DLLs must be 32bit ( DLLs match the JVM not the OS ).
I have installed Java 1.7.0_45 on Mac OS X 10.6.8 using Pacifist [http://www.charlessoft.com/] however I am unable to run a jar file which I have downloaded. The jar file is a threaded application.
The error message I am getting is:
java -jar context.jar
2013-10-31 14:14:41.898 java[330:a07] *** NSInvocation: warning: object 0x109356390 of class 'ThreadUtilities' does not implement methodSignatureForSelector: -- trouble ahead
2013-10-31 14:14:41.900 java[330:a07] *** NSInvocation: warning: object 0x109356390 of class 'ThreadUtilities' does not implement doesNotRecognizeSelector: -- abort
Trace/BPT trap
Is there anyway I can run the jar. I have set the JAVA_HOME path properly and java -version is showing 1.7.0_45 as the version.
The same application works properly on Windows Java 1.7.0_45 and also on Linux Java 1.7.
The web search for the solution and the given keywords return very few results and none of them have any specific solution in it. I am new to mac so I am not fully able to understand the issue.
Alternatively, is there anyway I can run Java from folder in Mac like I can do in windows and Linux by just extracting the Java contents and changing the JAVA_HOME. If that is possible then I should be able to run my JAR.
I had kind of same problem while installing an application through jar file, my Java was not detected by the jar application installer,
Over here I see that one of the method is not accessible, could be a same problem. But I am not very sure of it.
make sure you have rt.jar in your JAVA_HOME/jre/lib/ folder
In case you don't have then you are required to have it through the process of creation of symbolic link.
In the command below replace your_java_version with proper version matching your requirement.
sudo mkdir -p /System/Library/Frameworks/JavaVM.framework/Versions/<your_java_version>/Home/jre/lib
Go into the directory:
cd /System/Library/Frameworks/JavaVM.framework/Versions/<your_java_version>/Home/jre/lib/
Create symbolic link :
sudo ln -s ../../../Classes/classes.jar rt.jar
Hope this solves your problem.
I get the exact same problem with MacOS 10.6.8 and JDK 7. In order to run the jar I had to use the System JRE which is 1.6.x (In my case I wanted to install Squirrel
/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin/java -jar >squirrel-sql-3.6-MACOSX-install.jar