/usr/lib/dld.sl: Invalid version for shared library with Java 1.5

[V. Nyga]

Hi,

I've a problem with java 1.5 (Version 5.0.11).
When I try to start an application which requires java 1.5, I get the error message:
'/usr/lib/dld.sl: Invalid version for shared library: /opt/java1.5/jre/lib/PA_RISC2.0/libjava.sl
/usr/lib/dld.sl: Exec format error'

I just installed the latest patch:
PHSS_37517 (ld and linker tools cumulative patch)

Can anybody give me a hint what's wrong?

Volkmar

[James R. Ferguson]

Hi V:

This suggests that either the executable or the hardware wants load a 64-bit library to a 32-bit executable or vice versa.

Regards!

...JRF...

[Torsten.]

May be your java need some patches too?
I would not be surprised.

http://www.hp.com/go/java

http://h18012.www1.hp.com/java/patches/index.html

[V. Nyga]

Thorsten, thanks, you're right.
That I've already done, sorry that I still doesn't give all informations at the beginning - I should know it after 6 years itrc now. :-)

JRF - with 'ldd' I get a:

ldd ProSAP_hpux
=>
/usr/lib/libm.2 => /usr/lib/libm.2
/usr/lib/libc.2 => /usr/lib/libc.2
/usr/lib/libdld.2 => /usr/lib/libdld.2
/usr/lib/libc.2 => /usr/lib/libc.2
/usr/lib/libnsl_s.2 => /usr/lib/libnsl_s.2
/usr/lib/libnsl.1 => /usr/lib/libnsl.1
/usr/lib/libxti.2 => /usr/lib/libxti.2
/usr/lib/dld.sl: Can't open shared library: /eng/kunden/SAP/java1.3/hpux11_pa32/lib/PA_RISC/hotspot/libjvm.sl
/usr/lib/dld.sl: No such file or directory

Hmmm - SAP says I've to use java 1.5, this doesn't correspondent to the lib the developer used(?).

Volkmar

[Dennis Handly]

>dld.sl: Invalid version for shared library:

This means there is something tricky going on with shlib versioning.

>JRF: This suggests that either the executable or the hardware wants load a 64-bit library to a 32-bit executable or vice versa.

That's not what the message means at all. :-)
I'm probably the only person that does know and then I wasn't able to solve it last time:
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1115429
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1151227

The last time I was able to figure this out had a case where there were two different versions of a shlib. One the full version and the other one had stubs.
And the culprit pointed at evil libcl.2!

>SAP says I've to use java 1.5, this doesn't correspondent to the lib the developer used(?).

Possibly.

[V. Nyga]

Hi Dennis!

I'm running parallel now itrc, call at HP and the developer :-)

I've verified the java1.5 installation ...

I've tried odump:
/usr/ccs/bin/odump -slliblist -sllibload ProSAP_hpux
Warning: expected size of dl_header_ext was 80, got 72
This usually is the result of either outdated odump,ld or dld.sl

Shared Library List Table for ProSAP_hpux:

Index Ref IDNRVIL HighWater Name

0 abs .D..... 0 ProE_SAP_CAD_Desktop_Enterprise_hpux11_pa32_2004
1 -l .D...I. 49 /eng/kunden/SAP/java1.3/hpux11_pa32/lib/PA_RISC/libjava.sl
2 -l .D..... 49 /eng/kunden/SAP/java1.3/hpux11_pa32/lib/PA_RISC/hotspot/libjvm.sl
3 -l .D...I. 0 /usr/lib/libnsl.1
4 -l .D...I. 0 /usr/lib/libnsl_s.2
5 -l .D...I. 0 /usr/lib/libc.2
6 -l .D...I. 0 /usr/lib/libm.2


Shared Library Load List for ProSAP_hpux:

Order Name

