SYSTEM-F-SHRIDMISMAT with Oracle image on 8.3 IA64

[Glenn Wolf]

I have an application that I distribute to sites as a set of executables. We are porting to IA64 on OpenVMS 8.3. The application uses oracle (10g, version 10.2.0.2.0); the images are linked using the oracle LNPROC command.

The issue is that the images will only run on the system where they were linked. When I move them to a target system (which has all the same OpenVMS and Oracle versions, including patches), I get:
%DCL-W-ACTIMAGE, error activating image LIBCLNTSH
-CLI-E-IMGNAME, image file DSA4500:[ORACLE.LIB32]LIBCLNTSH.SO
-SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image

Using ANAL/Image on the shareable image in question, on the build system I see:
Image name: "LIBCLNTSH"
Global Symbol Table name: "libclntsh"
Image file identification: "V1.0"
Link identification: "Linker I02-31"
Link Date/Time: 27-SEP-2007 16:25:08.34

and

Match Control
Algorithm: EQUAL
Major ID: 9956.
Minor ID: 2876165594.

while on the run system, I see:
Image name: "LIBCLNTSH"
Global Symbol Table name: "libclntsh"
Image file identification: "V1.0"
Link identification: "Linker I02-31"
Link Date/Time: 24-SEP-2007 14:09:39.42

and

Match Control
Algorithm: EQUAL
Major ID: 9954.
Minor ID: 1023564194.

However, using anal/image on the application image, in the Image Activation Information section, Shareable Image list, I see:
Shareable Image List
CMA$OPEN_RTL
(LESS/EQUAL, 4., 5.)
LIBCLNTSH
(EQUAL, 9956., -1418801702.)
DECC$SHR
(LESS/EQUAL, 1., 1.)
CXXL$LANGRTL
(LESS/EQUAL, 1., 1.)

Does the entry for LIBCLNTSH (the problem shareable image) look right?

It looks like there is an issue with the match version for the libclntsh shared library; has this changed for IA64?

In the option files that (I think) are used to link the shareable image, there is no GSMATCH keyword; I think this is the same as on the prior version of oracle we used. Is the default behavior of the linker different with respect to GSMATCH?

Thanks for your help!

Glenn

[Hoff]

Oracle has classically wanted applications to relink in the target environment context; minor differences and ECOs and upgrades have often led to a requirement to relink. (This area has gotten better over the years, but I first hit an Oracle gsmatch error was back about 1984 or so.)

And yes, LIBCLNTSH gsmatch doesn't and it's specified as an equal-only match, so you will get an error here.

The usual trigger for these cases -- assuming this is not fully intentional -- is that somebody forgot to include and to specify a gsmatch when LIBCLNTSH was linked.

[Glenn Wolf]

This application has been around since the mid nineties, anyway (long before I inherited it), and we have never had to link on the execution box.

Looking at the most recent (working) distribution we have (Oracle 8.1.7.3 under OpenVMS 7.3.2 on Alpha), I see that Oracle links their shared library with the "GSMATCH=equal,8,1" qualifier, but they neglect to do that in the 10g/IA64 environment.

Looks like it's time to go off and see the Oracle Oracle.

Thanks for your help, Hoff!

Glenn

[John Gillings]

Glenn,

> When I move them to a target system
>(which has all the same OpenVMS and Oracle
>versions, including patches),

This statement isn't supported by your GSMATCH information. The major IDs and link dates for LIBCLNTSH differ, therefore they are different versions (by definition).

That they're GSMATCH EQUAL with somewhat random IDs suggests the GSMATCH was not specified when the image was linked. I don't know the exact algorithm LINK uses when GSMATCH is omitted, but you should think of it as strictly EQUAL with unique over all time IDs.

This may be an oversight, but it may also be deliberate (intended to lock images down to the system they were linked on).

You need to ask Oracle for guidelines on creating "redistributable" images. It may be that you should distribute the matching LIBCLNTSH (and maybe others?) with your executable image.

[Hein van den Heuvel]

Fwiw, and probably stating the obvious...

1) 2876165594 (unsigned) = -1418801702 (signed)

2) The major and minor ID are a slice from the link time, making them slowly increasing.

3) It's just a number.
In a very recognizable location.
I'd be tempted to PATCH a copy with PATCH/ABSOLUTE or my 'zap' tool or DCL write/update, and just try it. Not that you would want that as a distribution method, but just so you know you could when in a bind.

4) Maybe just do what John says, ship the client-shareable with your distribution, or at least try that... so you know.

Some numbers below.
Hein.

$ x1=2876165594
$ x2=1023564194
$ shwo symb x*
X1 = -1418801702 Hex = AB6ECDDA
X2 = 1023564194 Hex = 3D0259A2
$ Y1 = 9956
$ Y2 = 9954
$ show sym y*
Y1 = 9956 Hex = 000026E4
Y2 = 9954 Hex = 000026E2
DBG> set radix hex
DBG> dep /date 10000="27-SEP-2007 16:25:08.34"
DBG> ex/hex/quad .
0000000000010000: 00A-6E4-AB6EC-C6B40
DBG> dep /date 10000="24-SEP-2007 14:09:39.42"
DBG> ex/hex/quad .
0000000000010000: 00A-6E2-3D025-869C0