How to statically link C run-time libraries .

[allin-in-one]

Please let me know how  statically link sharable (i.e. CXXL$LANGRTL, DECC$SHR, LBRSHR, LIBRTL etc)  with executable.

To avoid problems like “-SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image”.

I have tried like

$ LINK/NOSYSSHARE abc,SYS$SHARE:IMAGELIB.OLB/INCLUDE=(CXXL$LANGRTL,DECC$SHR,LBRSHR,LIBRTL),SYS$SHARE:STARLET.OLB/INCLUDE=(CMA$TIS,,CMA$TIS_VEC)

[H.Becker]

I'm a little bit surprised. I would have expected a reply like "Not a very detailed description of anything." :-)

The previous reply mentioned that you can not statically link a shareable image, aka shared library. Usually you can statically link with object libraries. However the file type .OLB is inconsistantly used by VMS. IMAGELIB.OLB is not the object library of modules which make up the shareable images, it is a library of shareable images.

/SYSSHR (default) resolves from all known shareable images, known in the sense that they are elements of the IMAGELIB.OLB (not real elements, but that's not important, here).  /NOSYSSHR is the qualifier you want to try.  But your command says "no" to known shareable images but includes shareable images from IMAGELIB: this will not work as expected.

Check out what's in SYS$SHARE: "$ dir sys$share:.olb". You should be able to link your object modules with the object libraries like DECC$CRTL.OLB, LIBCXXSTD.OLB,  etc. As far as I remember, you may not find all of these libraries on all platforms.

STARLET.OLB is default, except you exclude resolving from it with /NOSYSLIB. As with all libraries, you shouldn't need to /INCLUDE anything, when resolving undefined symbols, what I think you want to do.

Also depending on the platform, you don't need to use CXXLINK: on I64 it is provided just for convenience, because you had to use it on Alpha and you may want to use the same commands/procedures/makefiles.

Yes, a static link with objects can avoid a SHRIDMISMAT at image activation time. Usually this is only a problem if you link a main image with features/functions in a new shareable image and want to run the main image on VMS systems with an old version of that shareable image. If you don't need the new feature, you may want to link with the old version of that shareable image (on the target system or with a copy from the target system; logical names are your friends). But what do I know what your actual problem is and what you are trying to accomplish.

[John Gillings]

Typically SHRIDMISMAT will only occur if you attempt to execute an image on a system with an OpenVMS version earlier than the one on which the image was linked.

The best strategy to avoid this is to link your program on the earliest version of OpenVMS that you want to support, or ship object code and have the installation procedure link the image on the target system.

Even if you can find object code to replace all your shareable images, linking against object code might not work, because you can't link system services or other protected shareable images as object code (the privileged shareable image mechanism is required to do the necessary mode changes to get into privileged modes needed to do system service type stuff). If any of your object code is dependent on later incarnations of system services, you won't be able to move your images to earlier versions of OpenVMS. You'll get a different error, but essentially the same issue.

If you don't have an OpenVMS system running the earliest version you want to run on, it's possible to create a link environment using copies of all the shareable images you depend from the eralier version on and defining logical names to point to them just before linking. Once you've linked against the earlier versions, your image should run without error against later versions.

If none of that makes sense, please fill in details of where you're experienceing this problem. What version was the program linked on, and where are you trying to run it?

[allin-in-one]

Thank you.

I am still not clear about your suggestion. Sorry, I couldn't understand it completely.

My problem is: I am having an application built on IA64 Version V8.4. But the customer system is having Version V8.3.

In the customer system there are no C/C++ Run-times (C/C++ compiler )  installed. So I can't compile my program there. In the customer system getting SHRIDMISMAT at image activation time.

To avoid this problem I want to statically link all the required shareable images for running the application.

Please advise.

[H.Becker]

>>> I am still not clear about your suggestion.

and you are still not clear about the problem.

So this is for VMS on Integrity. There is no OLB for the C run-time library on the system, no matter whether the compiler is installed or not. On the system I checked there is a C compiler installed, but no C++ compiler. So I can't check whether the C++ compiler supplies some OLBs, but I  would assume it doesn't. However there are shareable image for C and C++ on the system, they come with the OS. That is, you don't need to have a compiler installed to link your C/C++ object modules on the target system. Just compile the sources, copy them to the target system and link there. This should work.

>>> But the customer system is having Version V8.3.

Although unrelated to your problem, I think HP recommended to upgrade to V8.3-1H1.

>>> In the customer system getting SHRIDMISMAT at image activation time.

It would be good to see some actual output, here. The GSMATCH for the C run-time library on 8.4 is 1,1. It can't be lower on previous systems. Same for CXXL$011_SHR.EXE.

Ask Google to find SHIML (SHareable IMage dependency List) for I64. This tool will show you all shareable images with requested and actual match control (GSMATCH) also taking logical names into account.  Run it on your develoment system and on the target system. It statically checks your executable and will show where the SHRIDMISMAT comes from.

[allin-in-one]

Thanks for the suggestion.

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

I want my application executable should contain all the required sharable images and run accross all the version of IA64

without any re-compile or re-link.

For this could you please suggest what are the compile/link options I should use.

Thanks.

[H.Becker]

>>> For this could you please suggest what are the compile/link options I should use.

Without knowing some details the answer can only be generic.

Regarding compiation: there is nothing you have to do. Regarding linking: the only option seems to link against the shareable images of the target system(s).

That is, you need the shareable images which cause the SHRIDMISMAT. (That includes, you need to identify these images and from what you disclosed so far, it isn't obvious which shareable images that are.) The "target system" is one with the lowest VMS version you want your application to run on. If your build environment is on a higher VMS version you have to have a local copy of these shareable images. You have to set up logical names to point to these copies at link time. The resulting executable image will have the reference to the shareable image in it together with the match control (GSMATCH) of the local copy.

That's all you need. Image activation with the system supplied shareable images (not your local copies) will succeed on old and current VMS versions (and likely on future ones, so there will be any). So you have to ship just your application image, nothing else.

[allin-in-one]

Thank you.

Getting error with the sharable CXXL$LANGRTL.EXE.

Error is

%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

Could you please let me know how to  set logical names to point to this sharable  at link time.

Thanks.

[H.Becker]

>>> Could you please let me know how to  set logical names to point to this sharable  at link time.

$ define /user CXXL$LANGRTL your$disk:[your.directory]your-CXXL$LANGRTL

$ link ...

[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.

[Dennis Handly]

>OpenVMS is not Unix, Unix is not OpenVMS.

Huh?  HP-UX behaves the same way.  It is forward compatible only.

And for Integrity, the system libs only come in shared form, not archive, so you can't do that.

And even if you could link with archive libs, if they use a new system call, you'll get SIGSYS.

There does appear to be one improvement under OpenVMS, there is a specific error message.

Whereas under HP-UX, it is good luck if you can figure this out.

[H.Becker]

>>> 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).

This is confusing (to me and I don't really understand what you are proposing). You don't need logical names at run time, here. As said before, providing the old shareable image to the linker, seems to be the right way to solve this (regardless where you link: on an old system or in an old environment on a new system). Again, only at link time one needs that old shareable image. There is no need for a logical to run the executable (main) image.

>>> 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.

Hmm, that's not always the case. But that doesn't help the OP with his problem.

>>> 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.

The OP wants to avoid one or a couple of shareable images, that's not a full static link. I wouldn't go so far and claim it wouldn't work. Fact is, there are no .OLBs with the binaries of these shareable images available on this platform.

>>> There does appear to be one improvement under OpenVMS, there is a specific error message. Whereas under HP-UX, it is good luck if you can figure this out.

One?  There are at least two error messages indicating a problem with incompatible shareable images :-)

And yes, it looks like the OP doesn't know enough about linking on VMS to get this problem solved and this forum is not the right place to present or work on such a solution. It looks like it is time to hire someone who can do this. The forum's "Private Messages" may be the way to contact someone for this.

[GuentherF · Accepted solution]

The reason why you hit this bump is to make sure that the functions your application uses on V8.4 are all available on V8.3. E.g. you may call a C RTL functions dealing with TCP/IP on V8.4 which has not been supported under V8.3. Even linking in V8.4 C RTL may not work because the TCP/IP on V8.3 may not support this feature, yet. So that's why what you are asking for is not supported.

If you don't have access to a V8.3 system then maybe your customer can send you a copy of the shareable image(s) in question. Then with the logical name(s) defined link the .EXE as described before.

And as mentioned before you better have your customer's (or supported by your product) version of OpenVMS for testing before you ship!

/Guenther

[John Reagan]

Not to contradict John Gillins, but linking against an older SYS$LIBRARY: directory is quite easy and works.

That is exactly how we link the Pascal compiler.  I simply point SYS$LIBRARY (or ALPHA$LIBRARY or IA64$LIBRARY) to an older copy of SYS$LIBRARY: and do the link.

No funky magic.  No static linking of any libraries.

With C/C++ applications, you have some additional work to do at compile-time by defining the right symbol so the V8.4 header files will only define the symbols available on the V8.3 platform.  Look in the C Run-Time Library reference manual for "Multiple Version Support Macro".  It will guide you to define the __VMS_VER macro.