JNI java.lang.UnsatisfiedLinkError loading shared library

[Quy Viet Le]

Hi Everyone,

I am currently trying to get Java to communicate with a C wrapper that communicates with Fortran libraries. I’m using aCC to create the shared library, C to compile the C functions, and f90 to compile the Fortran functions/subroutines. This is all done on the PA-RISC HPUX Version 11.11.

/opt/fortran90/bin/f90 -c +A +fltconst_strict +fp_exception +FPVZODI +nosignedzero +ppu +U77 +W404,441 -Wl,+n +Z +DAportable +DS2.0 -g +noobjdebug +implicit_none *.f

/usr/bin/cc -c -Aa +e +u4 +Z -c -mt -C -DHPUX_CC -D_HPUX_SOURCE -I. +DAportable +DS2.0 -g +noobjdebug *.c

/opt/aCC/bin/aCC –b –o libapt.sl *.o -L/opt/fortran90/lib/pa2.0 -lF90 -lisamstub -lstd -lstream -lCsup -lm -lc –lcl

Once I have my shared library, I then attempt to load the shared library in my Java application.

public class temp {
static { System.loadLibrary(“apt”); }
public static native void initialize();
public static native void someFunction();
}

javac -sourcepath src temp -d bin
javah -jni -classpath bin temp

I create a wrapper.c file based off the header file generated by javah :

#include "temp.h"

extern void someFortranFunction();
extern void _main();

JNIEXPORT
void JNICALL Java_temp_initialize
(JNIEnv * env, jclass cls) {
_main();
}

JNIEXPORT
void JNICALL Java_temp_someFunction();
(JNIEnv * env, jclass cls) {
someFortranFunction();
}

When I run the application in a java main class file

temp.initialize();
temp.someFunction();

I get the following error:

Exception in thread "main" java.lang.UnsatisfiedLinkError: ./libapt.sl: Exec format error
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1776)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1676)
at java.lang.Runtime.loadLibrary0(Runtime.java:822)
at java.lang.System.loadLibrary(System.java:992)
at temp.(temp.java:10)
*** Error exit code 1

This didn’t give much information in terms of what was unresolved. So I did a test and compiled an C++ executable using the same library:

[Quy Viet Le]

Continuation of the above post:

#include
#include

/**
* Fortran and C subroutines/functions go inside
* the extern "C" block.
*/
extern "C" {
void someFunction();
}

int main() {
someFunction();
return 0;
}

aCC +p +Z +u4 -mt -o main.exe main.cpp libapt.sl â w

The main.exe executes with the expected results producing the correct output. I was baffled, but figured there must be a linking problem somewhere. I next used the linker ld tool to link all object code:

ld -o libapt.sl +vallcompatwarnings *.o -L/opt/fortran90/lib/pa2.0 -lF90 -lisamstub -lstd -lstream -lCsup -lm â lc

I get the following error:

