| Title: | DIGITAL UNIX (FORMERLY KNOWN AS DEC OSF/1) |
| Notice: | Welcome to the Digital UNIX Conference |
| Moderator: | SMURF::DENHAM |
| Created: | Thu Mar 16 1995 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 10068 |
| Total number of notes: | 35879 |
Hi!,
I'm looking to find an easy work-around to the following situation:
I'm using a Java application (that means to run the Java Virtual
Machine with the Java application name as parameter).
Java allows to invoke a non Java code; a dynamic Java library is
automaticcaly loaded and it calls the C function.
My external code is the link to CICS that is a .so library that
includes the ECI libcicsecico.so. This last one is generated as 32 bit
(option -taso), so the library to be generated must be done with -taso
otherwise I get a linker error.
Now, at execution time I get an error ---> cannot load TASO library.
... for non-Taso executable.....
thanks for any help.
Marino Formia
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 9999.1 | No can do... | NNTPD::"[email protected]" | Christopher Gillett | Fri May 30 1997 10:59 | 30 |
What's happening here is that you are attempting to open a -taso built shared object in the context of a non-taso built program. You can't do this because it doesn't make any sense. Java is built as a normal 64 bit application - we don't use any of the taso switches or other 32 bit hacks. When you create a native method, it gets placed into a shared object. When the native method is invoked, the Java virtual machine attempts to dlopen() the shared object, along with any other shared objects needed to do the work. If dlopen() fails for some reason, then Java calls dlerror() to get the error message produced. In this case dlopen() fails for the reason given (cannot load TASO library foo.so for non-TASO executable) and the game is over. The reason dlopen() declines to open the taso'd shared object is because it doesn't make any sense to do so in the context of a full 64 bit program. Pointers in the non-taso built parts of the program are probably going to be outside the 31 bit range defined for taso'd pointers. Since the taso'd shared object expects the pointer values to be in the range of 31 bits (31 is not a typo), the segfault caused by bad pointer interaction would only be a few instructions away. It only makes sense to have taso'd shared objects when the program which will dlopen() them is also taso'd. Chris [Posted by WWW Notes gateway] | |||||
| 9999.2 | Or, to put it more bluntly: | QUARRY::reeves | Jon Reeves, UNIX compiler group | Fri May 30 1997 13:53 | 2 |
Java is telling you it's time to wean yourself from the TASO crutch and fix your shared library. | |||||