Generating a shareable image from an object file or library

[Jeremy Begg]

Hi,

As part of an Itanium migration project I need to turn a selection of OpenVMS Alpha object modules into a OpenVMS Alpha shareable image. These are compiled from "C" sources but the source code is no longer available. Some of the object modules are in an object library, and some are individual .OBJ files. Once we have changed the application to link against the shareable image rather than the object modules, we should be able to translate the shareable image using AEST. (We can build the rest of the application from BASIC source.)

Is there a tool which will extract the global symbol definitions from an object file or library and turn them into a SYMBOL_VECTOR statement in a linker options file? Such a tool would save a lot of mucking about with the output from ANALYZE/OBJECT.

Thanks,
Jeremy Begg

[Kris Clippeleyr]

Jeremy,
Attached a DCL command procedure that can produce a symbol vector from a list of object files. It takes an input file as "P1" parameter and an output file as "P2" parameter.
The input file should contain a list of names of object files (one per line).
This procedure works for me on OpenVMS Alpha.
Regards,
Kris (aka Qkcl)

[Robert Gezelter]

Jeremy,

Since you are doing this as part of a migration, two other suggestions:

- Consider using the LINK map as a stating point (e.g., remove the object library from the LINK operation, and use which externals are unresolved as a guide); or

- Use the various LIBRARY/LIST options to extract the list of entry points.

On general principles, I would also include several spare entry points, to allow graceful upward compatibility.

- Bob Gezelter, http://www.rlgsc.com

[H.Becker]

It may work in your environment but exporting everything is not recommended. You can run into link-time and run-time errors.

Determining the symbol vector entries based on the unresolved externals from a linker map is the best approach.

[Hoff]

This is about half an hour of brute-force DCL coding (or perl or php or whatever string-handling language you have and have a comfort level with), or less. List the externals from the library and brute-force the publication of entry points into the vector for the LINKER, then run the results through the LINKER and then AEST. I'm guessing elegance and upward compatibility and efficiency of the symbol vector just don't matter for this case, given this is probably that lost-source AEST project.

[John Gillings]

Jeremy,

Although others have posted solutions, I would recommend you DON'T try to automate building a symbol vector. If it were feasible to do this is a general way, OpenVMS would have had it years ago. I've seen numerous attempts to "solve" this problem over the years, none of which really do it properly.

There are several reasons.

First, the order of the symbol vector is critical, maybe not the first time, but for second and subsequent incarnations order must be preserved. There is no way to sort the list correctly, taking into account additions and removals. Ultimately the only way to do it is to maintain a list, and since any proposed utility would really only produce a list, it's all circular. (Of course you're going to say this is a one off, but I'll quote one of Fred Brooks' laws: "plan to do it twice, you will anyway").

Second, in any collection of routines there will always be private, internal routines which should not be exposed to the outside world. Beware especially of tiny utility routines with names that might clash with other modules.

Third, it's quite easy to do it manually. It's probably quicker than learning how someone else's tool works, or building one yourself.

I'd use the librarian. First enter all your modules into an object library. Now catch the output of

$ LIBRARY/LIST/NAMES

Filter off the header, the "Module XXX" subheadings and the blank lines. You now have a list of routines in module order. Sort them into a different order if you want, but once you've linked your first version, the order must not change.

Now remove all the private routines (or skip if you really want ALL routines), and turn each line into:

SYMBOL_VECTOR=(symbol=PROCEDURE)

(they concatenate, and this syntax avoids any command line overflow issues).

Hopefully you're not intending to export naked data structures.

If you ever need to update the list, make sure you only add entries at the bottom. If you want to remove a routine, replace its entry with SYMBOL_VECTOR=(SPARE) and a comment naming the symbol being removed.

If you have an existing shareable image, my FAKE_RTL procedure will build an options file for you.

[Hoff]

Based on another recent question, I expect Mr Begg is working with existing object code that will be linked and then run through AEST as part of a port.

This environment (if my assumptions are correct) is already somewhat of a crock, and the object code here is unlikely to be touched again once the shareable image works.

And this translation pending the wholesale replacement of the object code, or of some future and unspecified port.