Wasting disk space with PA_RISC1.1 code for Java2 1.3

[Matthias Habl]

The Java2 Software Development Kit 1.3.1.05 bundle (part no. B9788AA)
contains each binary as a PA_RISC1.1 and PA_RISC2.0 version,
subdivided into different filesets. For example the dynamic library
'libjava.sl' can be found in the filesets 'Jre.JRE-PA11' and
'Jre.JRE-PA20'. Because the PA_RISC1.1 filesets take a lot of disk
space (22.6 Mbytes) and I'm using a PA_RISC2.0 machine I tried to
remove the unnecessary filesets with the PA_RISC1.1 code, but this
wasn't successful.

$ /opt/java1.3/bin/java -version
java version "1.3.1.05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1.05-020425-12:07)
Java HotSpot(TM) Server VM (build 1.3.1 1.3.1.05-JPSE_1.3.1.05_20020425 PA2.0, mixed mode)

# -> O.k. java works and the PA2.0 version is used.
# I'm "removing" the PA_RISC1.1 libraries with the following command:

$ mv /opt/java1.3/jre/lib/PA_RISC /opt/java1.3/jre/lib/PA_RISC-obsolete

# Now java doesn't work any more:

$ /opt/java1.3/bin/java -version
Error: could not find libjava.sl
Error: could not find Java 2 Runtime Environment.

# But the PA_RISC2.0 'libjava.sl' still exists:
-r-xr-xr-x 1 bin bin 290816 Apr 25 22:40 /opt/java1.3/jre/lib/PA_RISC2.0/libjava.sl

# I didn't understand this, so I called the '.java_wrapper' ksh(1) script
# with an debugging option:

$ /bin/ksh -xp /opt/java1.3/bin/java -version

(... output is shorted)
+ vmproc=PA_RISC2.0
+ SHLIB_PATH=/opt/java1.3/bin/../jre/lib/PA_RISC2.0/native_threads: /opt/java1.3/bin/../jre/lib/PA_RISC2.0/server: /opt/java1.3/bin/../jre/lib/PA_RISC2.0:
+ export SHLIB_PATH
+ XFILESEARCHPATH=/opt/java1.3/bin/../jre/lib/locale/%L/%T/%N%S:
+ export XFILESEARCHPATH
+ prog=/opt/java1.3/bin/../bin/PA_RISC2.0/native_threads/java
+ [ -x /opt/java1.3/bin/../bin/PA_RISC2.0/native_threads/java ]
+ exec /opt/java1.3/bin/../bin/PA_RISC2.0/native_threads/java -version
Error: could not find libjava.sl
Error: could not find Java 2 Runtime Environment.

I still don't understand this behavior. The wrapper script
/opt/java1.3/bin/.java_wrapper executes the PA_RISC2.0 'java' program
and the environment variable SHLIB_PATH contains exactly the directory
/opt/java1.3/bin/../jre/lib/PA_RISC2.0 where the PA_RISC2.0 library
'libjava.sl' resides.

Can anyone explain me this: After installing the complete SDK java
uses PA_RISC2.0/libjava.sl, which I tested by looking at the access
time ('ls -lu ...'). But when I'm removing PA_RISC/libjava.sl,
i.e. the PA11 version, java doesn't work and can't find
PA_RISC2.0/libjava.sl any more.

Regards, Matthias

[Duncan Edmonstone]

This is indeed very strange!

Can you post the output of 'chatr java' and 'chatr libjava.sl' for the two PA_RISC2.0 binaries?

From this we can ate least figure out what libraries both are attempting to load...

HTH

Duncan

[Tim D Fulford]

Make sure that the filkes in question are not hard links to each other. Sometimes only one binary is shipped but hard linked to a different name e.g. compress

