LIB$FIND_IMAGE_SYMBOL behaviour change in VMS v8.3 ?

[x2084]

> Easy to check, use ANALYZE/IMAGE against your main image to see if the shareable image reference is to the logical name, or the actual name of the image at the time of the link. This would be relevant to your case if the image you're activating with LIB$FIS was also statically linked, and it was important that they map to the same physical image.

This is not clear to me. If you link against DECC$SHR, ANALYZE/IMAGE can't and does not show if the reference is to a logical or to the actual name of the image. Its output needs to be interpreted in the run-time environment. That's what SHIML does.

In the reported case, it looked like that the main image M was linked against the shareable SX by using a logical S and lib$fis was given the logical I, pointing to the shareable SY which was linked against the shareable SX, without using the logical S.

From the image activator's point of view: it activated the images disk:[dir]M.exe, disk:[dir]SX.exe, is requested to activate disk:[dir]SY.exe and looks for the not yet activated sys$share:SX.exe.

To work around the problem, one can define a logical SX pointing to SX. To fix the problem, one should link SY against the shareable SX by using the logical S. As far as I understand, the latter was intended but was not done by mistake.

Also, the symbol to look up is in SY. It added another level of confusion why an error was reported on the "already activated image" SX.

Anyway, the behavior should have been the same on V7: there is no "stricter" in V8.3. (OK, there can always be some "suboptimal behavior" but it's unlikely that there was something changed in this area.)

[John Gillings]

Hartmut,

>This is not clear to me. If you link
>against DECC$SHR, ANALYZE/IMAGE can't and
>does not show if the reference is to a
>logical or to the actual name of the
>image.

Sorry, I was thinking of ancient behaviour that has long since been fixed.

Way back in V4, the linker would resolve logical names pointing to shareable images, so the references in the image pointed to the actual shareable image name, not the logical name used to find it. This was not normally an issue because logical name and image name were the same, but in the case where there might be multiple "plug in" shareable images, it was important to have a "master" image with the correct name to link against. I raised it because Art had a difference in the logical name and image name.

I've just checked on V8.3 and confirmed that the linker uses the logical name from the options file or shareable image library when it writes the references in the image file, regardless of the actual image name it points to.

Under the V4 behaviour, references in the linked image would be ASGMENUY_V13 rather than ASGMENUY.

I believe the solution is stricter use of logical names in all references to shareable images, and a cross check against the linker map file.