When attempting to execute JAVA (version 1.4.2_05) on a linux machine, from a no
n-standard pathname, some of the runtime shared libraries cannot be found. From a trace of the system commands, JAVA attempts to find the libjava.so by using th
e ?/proc/self/exe? to find the pathname of the library. This method does not wo
rk in conjunction with IBM/Rational ClearCase.

Customers who are developing software need to be able to recreate previous versi
ons of software, so they store copies of compilers, source code and versions of
JAVA in their source control application (ClearCase). They then execute the stor
ed tools from the alternate pathname that is a clearcase vob. Java is attemptin
g to figure out the pathname where Java is running from to build a pathname for
related libraries. Unfortunately the method Java is using on Linux (using /proc
/self/exe) to find a software library will not always work.

ClearCase gives you the ability to use a pathname along with a version specifier
 to specify a particular version of a file to open. ClearCase translates this p
athname and version specifier into another pathname in the UFS or NFS namespace
which is filled in with the correct version contents. So for example an open of
 /vobs/jay_unix_java/j2re1.4.2_06/bin/java with version 3 specified, might actua
lly open /home/jay/jay_java.vbs/c/cdft/9/22/1cf5f8ff188811d985e1000c29844b01 whi
ch is a UFS file that contains the correct content for version 3 of j2re1.4.2_06
/bin/java (through the magic of ClearCase).

JAVA needs to be more flexible and not base it path search on the path of where
it is executed. This issue was found when JAVA was exported into Rational?s Cle
arCase on a linux machine.
 
The linux strace near the failure looks like this:

  getpid() = 4167
rt_sigaction(SIGRTMIN, {0x400399c0, [], 0x4000000}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x40038c90, [], 0x4000000}, NULL, 8) = 0
rt_sigaction(SIGRT_2, {0x40039a10, [], 0x4000000}, NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [RTMIN], NULL, 8) = 0
_sysctl({{CTL_KERN, KERN_VERSION}, 2, 0xbffff50c, 31, (nil), 0}) = 0
brk(0) = 0x8058354
brk(0x8058384) = 0x8058384
brk(0x8059000) = 0x8059000
readlink("/proc/self/exe", "/tmp_mnt/DYN9-34-93-188/usr/vobs/jay_java.vbs/c/cdft
/9/22/1cf5f8ff188811d985e1000c29844b01", 4095) = 90
write(2, "Error: could not find libjava.so"..., 33) = 33
write(2, "Error: could not find Java 2 Run"..., 50) = 50
_exit(2)



Suggestion: Have JAVA look for an environment variable to resolve the pathname
if /proc/self/exe fails.

For comparison, the truss from doing the same thing running Java on Solaris is:

        getustack(0xFFBFF5F4)
        brk(0x00032F08) = 0
        brk(0x00034F08) = 0
        resolvepath("/export/home/vobs/jay_unix_java/j2re1.4.2_06/bin/java", "/e
xport/home/vobs/jay_unix_java/j2re1.4.2_06/bin/java", 1024) = 53
        sysinfo(SI_ARCHITECTURE, "sparc", 12) = 6
        resolvepath("/export/home/vobs/jay_unix_java/j2re1.4.2_06/bin/java", "/e
xport/home/vobs/jay_unix_java/j2re1.4.2_06/bin/java", 1024) = 53
        access("/export/home/vobs/jay_unix_java/j2re1.4.2_06/lib/sparc/libjava.s
o", 0) = 0
        open("/export/home/vobs/jay_unix_java/j2re1.4.2_06/lib/sparc/jvm.cfg", O
_RDONLY) = 3
        fstat64(3, 0xFFBFE690) = 0
        brk(0x00034F08) = 0
###@###.### 11/2/04 04:37 GMT