ls -li /usr/bin/*compress
3480 -r-xr-xr-x 3 bin bin 36864 Sep 29 1999 /usr/bin/compress
3480 -r-xr-xr-x 3 bin bin 36864 Sep 29 1999 /usr/bin/uncompress

the i shows the i-node.

Just a thought

Tim

[Tim D Fulford]

Matthias

OK. Other than the suggestions above I have no idea. But as an experiment you could try copying files like libjava.sl back into the original directory structure & seeing if this works.

Otherwise I would just forget about saving the disk space. :-(

Tim

[Duncan Edmonstone · Accepted solution]

Matthias,

The odd thing here is that the chatr indicates that libjava.sl isn't loaded at run-time, which means it must be explicitly loaded by a call to dlopen somewhere in the source code - we know this is the case cos the error message you get isn't the usual one when a shared library can't be loaded (this usually mentions dld).

I tried the following :

strings /opt/java1.3/jre/bin/PA_RISC2.0/native_threads/java | grep libjava

and it returned the following:

%s/lib/%s/libjava.sl
%s/jre/lib/%s/libjava.sl

Which seems to bear this out... one can only assume that something in the source code is trying to open the wrong shared library - I'm not sure how to take this further though...

Can tusc trace PARISC2.0 binaries? if so, perhaps you should download and install that - maybe then you can get a handle on whats going on.

Sorry I can't help more

Duncan

[Matthias Habl]

With your help I found an explanation. Using tusc(1) (no problem to
trace PA_RISC2.0 binaries) it revealed, that 'java' is indeed reading the
libraries itself, as Duncan has suspected:

stat("/opt/java1.3/bin/../jre/lib/PA_RISC2.0/libjava.sl", 0x7f7f2868) = 0
open("/opt/java1.3/bin/../jre/lib/PA_RISC2.0/libjava.sl", O_RDONLY, 03) = 3
fstat(3, 0x7f7f2930) ..................................... = 0
read(3, "0214010e0512@ \0\0\0\0\0\0\0\0\0".., 128) ....... = 128
lseek(3, 128, SEEK_SET) .................................. = 128
read(3, "10\0\004\0\0\0( \002beec\0\010\0".., 48) ........ = 48
read(3, "80\0\0\v\0\0\004\0\0\0\0", 12) .................. = 12
lseek(3, 90112, SEEK_SET) ................................ = 90112
read(3, "058cy 10\0\001e0\0\012fc\0\0\005".., 112) ....... = 112
mmap(NULL, 180224, PROT_READ|PROT_EXEC, MAP_SHARED|MAP_SHLIB, 3, 0x16000) ERR#12 ENOMEM
close(3) ................................................. = 0


The problem - and I think this is POOR PROGRAMMING of the java binary -
is, that the existence of the PA_RISC1.1 libjava.sl is used for the
decision whether the Java2 environment is installed or not. The same
problem appears in the case of libjvm.sl. Here is the protocol:


$ mv -i /opt/java1.3/jre/lib/PA_RISC /opt/java1.3/jre/lib/PA_RISC-obsolete
$ java -version
Error: could not find libjava.sl
Error: could not find Java 2 Runtime Environment.

### I'm making a variation of Tim's proposal:

$ mkdir /opt/java1.3/jre/lib/PA_RISC
$ cp /dev/null /opt/java1.3/jre/lib/PA_RISC/libjava.sl

$ java -version
Error: could not find a JVM.

### Ok, this was somewhat better. But now:

$ /opt/java1.3/jre/lib/PA_RISC
$ mkdir server
$ cp /dev/null server/libjvm.sl

### And so it works again:

$ java -version
java version "1.3.1.05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1.05-020425-12:07)
Java HotSpot(TM) Server VM (build 1.3.1 1.3.1.05-JPSE_1.3.1.05_20020425 PA2.0, mixed mode)


Thank you very much, I learnt some new powerful commands (chatr,
strings, especially tusc).


Matthias

[Duncan Edmonstone]

Matthias,

Glad this was useful... and a big thankyou to you, cos it looks like your points just crowned me!

I agree - v. poor programming - I wonder whos responsible for this fragment - HP or Sun?

Cheers

Duncan