how to identify a C program used which C library files

[Liu Tina]

an customer will upgrade their system software. They asked: how to identify a C program used which C library files.

Thanks for your great help!
Best Regards,
Tina

[John Gillings]

Tina,

I'm not sure I understand your question.

By "C library files" do you mean run-time libraries, or compile time include files (".h")?

There are various code management utilities that can keep track of dependence trees. Other than using something like that, you may be able to get some of what you need by searching source code for "#include" directives.

>"customer will upgrade their system
>software"

If, by that, you mean they're going to upgrade OpenVMS, then this may be a non-issue. OpenVMS engineering go to fanatical lengths to preserve binary upwards compatibility. You should be able to upgrade the operating system without touching your applications.

If none of the above makes sense, please restate your question. What is the real problem you're trying to solve?

[Liu Tina]

John,

Thanks for your Help!

The customer asked how to identify an C program used which C run-time libraries files and used which compile time include files (".h")under VMS.

And the other question is the customer application systems will be upgrade from V8.3 to VMS V8.3-1H1. The customer hope all of their programes were wrote by C could be running stable without re-comppile under VMS V8.3-1H1. Could you conform this?

Thanks for your great help!
Best Regards,
Tina

[Joseph Huber_1 · Accepted solution]

I don't know which code management (like VMS DECset) has tools to list use of header files,
but one possibility in VMS is the use of MMS/GENERATE:
MMS/GENERATE src1,src2,...
will list for each srcn file the dependencies like

 1]MMS$OLB.OLB(TERMIOS_VMS=TERMIOS_VMS.OBJ) depends_on -
TERMIOS_VMS.C - ,ALPHA$LIBRARY:DECC$RTLDEF.TLB(DESCRIP=DESCRIP.H) - ,ALPHA$LIBRARY:DECC$RTLDEF.TLB(STDLIB=STDLIB.H) -
 1] ,ALPHA$LIBRARY:SYS$STARLET_C.TLB(TTDEF=TTDEF.H) -
,SYS$LIBRARY:TERMIOS.H -
Â
Together with some filter script or a simple search would get the list of included header files and their locations.

Now the header files say nothing about the libraries (object or shareable) to resolve the symbols referenced in the headers like the standard ones (CRTL,FORRTL,starlet,...).
To know which libraries are referenced, You need to LINK/MAP/CROSS. At the beginning of the .MAP file there is a list of all object modules,libraries, and shared images linked.

[Liu Tina]

Joseph,

Thanks for your help!

For you said: "To know which libraries are referenced, You need to LINK/MAP/CROSS. At the beginning of the .MAP file there is a list of all object modules,libraries, and shared images linked".

For these huge C programs come from vender several years ago. If there is any way to find which libraries are referenced at VMS?

Thanks for your help again!
Tina

[Joseph Huber_1]

If You are making executables, then the above mentioned .MAP output files contain the list.

If You have an executable, and want to know which libraries are referenced, then do a
ANALYZE/IMAGE name.exe
But analuze/image only can list the shared libraries (sys$share:.EXE) referenced, not the statically linked libraries (.OLB, object libraries). The executable bears no info about where object-modules came from.

[abrsvc]

It remains unclear what the customer/client wants to know. You are asking relatively detailed questions that don't seem to be what you really want to know. It like asking what species of tree exist in a forest when the real question is how long will it take to cut down the trees.

That being said, what is the real issue here? Upgrading from V8.3 to V8.3-1h1 should be a non-issue. If the "programs" mentioned are an application that does not involve direct control of hardware, it is unlikely that any problem will arise. If you have the sources, a compile/link/run test can be done. Without the source, runtime testing will confirm that all is well.

If the concern is that a referenced library will not work, then there should be an idea of what library will potentially fail. Asking about the ".h" files suggests that the sources are available. If so, then a check of the LINK command, its command qualifiers, and any referenced options files should get you the list of libraries.

As stated earlier, an ANAL/IMAGE will get you the "linked" library references.

Perhaps a step back to describe the ultimate goal will be helpful for us to provide you with more assistance.

Dan

[Hoff]

This is a port from OpenVMS Alpha V8.3 to OpenVMS I64, if I'm guessing correctly?

I'd suggest transferring these folks over to HP services for assistance with the port (or check with David Tan or another OpenVMS ambassador for assistance), or out to an outside vendor that can provide the necessary experience and assistance with the OpenVMS platform port.

And irrespective of any transfer to another entity, I'd also suggest to the customer that the porting manual be the starting point of the effort, if they've not already seen that document.

The porting manual is here:

http://h71000.www7.hp.com/doc/82final/6673/ba442-90001.PDF

The baseline pieces involved with porting C are (usually) straightforward, and there's the aforementioned porting manual available in the documentation set. Do crank up the diagnostics above the defaults to (mayhap) the /WARNINGS QUESTCODE setting, and fix any errors that are being reported, irrespective.) There are a few wrinkles around porting from Alpha to Itanium (eg: checking for alignment faults, after you've gotten the port working) but (based on local experience) there's very little that could be picked up from the list of included and header files. (You either have the include files or you don't, and the compiler will tell you that far more quickly and efficiently than will a manual filename match.)

And note that the OpenVMS system include files are in text libraries on both platforms, and which can thus cause some confusion when folks are looking around for them and not finding them. Recent C compiler installations don't extract the headers (any more), so the customer can need to work around that or to use some DCL and a freeware tool such as what I've posted here:

http://labs.hoffmanlabs.com/node/1424

I'd also suggest clustering the new Itanium with the existing Alpha at least temporarily, as that makes hauling the source code around far easier. That clustering capability is also something I'd ask HP to provide for the port (via some sort of loan of products or whatever it's called - and if you're working where that TS-GSCD acronym implies, that might also be something you can provide to the customer here - if the end-state configuration itself isn't going to be clustered, and if policy allows. If the end-state configuration is clustered, then mixed-architecture works nicely for porting code.

In any case, if this is a port, that's (usually) rather larger than what I'd expect the ITRC forums can provide your customer. The port from Alpha to Itanium is usually fairly mechanical, though each port is always different, and there are occasionally cases of platform-specific code around, lost source code, weird designs that were hauled forward from VAX/VMS v.ancient, or even RSX-11, missing layered products, etc...

[H.Becker]

As already said, there is no info about objects or object libraries in VMS images. ANALYZE/IMAGE is one tool to find all the shareable images one image depends on. But there is more, there is SHIML, a tool which lists the whole shareable image tree one image depends on and there is XPD, a tool which lists the names of the external prodecures and data one image references (which at run time are resolved by shareable images).
If you need those tools, Google will easily find them for you.