1753539 Members
5300 Online
108795 Solutions
New Discussion юеВ

Re: JNI and 64 bit

 
David Brown_21
New Member

JNI and 64 bit

I have a JNI library that works fine when running the JVM in 32 bit mode.

PA-RISC, HP-UX 11.11, JDK 1.4.2.11
aCC: HP ANSI C++ B3910B A.03.73

I am now trying to create a 64 bit version of the shared library (and invoking java -d64). I added +DA2.0W to the compile statements, and it builds OK, but when I try to run it, I get:

/usr/lib/pa20_64/dld.sl: Unsatisfied code symbol '_main' in load module 'libCCImpl.sl'.

I am testing with the sample code in Programmer's guide for JavaтДв 2 - Using Java 2 JNI on HP-UX.

I build with:
aCC +z +u4 +DA2.0W -c -D_HPUX -DNATIVE -D_POSIX_C_SOURCE=199506L \
-I/usr/java/include -I/usr/java/include/hp-ux \
CCImpl.cpp
aCC -b +DA2.0W -o libCCImpl.sl CCImpl.o \
-lCsup -lstream -lstd

(/usr/java is a symbolic link to /opt/java1.4)

Suggestions? Are there any additional compiler flags I need? Note that the exact same code works fine in 32 bit mode.
2 REPLIES 2
Dennis Handly
Acclaimed Contributor

Re: JNI and 64 bit

>I added +DA2.0W

You should be using +DD64 instead.

>/usr/lib/pa20_64/dld.sl: Unsatisfied code symbol '_main' in load module 'libCCImpl.sl'.

This lib is build improperly. See the rules on
http://www.docs.hp.com/en/7762/5991-4874/otherlangs.htm#callinghpacc

#if !defined(__LP64__) && !defined(__ia64)
_main();
#endif

>aCC -b +DA2.0W -o libCCImpl.sl CCImpl.o -lCsup -lstream -lstd

The aC++ libs are listed in the wrong order:
http://www.docs.hp.com/en/7762/5991-4874/distributing.htm#linking

Were these commands and code incorrect in Programmer's guide for Java?

The lib order seems correct in:
http://www.hp.com/products1/unix/java/infolibrary/prog_guide/JNI_java2.html#native

(I'm asking them to fix the _main issue.)
David Brown_21
New Member

Re: JNI and 64 bit

Thank you Dennis! (and also to Jeff Donsbach and Channing Benson, who have been assisting me on the java-dev mail list)

My code is now working once I #ifdefined the extern declaration of _main & the call to it in Initialize()

I also changed to +DD64 per suggestion from Jeff (so that makefiles are portable across architectures)

As for where I got the incorrect link order, I must have been working with an older version of the documentation. I'm sure that I didn't see the caveat about _main for IA64. When was the documentation last revised? I began work on this project in September, at which time I got 32 bit working, and turned my attention to other platforms (Solaris, Linux & AIX).

I do recall looking at this 3rd party page, which appears to be an excerpt of earlier HP documentation (but in a more readable format) and it contains the link order I used (i.e. I think this is where I got some of the info)

http://www.wiwi.uni-rostock.de/LABOR_NETZ/DOKUS/JDK/hpux/HPUX_JNI.html

(and I realize in hindsight that I should have regarded the HP documentation as primary - but since I don't recall seeing the caveat about _main for IA64 in the HP doc either, wonder if I was looking at an older version of the HP doc?)

(also glad to see HP moving in the direction of compatibility with other platforms, where the _main() statement was not needed - if I had simply tried compiling my code (which was already working on Solaris & Linux) as 64 bit to begin with and not read any documentation, it would have worked!)


Here are excerpts of comments from Jeff & Channing:

"+DD64" is prefered over "+DA2.0W" for compiler flags since
it is portable across architectures and you won't have to change your
Makefiles.

----------------


If you look at the latest documentation on this, you will see a note
that says:

------------------------------------------------------------------------
----
In the above example you can see the additional native method
initialize() simply calls the routine _main(). Since the Java Native
interface does not allow us to call a routine name _main directly we
have to write this wrapper function to allow us to call _main
indirectly. Also note that we need to use initialization extern "C" to
direct the C++ compiler not to perform name mangling on this routine.
The entry point _main is located in the PA-RISC version of the C++
runtime support library libCsup.sl.

Note: As mentioned above the additional initialization step is no longer
necessary with the Itanium version of HP aC++. In fact calling _main
from code compiled by the Itanium version of HP aC++ will result in
_main being an unresolved symbol.
------------------------------------------------------------------------
----

Now, I don't know if that is also the case for 64-bit PA-RISC, but I do
notice that the version of libCsup.sl in /usr/lib has _main defined, but
the one in /usr/lib/pa20_64 does not.....

Try commenting out the extern declaration of _main as well as the call
to it from initialize.....

Anyone out there know how 64-bit PA JNI is supposed to take care of
static constructors?

-- Chan