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

[Quy Viet Le]

Hi Dennis,

Thanks for your help. The PARISC server I am developing on does not have the latest patches from what the system admin tells me. We're unable to update the servers right now due to a freeze on the system.

As a last resort, I am trying to develop this Java application on our Itanium HPUX servers now since they have more recent patches.

I'm having trouble finding documentation that will link the correct runtime libraries for the Fortran. According to the PARISC aCC mixed language programming section (http://www.docs.hp.com/en/14672/Help/otherlangs.htm#main), it says you should link with the following:

>-L/opt/fortran90/lib/ -lF90 -lisamstub

When on the Itanium, I am unable to find a libamstub.so file. Do I need the libamstub.so shared lib to compile a shared fortran/c++ library on the Itanium or is there a different library that contains the same object files?

Also, I did a quick test on the Itanium. I recompiled all library subroutines/functions and then created the shared library via the following command:

>aCC -b -o libapt.so *.o -lCsup -lstd -lstream -lm -L/opt/fortran90/lib/ -lF90 -lisamstub -I/opt/java/include -I/opt/java/include/hp-ux

The compiler threw a fatal error:

>ld: Can't find library for -lisamstub

After taking that flag out

>aCC -b -o libapt.so *.o -lCsup -lstd -lstream -lm -L/opt/fortran90/lib/ -lF90 -I/opt/java/include -I/opt/java/include/hp-ux

everything compiled fine. I then created a quick main function in C that just calls one of the subroutines:

>#include
>#include
>
>extern void calluip_();
>
>
>
>int main() {
> calluip_();
> return 0;
>}

I compile with the following command:

>/usr/bin/cc -c -c +Z +u4 -mt -Aa +e -C -DHPUX_CC -D_HPUX_SOURCE -I. +DSblended -g +noobjdebug main.c

Once I create the executable

>/usr/bin/cc +Z +u4 -mt -Aa +e -o main.exe main.o libapt.so

the ld complains about what I would guess as to be standard Fortran library subroutines:

>ld: (Warning) Unsatisfied symbol "__F90_START_IO" in file libapt.so
>ld: (Warning) Unsatisfied symbol "_Unwind_SetIP" in file /usr/lib/hpux32/libCsup.so.1
>ld: (Warning) Unsatisfied symbol "_Unwind_SetGR" in file /usr/lib/hpux32/libCsup.so.1
>ld: (Warning) Unsatisfied symbol "_Unwind_GetIP" in file /usr/lib/hpux32/libCsup.so.1
>ld: (Warning) Unsatisfied symbol "_Unwind_GetGR" in file /usr/lib/hpux32/libCsup.so.1
>ld: (Warning) Unsatisfied symbol "err1msg_" in file libapt.so
>ld: (Warning) Unsatisfied symbol "Ftn_getarg" in file libapt.so
>ld: (Warning) Unsatisfied symbol "FTN_TIME" in file libapt.so
>ld: (Warning) Unsatisfied symbol "hs1tbu_" in file libapt.so
>ld: (Warning) Unsatisfied symbol "__F90_F_INQUIRE" in file libapt.so
>ld: (Warning) Unsatisfied symbol "_Unwind_RaiseException" in file /usr/lib/hpux32/libCsup.so.1
>ld: (Warning) Unsatisfied symbol "__F90_F_BACK" in file libapt.so
>ld: (Warning) Unsatisfied symbol "_Unwind_GetRegionStart" in file /usr/lib/hpux32/libCsup.so.1
>ld: (Warning) Unsatisfied symbol "__F90_END_IO" in file libapt.so
>ld: (Warning) Unsatisfied symbol "__F90_PARSE_FMT" in file libapt.so
>ld: (Warning) Unsatisfied symbol "FTN_300_IARGC" in file libapt.so
>ld: (Warning) Unsatisfied symbol "hs2tbu_" in file libapt.so
>ld: (Warning) Unsatisfied symbol "__F90_F_OPEN" in file libapt.so
>ld: (Warning) Unsatisfied symbol "__F90_DO_IO_ITEM" in file libapt.so
>ld: (Warning) Unsatisfied symbol "F90_LGT" in file libapt.so
>ld: (Warning) Unsatisfied symbol "F90_LLE" in file libapt.so
>ld: (Warning) Unsatisfied symbol "F90_LLT" in file libapt.so
>ld: (Warning) Unsatisfied symbol "GETENV" in file libapt.so
>ld: (Warning) Unsatisfied symbol "hssrtn_" in file libapt.so
>ld: (Warning) Unsatisfied symbol "_Unwind_Resume" in file /usr/lib/hpux32/libCsup.so.1
>ld: (Warning) Unsatisfied symbol "chdir_" in file libapt.so
>ld: (Warning) Unsatisfied symbol "system_" in file libapt.so
>ld: (Warning) Unsatisfied symbol "getcwd_" in file libapt.so
>ld: (Warning) Unsatisfied symbol "sleep_" in file libapt.so
>ld: (Warning) Unsatisfied symbol "gtapeng_" in file libapt.so
>ld: (Warning) Unsatisfied symbol "etime_" in file libapt.so
>ld: (Warning) Unsatisfied symbol "__F90_F_STOP" in file libapt.so
>ld: (Warning) Unsatisfied symbol "FTN_FLUSH" in file libapt.so
>ld: (Warning) Unsatisfied symbol "__F90_F_REW" in file libapt.so
>ld: (Warning) Unsatisfied symbol "FTN_DATE" in file libapt.so
>ld: (Warning) Unsatisfied symbol "_Unwind_GetLanguageSpecificData" in file /usr/lib/hpux32/libCsup.so.1
>ld: (Warning) Unsatisfied symbol "hslsqf_" in file libapt.so
>ld: (Warning) Unsatisfied symbol "hslsqs_" in file libapt.so
>ld: (Warning) Unsatisfied symbol "__F90_F_CLOSE" in file libapt.so
>39 warnings.

