Details
P2 Description
The following information was received from Oracle. Please contact
Steve Fleming, Sun MDE, ASAP: 415-336-2274 (x62274).
Oracle Customer Contact: Jamie Wang, 415-506-7000
We encountered a problem with the way javasoft's vm loads shared library. We
have an exe
which loads one shared lib and it in turn loads libjava.so. However, during
execution
some symbols referenced in the libjava.so can't be found.
We found the problem occurrs in file linker_md.c under the runtime for Solaris
platform.
In that file, they're loading libjava.so as an exe with dlopen(0,1) where the
parameter 0
allows the exe symbol space to include itself + one level indirection of the
shared
library. (The manual page for dlopen probablly is a better place for
explaination than
mine here.) This works fine for their exe (ie. java). But, it didn't work for
our
configuration because we have more indirection. We think they ought to change
the way
they load so's because people can't be limited to just have an exe to load
libjava.so. Our
work around solution is to modify their src in function SysInitializLinker()
where the
call to dlopen as dlopen("libjava.so", 1). This worked for us.
Additiona
l information from Oracle (5/21/97):
From uname -a, it shows SunOS 5.4. I believes it is Solaris 2.4 and am using JAE 1.1.1FCS.
However, it's the same result in JDK 1.0.2.
Steve Fleming, Sun MDE, ASAP: 415-336-2274 (x62274).
Oracle Customer Contact: Jamie Wang, 415-506-7000
We encountered a problem with the way javasoft's vm loads shared library. We
have an exe
which loads one shared lib and it in turn loads libjava.so. However, during
execution
some symbols referenced in the libjava.so can't be found.
We found the problem occurrs in file linker_md.c under the runtime for Solaris
platform.
In that file, they're loading libjava.so as an exe with dlopen(0,1) where the
parameter 0
allows the exe symbol space to include itself + one level indirection of the
shared
library. (The manual page for dlopen probablly is a better place for
explaination than
mine here.) This works fine for their exe (ie. java). But, it didn't work for
our
configuration because we have more indirection. We think they ought to change
the way
they load so's because people can't be limited to just have an exe to load
libjava.so. Our
work around solution is to modify their src in function SysInitializLinker()
where the
call to dlopen as dlopen("libjava.so", 1). This worked for us.
Additiona
l information from Oracle (5/21/97):
From uname -a, it shows SunOS 5.4. I believes it is Solaris 2.4 and am using JAE 1.1.1FCS.
However, it's the same result in JDK 1.0.2.