How to statically link C run-time libraries?

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

[John Reagan]

One or the other.  Whatever is in the manual.

My point was that for C/C++ applications, you have to do something at compile-time AND at link-time.  For other languages, you can just redefine one of the *$LIBRARY logicals to point to older files and link.

So you can easily compile on V8.4 with the right __VMS_VER and __CRTL_VER, and link against the older [SYSLIB] and then take the .EXE back to V8.3.