topic Re: How to statically link C run-time libraries? in Operating System - OpenVMS

How to statically link C run-time libraries .

allin-in-one — Sat, 08 Jun 2013 12:41:05 GMT

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)

Re: How to statically link C run-time libraries .

Steven Schweda — Sat, 08 Jun 2013 14:06:25 GMT

Re: How to statically link C run-time libraries .

H.Becker — Sat, 08 Jun 2013 14:49:27 GMT

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.

Re: How to statically link C run-time libraries .

John Gillings — Mon, 10 Jun 2013 02:23:51 GMT

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?

Re: How to statically link C run-time libraries .

allin-in-one — Mon, 10 Jun 2013 05:21:07 GMT

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.

Re: How to statically link C run-time libraries .

H.Becker — Mon, 10 Jun 2013 07:22:30 GMT

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

Re: How to statically link C run-time libraries .

allin-in-one — Mon, 10 Jun 2013 07:36:12 GMT

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.

Re: How to statically link C run-time libraries .

H.Becker — Mon, 10 Jun 2013 09:10:18 GMT

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

Re: How to statically link C run-time libraries .

allin-in-one — Mon, 10 Jun 2013 09:43:06 GMT

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.

Re: How to statically link C run-time libraries .

H.Becker — Mon, 10 Jun 2013 11:39:00 GMT

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

Re: How to statically link C run-time libraries .

allin-in-one — Mon, 10 Jun 2013 12:51:37 GMT

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.

Re: How to statically link C run-time libraries .

H.Becker — Mon, 10 Jun 2013 15:42:32 GMT

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

Re: How to statically link C run-time libraries .

allin-in-one — Mon, 10 Jun 2013 15:55:11 GMT

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

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

Re: How to statically link C run-time libraries .

allin-in-one — Mon, 10 Jun 2013 16:07:27 GMT

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.

Re: How to statically link C run-time libraries .

abrsvc — Mon, 10 Jun 2013 16:41:48 GMT

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

Re: How to statically link C run-time libraries .

allin-in-one — Mon, 10 Jun 2013 16:58:31 GMT

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.

Re: How to statically link C run-time libraries .

abrsvc — Mon, 10 Jun 2013 17:13:22 GMT

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

Re: How to statically link C run-time libraries .

Dennis Handly — Mon, 10 Jun 2013 17:16:13 GMT

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

Re: How to statically link C run-time libraries .

John McL — Mon, 10 Jun 2013 22:48:49 GMT

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"?

Re: How to statically link C run-time libraries .

John Gillings — Tue, 11 Jun 2013 01:44:48 GMT

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.