ld: Unsatisfied symbols:
FTN_DTOI$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/cmnprf/untsub.o) (code)
FTN_RTOI$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/fn5lb7/chopr.o) (code)
FTN_DATE (first referenced in /project/aero/swdev/perf/home.quy/libtest/bcslib/bcslib_hpux.o) (code)
FTN_EXP$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/atmos/atmoset.o) (code)
FTN_AINT$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/fn5lb7/chopr.o) (code)
FTN_ACOS$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/math/dbtoll.o) (code)
FTN_DSIN$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/math/lltodb.o) (code)
__F90_F_OPEN (first referenced in /project/aero/swdev/perf/home.quy/libtest/fn5lb7/calluip.o) (code)
FTN_RTOR$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/atmos/atmos.o) (code)
FTN_TAN$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/skew/skerpwa.o) (code)
F90_LGT (first referenced in /project/aero/swdev/perf/home.quy/libtest/cmnprf/verstat.o) (code)
FTN_TIME (first referenced in /project/aero/swdev/perf/home.quy/libtest/bcslib/bcslib_hpux.o) (code)
GETENV (first referenced in /project/aero/swdev/perf/home.quy/libtest/fn5lb7/calluip.o) (code)
FTN_COS$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/hstbls/pridrgx.o) (code)
FTN_ATAN$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/skew/skerpwa.o) (code)
Ftn_getarg (first referenced in /project/aero/swdev/perf/home.quy/libtest/fn5lb7/argval.o) (code)
__F90_START_IO (first referenced in /project/aero/swdev/perf/home.quy/libtest/atmos/atmos_bsp.o) (code)
FTN_300_IARGC (first referenced in /project/aero/swdev/perf/home.quy/libtest/fn5lb7/argval.o) (code)
__F90_F_REW (first referenced in /project/aero/swdev/perf/home.quy/libtest/fn5lb7/flcntl.o) (code)
__F90_F_STOP (first referenced in /project/aero/swdev/perf/home.quy/libtest/retlib/rndeck.o) (code)
F90_LLT (first referenced in /project/aero/swdev/perf/home.quy/libtest/cmnprf/verstat.o) (code)
F90_LLE (first referenced in /project/aero/swdev/perf/home.quy/libtest/fn5lb7/chrltr.o) (code)
FTN_ALOG$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/atmos/nonstd.o) (code)
FTN_SIN$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/lvl1/dsder3.o) (code)
__F90_F_CLOSE (first referenced in /project/aero/swdev/perf/home.quy/libtest/fn5lb7/calluip.o) (code)
__F90_F_INQUIRE (first referenced in /project/aero/swdev/perf/home.quy/libtest/fn5lb7/calluip.o) (code)
FTN_DINT$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/fn5lb7/chopd.o) (code)
FTN_DCOS$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/math/lltodb.o) (code)
FTN_ASIN$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/lvl1/dsder1.o) (code)
__F90_F_BACK (first referenced in /project/aero/swdev/perf/home.quy/libtest/fn5lb7/unwind.o) (code)
FTN_DACOS$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/math/lltodb.o) (code)
FTN_ALOG10$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/atmos/dltohp.o) (code)
FTN_ATAN2$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/math/dhdx.o) (code)
FTN_AMOD$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/math/hftohm.o) (code)
__F90_DO_IO_ITEM (first referenced in /project/aero/swdev/perf/home.quy/libtest/atmos/atmos_bsp.o) (code)
U_STACK_TRACE (first referenced in /opt/fortran90/lib/pa2.0/libF90.a(alloc.o)) (code)
FTN_DTOD$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/cmnprf/untsub.o) (code)
FTN_DLOG10$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/bcslib/bcslib_hpux.o) (code)
__F90_END_IO (first referenced in /project/aero/swdev/perf/home.quy/libtest/atmos/atmos_bsp.o) (code)
FTN_ITOI (first referenced in /project/aero/swdev/perf/home.quy/libtest/fn5lb7/chopi.o) (code)
__F90_PARSE_FMT (first referenced in /project/aero/swdev/perf/home.quy/libtest/fn5lb7/aformt.o) (code)
FTN_FLUSH (first referenced in /project/aero/swdev/perf/home.quy/libtest/fn5lb7/flflush.o) (code)
ld: Unsatisfied symbols:
$global$ (data) (probably missing /usr/ccs/lib/crt0.o)
*** Error exit code 1

So it seems that the ld tool canâ t resolve all the Fortran intrinsic functions/subroutines. This is weird because Iâ ve included them with the â lF90 which should look in the /usr/lib directory for libF90.sl as indicated by the aCC/ld documentation.

Iâ ve also checked the libF90.sl tool to see if these symbols are included in that shared library using the â nmâ tool. The shared library does indeed contain all of these symbols.

Iâ m wondering if there is something that I missed in my steps. I am pretty much stuck and have exhausted the possibilities I can think of. Any help would be greatly appreciated. Thank you for taking the time to read this long post and helping.