0 ProSAP_hpux
1 ^ /opt/java1.5/jre/lib/PA_RISC2.0/libjava.sl
2 ^ ^ /opt/java1.5/jre/lib/PA_RISC2.0/libverify.sl
3 ^ ^ ^ /usr/lib/libc.2
4 ^ ^ ^ ^ /usr/lib/libdld.2
5 ^ ^ /usr/lib/libdld.2
6 ^ ^ /usr/lib/libc.2
7 ^ ^ ^ /usr/lib/libdld.2
8 ^ /opt/java1.5/jre/lib/PA_RISC2.0/server/libjvm.sl
9 ^ ^ /usr/lib/libpthread.1
10 ^ ^ /usr/lib/libdld.2
11 ^ ^ /usr/lib/libm.2
12 ^ ^ /usr/lib/librt.2
13 ^ ^ /usr/lib/libcl.2
14 ^ ^ ^ /usr/lib/libdld.2
15 ^ ^ ^ /usr/lib/libisamstub.1
16 ^ ^ /usr/lib/libCsup.2
17 ^ /usr/lib/libnsl.1
18 ^ ^ /usr/lib/libxti.2
19 ^ /usr/lib/libnsl_s.2
20 ^ /usr/lib/libc.2
21 ^ ^ /usr/lib/libdld.2
22 ^ /usr/lib/libm.2

