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

Creating a shareable image on I64

 
SOLVED
Go to solution
Martin Vorlaender
Honored Contributor

Creating a shareable image on I64

All,

when trying to build XPDF and all of its dependancies on OpenVMS I64 8.3, I hit a road block with (at least) XAW and XMU.

On VAX and Alpha, a map file is generated from the object files using LINK/NOSHARE/NOEXE/MAP=map_file option_file_containing_objects

Then, map_file is parsed for psect and symbol names. Out of these a new option file is generated to LINK/SHARE.

Unfortunately, this does not work on I64. I do have another DCL procedure that parses the output of an ANALYZE/OBJECT/SECTION=SYMTAB for symbols. This gives me the global procedure symbols.

Unfortunately, XAW also exports some C structures, which I cannot find in the object analysis output.

Anyone have a hint on how to identify these?

cu,
Martin
17 REPLIES 17
Hein van den Heuvel
Honored Contributor

Re: Creating a shareable image on I64

Horse and cart question ?

I'm all for automating the generation of sources file when possible and desirable.
I have generated many a function table, prototype module, and so on myself, mostly using DCL scripts, but of late more so using perl.

But really IMHO the .OPT file is not a by product but a tool to make sure everything is consistent.
So go ahead, generate it once (on Alpha!), closely verify it for excess symbols which should not be exposed, and then bless the darn thing and stick it in the source distribution.
From there onwards, maintain it like any other source file. This .OPT file should possibly not be seen as an annoyance, but as a helper file.

Just a thought!

Hein.

John Reagan
Respected Contributor

Re: Creating a shareable image on I64

Global data symbols and PSECTs are in the SYMTAB as well. If you can't see them, C didn't export them.

There isn't any other hidden mechanism for global data vs global routines.

John
Richard Whalen
Honored Contributor

Re: Creating a shareable image on I64

If you can find an OpenVMS V8.2 system then you can use the /EXPORT_SYMBOL_VECTOR and /PUBLISH_GLOBAL_SYMBOLS qualifiers to generate an options file. But as was discussed in http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1176046 these are not available on VMS V8.3.

If you intend to make the software available to others, then it would probably be best to find an 8.2(-1) system as it is possible that an image linked on an 8.3 system may not run on an 8.2 system.
John Gillings
Honored Contributor

Re: Creating a shareable image on I64

Martin,

What doesn't work on I64? What's the difference in the map files? What does Alpha list that I64 doesn't? Have you tried /MAP with /FULL and/or /CROSS?

I'd have thought it much quicker, simpler, and easier to parse to dump all the object modules in a library then do a LIB/LIS/NAMES to generate the list of global symbols (though granted, it doesn't list PSECTs - are you really sharing PSECTs between images? uggh! there are much cleaner mechanisms)

As Richard mentioned, for a short time, the linker had /EXPORT_SYMBOL_VECTOR and /PUBLISH_GLOBAL_SYMBOLS, but these were removed for the very reason that what you're doing really isn't a good idea!

First, it's extremely rare that you would really WANT to export ALL global symbols from a set of object modules to build a shareable image. Why clutter up a symbol vector and wear the run time cost of fixups for routines that will never, and should never be called from outside?

Second, even if you generate them, there's no way, even in theory to automatically keep them in a consistent order to form a symbol vector which gives any type of upwards compatibility (and, if you don't care about upwards compatibility, why use shareable images in the first place? much simpler just to link everything together!)

As Hein has suggested, treat the options file as another chunk of source code. By all means generate the list first time, but then maintain it by adding any new symbol table entries at the end. Surely he code can't be volatile enough to make that a serious burden?

A crucible of informative mistakes
mike wagner_4
Occasional Advisor

Re: Creating a shareable image on I64

> ... LIB/LIS/NAMES ...

Lists the names, you very likely want to know if they are procedure or data. At least the linker options expect that. Sure, try and error is always an option.

> ... PSECTs between images? uggh! there are much cleaner mechanisms) ...

Did you ever consider that the compiler may generate them for you and that you may not have much choice?

Xpdf looks like Open Source. If you want to port it you have to take what's there or to convince the non-VMS developers to accept VMS specific code or build procedures, and to maintain them.

On Unix/Linux "exporting everything" is quite common. And it works. On these systems there is not always a penalty for not calling an exported function, the symbols for "everything" can have late binding, they are "fixed up" when they are needed. This doesn't make exporting everything a good thing, but it is cheap. Guess what people pick? In other words, Unix is different.

ANALYZE/OBJECT is the supplied VMS utility to get to the global symbols and the section, which is not necessarily listed as a symbol in the symbol table.

But why aren't we waiting until Martin tells more about his problem?

mw