-Quy

[Quy Viet Le]

The above post seems to have some errors. I've reposted the above post with the correct formatting:

#include
#include

/**
* Fortran and C subroutines/functions go inside
* the extern "C" block.
*/
extern "C" {
void someFunction();
}

int main() {
someFunction();
return 0;
}

aCC +p +Z +u4 -mt -o main.exe main.cpp libapt.sl â w

The main.exe executes with the expected results producing the correct output. I was baffled, but figured there must be a linking problem somewhere. I next used the linker ld tool to link all object code:

ld -o libapt.sl +vallcompatwarnings *.o -L/opt/fortran90/lib/pa2.0 -lF90 -lisamstub -lstd -lstream -lCsup -lm â lc

I get the following error:

ld: Unsatisfied symbols:
FTN_DTOI$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/cmnprf/untsub.o) (code)
FTN_RTOI$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/fn5lb7/chopr.o) (code)
FTN_DATE (first referenced in /project/aero/swdev/perf/home.quy/libtest/bcslib/bcslib_hpux.o) (code)
FTN_EXP$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/atmos/atmoset.o) (code)
FTN_AINT$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/fn5lb7/chopr.o) (code)
FTN_ACOS$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/math/dbtoll.o) (code)
FTN_DSIN$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/math/lltodb.o) (code)
__F90_F_OPEN (first referenced in /project/aero/swdev/perf/home.quy/libtest/fn5lb7/calluip.o) (code)
FTN_RTOR$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/atmos/atmos.o) (code)
FTN_TAN$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/skew/skerpwa.o) (code)
F90_LGT (first referenced in /project/aero/swdev/perf/home.quy/libtest/cmnprf/verstat.o) (code)
FTN_TIME (first referenced in /project/aero/swdev/perf/home.quy/libtest/bcslib/bcslib_hpux.o) (code)
GETENV (first referenced in /project/aero/swdev/perf/home.quy/libtest/fn5lb7/calluip.o) (code)
FTN_COS$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/hstbls/pridrgx.o) (code)
FTN_ATAN$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/skew/skerpwa.o) (code)
Ftn_getarg (first referenced in /project/aero/swdev/perf/home.quy/libtest/fn5lb7/argval.o) (code)
__F90_START_IO (first referenced in /project/aero/swdev/perf/home.quy/libtest/atmos/atmos_bsp.o) (code)
FTN_300_IARGC (first referenced in /project/aero/swdev/perf/home.quy/libtest/fn5lb7/argval.o) (code)
__F90_F_REW (first referenced in /project/aero/swdev/perf/home.quy/libtest/fn5lb7/flcntl.o) (code)
__F90_F_STOP (first referenced in /project/aero/swdev/perf/home.quy/libtest/retlib/rndeck.o) (code)
F90_LLT (first referenced in /project/aero/swdev/perf/home.quy/libtest/cmnprf/verstat.o) (code)
F90_LLE (first referenced in /project/aero/swdev/perf/home.quy/libtest/fn5lb7/chrltr.o) (code)
FTN_ALOG$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/atmos/nonstd.o) (code)
FTN_SIN$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/lvl1/dsder3.o) (code)
__F90_F_CLOSE (first referenced in /project/aero/swdev/perf/home.quy/libtest/fn5lb7/calluip.o) (code)
__F90_F_INQUIRE (first referenced in /project/aero/swdev/perf/home.quy/libtest/fn5lb7/calluip.o) (code)
FTN_DINT$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/fn5lb7/chopd.o) (code)
FTN_DCOS$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/math/lltodb.o) (code)
FTN_ASIN$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/lvl1/dsder1.o) (code)
__F90_F_BACK (first referenced in /project/aero/swdev/perf/home.quy/libtest/fn5lb7/unwind.o) (code)
FTN_DACOS$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/math/lltodb.o) (code)
FTN_ALOG10$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/atmos/dltohp.o) (code)
FTN_ATAN2$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/math/dhdx.o) (code)
FTN_AMOD$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/math/hftohm.o) (code)
__F90_DO_IO_ITEM (first referenced in /project/aero/swdev/perf/home.quy/libtest/atmos/atmos_bsp.o) (code)
U_STACK_TRACE (first referenced in /opt/fortran90/lib/pa2.0/libF90.a(alloc.o)) (code)
FTN_DTOD$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/cmnprf/untsub.o) (code)
FTN_DLOG10$ (first referenced in /project/aero/swdev/perf/home.quy/libtest/bcslib/bcslib_hpux.o) (code)
__F90_END_IO (first referenced in /project/aero/swdev/perf/home.quy/libtest/atmos/atmos_bsp.o) (code)
FTN_ITOI (first referenced in /project/aero/swdev/perf/home.quy/libtest/fn5lb7/chopi.o) (code)
__F90_PARSE_FMT (first referenced in /project/aero/swdev/perf/home.quy/libtest/fn5lb7/aformt.o) (code)
FTN_FLUSH (first referenced in /project/aero/swdev/perf/home.quy/libtest/fn5lb7/flflush.o) (code)
ld: Unsatisfied symbols:
$global$ (data) (probably missing /usr/ccs/lib/crt0.o)
*** Error exit code 1

