Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

How to statically link C run-time libraries .

 
SOLVED
Go to solution
Highlighted
allin-in-one
Frequent Advisor

How to statically link C run-time libraries .

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)

 

25 REPLIES 25
Steven Schweda
Honored Contributor

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

 
H.Becker
Honored Contributor

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

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
Honored Contributor

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

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?

A crucible of informative mistakes
allin-in-one
Frequent Advisor

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

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
Honored Contributor

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

>>> 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
Frequent Advisor

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

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
Honored Contributor

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

>>> 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
Frequent Advisor

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

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
Honored Contributor

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

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