How can I verify this to my java1.5 installation?
(I've set SHLIB_PATH to java1.5 to find the libraries)
Has java1.5 a higher 'HighWater'?
Do I understand everything? 8-(

V.

[V. Nyga]

Oh just for info:
Parallel the developer tries to compile with java1.5 ... I'll let you know.
On the other side - shouldn't java be downside compatible?

V.

[V. Nyga]

one more info:

this exe works with java1.4 and their libraries ... but not the other application

[Dennis Handly · Accepted solution]

>I'm running parallel now itrc, call at HP and the developer :-)

Did you point them to this thread? (They haven't talked to me yet.)

>odump -slliblist -sllibload ProSAP_hpux

You also need to use these options on each of those shlibs (especially the java1.5 shlibs). Also do this again and add -sldlhead.

These are the suspicious shlibs (with that 49):
1 -l .D...I. 49 .../java1.3/.../libjava.sl
2 -l .D..... 49 .../java1.3/.../hotspot/libjvm.sl

From mine:
2 -l .D...I. 49 /usr/lib/libcl.2

-sldlhead output:
Shared Library DL Header for /usr/lib/libcl.2:
version: 93092112
LTptr_offset: 0x00000bc0
highwater_mark: 0000000049 << that 49

>this exe works with java1.4 and their libraries

Can you use the above odump with that 1.4 version to see if the highwater marks are different?

Ok, looking at my system, I see a problem. I have 1.2 and 1.4:
Shared Library DL Header for /opt/java1.2/jre/lib/PA_RISC2.0/libjava.sl:
highwater_mark: 0000000049
Shared Library List Table for .../libjava.sl:
Index Ref IDNRVIL HighWater Name
0 abs I....I. 0 libjava.sl
1 -l .D...I. 0 /usr/lib/libdld.2
2 -l .D...I. 49 ../../lib/PA_RISC2.0/classic/libjvm.sl

Shared Library DL Header for /opt/java1.4/jre/lib/PA_RISC2.0/libjava.sl:
highwater_mark: 0000000000
Shared Library List Table for .../libjava.sl:
Index Ref IDNRVIL HighWater Name
0 abs I....I. 0 libjava.sl
1 -l .D...I. 0 $ORIGIN/libverify.sl
2 -l .D...I. 0 /usr/lib/libdld.2
3 -l .D...I. 0 /usr/lib/libc.2

The libjvm.sl in both cases have a highwater mark of 49.

So the application was developed with 1.3 and you are now trying to run with 1.5.

Since they changed the bill of materials in libjava.sl, you can't use 1.5. You would need a new version of ProSAP_hpux.

[V. Nyga]

Hi Dennis, thanks, yes, I've asked the developer to create a new exe with java1.5.
It seems to work.
I can do more test not until next week.
Can you explain the watermark?
Is a watermark of 49 a no-go?

This is from the new exe:

/usr/ccs/bin/odump -slliblist -sldlhead -sllibload ProSAP_hpux-V3.2.08.292_java15
Warning: expected size of dl_header_ext was 80, got 72
This usually is the result of either outdated odump,ld or dld.sl

Shared Library List Table for ProSAP_hpux-V3.2.08.292_java15:

Index Ref IDNRVIL HighWater Name

0 abs .D..... 0 ProSAP_hpux_hpux11_pa32_2004_java1.5
1 -l .D...I. 0 /eng/kunden/SAP/java1.5/hpux11_pa32/lib/PA_RISC2.0/libjava.sl
2 -l .D..... 49 /eng/kunden/SAP/java1.5/hpux11_pa32/lib/PA_RISC2.0/hotspot/libjvm.sl
3 -l .D...I. 0 /usr/lib/libnsl.1
4 -l .D...I. 0 /usr/lib/libnsl_s.2
5 -l .D...I. 0 /usr/lib/libc.2
6 -l .D...I. 0 /usr/lib/libm.2


Shared Library DL Header for ProSAP_hpux-V3.2.08.292_java15:

version: 93092112
LTptr_offset: 0x00000000
highwater_mark: 0000000000
embedded_path: 0000000000
flags: 0x00000034

Name Location/Value Size
---- -------------- ----
library_list 0x0001ba34 0x00000007
import_list 0x0005c220 0x000018be
export_list 0x00029550 0x000028a4
export_ext 0x00000000 0x000028a4
hash_table 0x0001ba6c 0x000036b9
string_table 0x000ce7dc 0x00026753
dyn. reloc 0x00068810 0x00005197
module_list 0xffffffff 0x00000000
data_lnk_tbl 0x008fcd98 0x000001c7
proc_lnk_tbl 0x008f15e0 0x000016f7
elaborator 0x00000070
initializer 0xffffffff 0x00000000
tdsize 0x00000000
fastbind_list 0x00000000


Shared Library Load List for ProSAP_hpux-V3.2.08.292_java15:

Order Name

0 ProSAP_hpux-V3.2.08.292_java15
1 ^ /opt/java1.5/jre/lib/PA_RISC2.0/libjava.sl
2 ^ ^ /opt/java1.5/jre/lib/PA_RISC2.0/libverify.sl
3 ^ ^ ^ /usr/lib/libc.2
4 ^ ^ ^ ^ /usr/lib/libdld.2
5 ^ ^ /usr/lib/libdld.2
6 ^ ^ /usr/lib/libc.2
7 ^ ^ ^ /usr/lib/libdld.2
8 ^ /opt/java1.5/jre/lib/PA_RISC2.0/server/libjvm.sl
9 ^ ^ /usr/lib/libpthread.1
10 ^ ^ /usr/lib/libdld.2
11 ^ ^ /usr/lib/libm.2
12 ^ ^ /usr/lib/librt.2
13 ^ ^ /usr/lib/libcl.2
14 ^ ^ ^ /usr/lib/libdld.2
15 ^ ^ ^ /usr/lib/libisamstub.1
16 ^ ^ /usr/lib/libCsup.2
17 ^ /usr/lib/libnsl.1
18 ^ ^ /usr/lib/libxti.2
19 ^ /usr/lib/libnsl_s.2
20 ^ /usr/lib/libc.2
21 ^ ^ /usr/lib/libdld.2
22 ^ /usr/lib/libm.2

Hmm - there's still a highwater of 49 - but it works (???)

Wow I've already learned much about library handling this week (without doing any progamming) :-)
But there seems to be still much to learn.

V.

[Dennis Handly]

>Can you explain the watermark? Is a watermark of 49 a no-go?

You want to hear the whole sad story of a fancy smancy idea that goes terribly wrong in the real world? ;-)

On 10.x, there were some incompatible changes in libcl and libc. They used pragma HP_SHLIB_VERSION for intra library versioning, to have both versions of the same function:
http://docs.hp.com/en/7133/pragmas.htm#pragma-SHLIB-VERSION

The largest version sets the highwater mark for the shlib. This is recorded in all load modules that refer to this shlib to make sure the that version or a newer version is used.

Then on 11.0, we gave up on that technology and used the SVR4 inter library versioning, with .1 and now .2.
Unfortunately only libc realized they could remove the old intra library versioning and start over with 0. And libcl was left in the state of having the useless versioning.
And in the case of java, if you change the dependent shlibs around, the highwater mark will be different and dld will reject it.

>there's still a highwater of 49 - but it works (???)

That's because for libjvm.sl, it always had 49. It didn't go from 49 to 0, like libjava.sl.

[V. Nyga]

Solution:
Creation of a new executable ...
Java1.4 was downward compatible - Java1.5 isn't.
V.