So it seems that the ld tool canâ t resolve all the Fortran intrinsic functions/subroutines. This is weird because Iâ ve included them with the â lF90 which should look in the /usr/lib directory for libF90.sl as indicated by the aCC/ld documentation.

Iâ ve also checked the libF90.sl tool to see if these symbols are included in that shared library using the â nmâ tool. The shared library does indeed contain all of these symbols.

Iâ m wondering if there is something that I missed in my steps. I am pretty much stuck and have exhausted the possibilities I can think of. Any help would be greatly appreciated. Thank you for taking the time to read this long post and helping.

-Quy

[Dennis Handly]

>I'm using aCC to create the shared library,

Why? If you have no aC++ objects, you should use cc or f90 to link.

>java.lang.UnsatisfiedLinkError: ./libapt.sl: Exec format error
>This didn't give much information in terms of what was unresolved.

Is everything compiled with the right bit size, all 32 bit?

>ld -o libapt.sl +vallcompatwarnings *.o -L/opt/fortran90/lib/pa2.0 -lF90 -lisamstub -lstd -lstream -lCsup -lm -lc

You can't use ld directly to link aC++ load modules. You should NOT be adding -lc to any shlib!

>I get the following error:
>ld: Unsatisfied symbols: FTN_DTOI$

You forgot the F90 shlibs.

>This is weird because I've included them with the -lF90 which should look in the /usr/lib directory for libF90.sl as indicated by the aCC/ld documentation.

You need to look at the f90 documentation.
You probably forgot -lcl?

[Quy Viet Le]

Hi Dennis,

Thanks for your time and help. I really appreciate it.

>Why? If you have no aC++ objects, you should use cc or f90 to link.

I am now using the cc compiler to create the shared lib.

>Is everything compiled with the right bit size, all 32 bit?

The system I am compiling on is a 32 bit system, so everything is compiled in 32 bits.

>You can't use ld directly to link aC++ load modules. You should NOT be adding -lc to any shlib!

I've taken off the -lc flag.

>You need to look at the f90 documentation.
You probably forgot -lcl?

I've added -lcl flag, but I'm still getting the same error when loading the shared library.

I've been following the JNI tutorial by HP (http://docs.hp.com/en/JAVAPROGUIDE/JNI_java2.html#java_native_c) adding all the flags they've specified, but I'm still getting the unsatisfied link error from the JVM.

Like I said before, if I compile a main c/c++ program loading the same shared library and calling the same subroutines/functions, everything will run smoothly.

Any help would be greatly appreciated.

