How to statically link C run-time libraries .

[allin-in-one]

Thank you.

After defining this logical I hoped  CXXL$LANGRTL will be statically linked to the application executable.

If it is statically linked then the size of the executable will be increased in size.

But I didn't see any increase in size of the executable.

Please advise.

[H.Becker]

>>> After defining this logical I hoped  CXXL$LANGRTL will be statically linked to the application executable.

You defined a logical name pointing to a shareable image, using the pointed to shareable image and no longer the shareable image from IMAGELIB for linking your executable image. That's all. There are still shareable images involved. So nothing changed in the size of the image, nothing really changed in the image other than the GSMATCH of that shareable image, which is now the GSMATCH of your local copy, which should be the one from the target system.

You may want to read the fine manual to get a detailed understanding on how the VMS linker works.

[allin-in-one]

Can you tell me one thing,  Is it possible to link sharable images statically ?

If yes how to do it.(i.e. with commands).

[allin-in-one]

Is there anyone understand the problem I have mentioned? If yes, please let me know the solution.

I think the problem is simple. The issue is, whether it is possible or not ? If possible let me know the command.

[abrsvc]

Does anyone understnad your question? Yes.

The answer to the question is NO. You can not end up with a static copy of the shareable image. If you get right down to it, what you are asking defeats the purpose of the shareable image.

Proper use of the shareable images should allow you to generate an image that is compatible with all of the versions you support. You should link on the oldest version. OpenVMS has been the leader in compatability of images. I personally have executable images linked on V1.5 of OpenVMS(VAX) that run under OpenVMS V6 without any problems.

Rather than try to create a standalone image, perhaps you can better describe why you want to go down this path. What is the problem you are trying to solve with this attempt?

Dan

[allin-in-one]

Thanks for your crisp and straight answer.

I have a build system with the newer version of IA64. Where as the custmer is having older version of openVMS IA64.

when ever my application is initiated getting an error as

%DCL-W-ACTIMAGE, error activating image CXXL$LANGRTL -CLI-E-IMGNAME, image file NODE1$DKA0:[SYS0.SYSCOMMON.][SYSLIB]CXXL$LANGRTL.EXE
-SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image

To avoid this problem I wanted to statically link the sharable libraries.

I don't have any  of the oldest version.

Please advise.

[abrsvc]

An alternative is to provide an installation kit that contains the object modules along with a link command to generate an executable image.

Unfortunately, it is a bit dangerous to "trust" an older version without testing. I would think that it is even more dangerous to run a new image, however created, on an older OS. If there are "new features" or bugs fixed in the newer version, it could be invisible to a typical program or the "old" way might be acceptable and consistant in behavior. I would never want to run code built on a newer version of an OS on an older one. The exception to this is the environment where the "old" system is made available to the new one. For example: Linking on V8.4 with pointers to V8.3 shareable images.

Dan

[Dennis Handly]

>To avoid this problem I wanted to statically link the sharable libraries.

As has been mentioned, this is a contradiction in terms.

>I don't have any  of the oldest version.

Then you won't be successful.  Newer bits aren't likely to run on older systems.

[John McL]

You can't statically link .OLB files that are for shareable images (i.e. contain lists of entry points).  These are completely different to .OLB files that contain .OBJ code.

What you can do is define logical names that match the names of shareable images.  The image activator will look for a logical name before it looks for a file with specification SYS$SHARE:xxxxx.EXE, hence careful use of logical names can ensure that non-standard shareable are used (i.e. shareable images that don't reside in SYS$SHARE).

In your case you would need to have copies of a different version of the various C shareable images in some other directory and have logical names point to those.  Those logical names cannot be defined at /SYSTEM level because this would mean that programs apart from yours would access them. The advantage of this technique is that upgrades to OpenVMS might apply changes to the files in SYS$SHARE but would not touch the shareables in a different directory.  The disadvantage is that you would not get the benefit of any enhancements that the upgrade provided.

Personally I'm not convinced that your understanding of OpenVMS is sufficient for you to be working with something so technically complex, so try it at your own risk.  I wonder why the work was undertaken when such a vital issue was unresolved.  Did you just think "someone on the forum will tell me what to do"?

[John Gillings]

Stepping back a bit, I think we need some clarification

OpenVMS is built to preserve UPWARDS compatibility of user mode executable images. That means if you link your program on version X of OpenVMS, it will execute without relinking on all future versions.

However, BACKWARDS compatibility is NOT guaranteed, and will often fail. So, an image linked on version X of OpenVMS will typically NOT execute on lower versions. The Operating System is deliberately setup so the image won't even attempt to execute. It will fail immediately with SHRIDMISMAT or one of a few other similar conditions.

Although there are some tricks to hacking around this deliberate design feature, the bottom line is, an image MUST be linked against the lowest version of OpenVMS on which you want it to run. The reason you can't figure out how to do what you think of as a "static link" is that it wouldn't work even if it were possible. That's just the way OpenVMS works.

> I don't want to link the application on the customer system for various reasons. I think it is not a feasible solution

What you want doesn't really enter into it. If you need your image to run on V8.3, you have to link it on V8.3 (either actual or simulated). Regardless of the presence or absence of compilers, you can always LINK on any OpenVMS system, so that is the simplest and most robust solution to the issue you've presented. Instead of distributing the executable images, distribute your object code and a link procedure.

If you really insist on bringing the mountain to Mahommad, you might be able to copy large chunks of the V8.3 Run Time Libraries onto your V8.4 system and change your build procedure to link against V8.3 RTLs, but unless you really understand how the OpenVMS linker works (and the fact that you're asking this question at all is evidence that you do not), you will almost certainly fail. This forum is not suitable for coaching you on which parts of the RTL you need, as it would require detailed analysis of your code (learn to read a MAP file, see HELP LINK/MAP with /FULL). As well as being tricky to get right, it's not supported, so not the kind of thing responsible people would recommend for production code.

Another supported alternative - build yourself a V8.3 system disk. When you're ready to do a distribution build for this customer, shutdown your V8.4 system, boot from the V8.3 system disk, do your link, then shutdown and reboot to V8.4.

OpenVMS is not Unix, Unix is not OpenVMS. Insisting that one behave like the other is a path to frustration and failure.