I run the executable and get the following error:

>/usr/lib/hpux32/dld.so: Unsatisfied code symbol '__F90_START_IO' in load module './libapt.so'.
Killed


Running the file command on the main.exe executable produces the following output:

>main.exe: ELF-32 executable object file - IA64

All of my object files are ELF-32.

Also the Fortran object files were compiled with the following flags:

>f90 -c +Z +A +fltconst_strict +fp_exception +FPVZODI +nosignedzero +ppu +U77 +W404,441 +DSblended
-g +noobjdebug +implicit_none *.f

For my C object files:

>cc -c +Z +u4 -mt -Aa -C -DHPUX_CC -D_HPUX_SOURCE -I. +DSblended -g +noobjdebug *.c

Is there anything you see that I'm doing wrong in my steps? Thanks for your help.

[Dennis Handly]

>I'm having trouble finding documentation that will link the correct runtime libraries for the Fortran. According to the PA aCC mixed language programming section

I'm sorry to say that info is likely out of date and you should look at the Fortran documentation.
That's probably why it was remove from the Integrity version:
http://h21007.www2.hp.com/portal/download/files/unprot/aCxx/Online_Help/otherlangs.htm#callinghpfortran

>I am unable to find a libamstub.so file.

I assume that is no longer needed.

>aCC -b -o libapt.so *.o -lCsup -lstd -lstream -lm -L/opt/fortran90/lib -lF90

You should NOT be using the -AP shlibs. Also you have them in the wrong order:
http://h21007.www2.hp.com/portal/download/files/unprot/aCxx/Online_Help/distributing.htm#linking
-lstd_v2 -lCsup -lunwind -lm
(Also remove -L/opt/fortran90/lib.)

>Unsatisfied symbol "_Unwind_SetIP"

From -lunwind.

Unsatisfied code symbol '__F90_START_IO'

This is in -lIO77 or -lcl.

>cc -c ... -Aa

Any reason you aren't using -AC99? That is the new default for A.06.25.

>Is there anything you see that I'm doing wrong in my steps?

See above for missing -l options.

[Quy Viet Le]

Thanks, Dennis. I found that after looking at the PDF version of the HP Fortran Programmer's Guide, it gave me all the runtime libraries I needed. I was looking at the HTML versions before. Just a note to anyone else looking at this problem, read the PDF documents since they seem to be more up to date.