[Dennis Handly]

>The system I am compiling on is a 32 bit system, so everything is compiled in 32 bits.

Are you sure it is 32 bit? Only very old hardware doesn't support 64 bit.

>I've added -lcl flag, but I'm still getting the same error when loading the shared library.

The same error but probably not the same unsats?

>if I compile a main C/C++ program loading the same shared library and calling the same subroutines/functions, everything will run smoothly.

How are you loading it?
For dlopen(3) you might want to use RTLD_NOW to check for missing functions.

[Quy Viet Le]

>Are you sure it is 32 bit? Only very old hardware doesn't support 64 bit.

You are right. The system is 64 bit. I verified this through executing the following commands:

getconf KERNEL_BITS
64

and

file /stand/vmunix
/stand/vmunix: ELF-64 executable object file - PA-RISC 2.0 (LP64)

For kicks, I also executed the file command on my shared library

file libapt.sl
libapt.sl: PA-RISC2.0 shared library -not stripped

I also ran the file program through some of the object files that make up the shared library

file initl1.o
initl1.o: PA-RISC1.1 relocatable object

Will this cause a big problem mixing PA-RISC1.1 relocatable objects in a PA-RISC2.0 shared library? I'm very new at this and apologize in advance for any dumb questions I might ask.

Could this bit a mixing problem where I'm compiling in 32 bits but attempting to load it in a 64 bit program? How do I ensure that I am compiling Fortran and C subroutines/functions in 32 bits and that the javac compiler is also compiling in 32 bits?




>The same error but probably not the same unsats?

The problem with the Java error message is that it doesn't tell what is unsatisified. The only output I get when loading the shared library is

Exception in thread "main" java.lang.UnsatisfiedLinkError: /project/aero/swdev/perf/home.quy/j355/libapt.sl: Exec format error
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1776)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1676)
at java.lang.Runtime.loadLibrary0(Runtime.java:822)
at java.lang.System.loadLibrary(System.java:992)
at com.j355.J355.(J355.java:10)
*** Error exit code 1

Stop.


>How are you loading it?
>For dlopen(3) you might want to use RTLD_NOW to check for missing functions.

I will look this up see what I can do with it.

Thanks Dennis for your help.

[Dennis Handly]

>Will this cause a big problem mixing PA-RISC1.1 relocatable objects in a PA-RISC2.0 shared library?

No, you can mix and match these. You'll get more performance with PA2.0 objects.

>Could this be a mixing problem where I'm compiling in 32 bits but attempting to load it in a 64 bit program?

I was thinking that.

>How do I ensure that I am compiling Fortran and C subroutines/functions in 32 bits and that the javac compiler is also compiling in 32 bits?

The default is 32. So unless you use +DD64 or -d64 for java, it should be 32 bit.

>The problem with the Java error message is that it doesn't tell what is unsatisfied.

Yes I noticed that. But with my simple test case it does print the symbol.

>Exception in thread "main" java.lang.UnsatisfiedLinkError: /project/aero/swdev/perf/home.quy/j355/libapt.sl: Exec format error

This is an unhelpful catch all message. It could be related to bad highwater marks but trying to track that down in the past has been near impossible.
I also thought it could be due to the wrong bitness.

I suppose you could use tusc to see what dld is trying to open before it aborts?

tusc -fp -ea -o tusc.out java ...

The attach tusc.out.

[Quy Viet Le]

Here's the tusc.out file you requested.

Thanks for your help.

-Quy

[Dennis Handly · Accepted solution]

>Here's the tusc.out file you requested.

This shows that /project/aero/swdev/perf/home.quy/j355/libapt.sl was opened, mmap and immediately munmap. And dlopen? returned that error.

Do you have the latest linker patches installed? If you do, you probably have to talk to the Response Center to get a debugging dld.sl so that you have a better idea why you have that error.

So other similar threads:
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1306470
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1292004
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1252481
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1115429