Implementing LIBTOOL on OpenVMS

[John E. Malmberg]

I am encountering libtool scripts in programs that I am building on OpenVMS.

Currently the scripts are building static libraries based on what they 
can determine from the configure scripts.  What I would like to do is to 
get them to build shared libraries for better efficiency.

Because of differences between *NIX and OpenVMS in this area, it looks 
like it may not be possible to make generating shared images on OpenVMS 
totally transparent to a build procedure with out some cooperation with 
the maintainers of the package.

The documentation suggests a post to this mailing list before I do anything.

There are some issues that I need to deal with.

1. All symbols must be resolved at the time a shared library is built on 
OpenVMS, either internal to the resulting shared library or by a shared 
library it is built against.  If I do not have this information, only a 
'static' library can be built.  Symbol preemption or definition at load 
time is not supported.

2. I need a list of public symbols to feed into the linker.  It appears 
that the method used for .DLL files can be used to identify them, or the 
.sym file.

3. For dot-n releases, in order to provide upward compatibility so that 
new shared libraries can be used by older programs, the list of public 
symbols must always be in the same order, with new symbols being added 
to the end.  Note that this does not apply if the shared image is only 
loaded by dlload().  On OpenVMS, programs are normally linked against 
shared images, and the dlload() method is only used for things like 
"plug-ins".

Special handing is needed if routine foo(x,y,z) changes to be foo(p,d,q) 
in a newer dot-n version.  The old version of foo would get a new name, 
but retain it's position in the symbol table, and it needs to still 
return something, if only an ENOSYS error code if it was really bad to 
continue to use it.  The new version of foo() would go to the end of the 
table.

So for OpenVMS, some history needs to be maintained for the full 
advantages of shared images to be used.


Other issues:

PIC mode.  OpenVMS compilers generate PIC code unless explicitly tell 
them not to.

Normally the eventual location of the shared library will reside is not 
used at build time.  A construct known as a logical name is used to find 
it if the shared image is not in the /SYS$SHARE directory.  For shared 
libraries not supplied by the operating system, normally a logical name 
is used.

A logical name works like a symbolic link, except that to the file 
system it looks like it is always present in the in either the current 
working directory or in the root directory when it is explicitly 
referenced.  A logical name can supersede access to a file of the same name.

When an application is built against a test shared library instead of a 
production one, it makes a local logical name for this.

There is a naming convention for the logical names and program names 
where prefixes can be reserved to prevent conflicts so that multiple 
libraries with similar names can coexist.  These prefixes are not 
directory paths.

On the 64 bit OpenVMS platforms, the detailed debugging symbols can be 
put in separate files that only need to be installed on the target 
system if there is a problem.

The install / deinstall steps for shared images on OpenVMS is probably 
not practical to be implemented through libtool because of significant 
differences in the way that task is done on OpenVMS.  The closest 
equivalent might be moving the images to a staging directory.

Because public data items in a shared image must never move or change 
size for upward compatibility, it is best not to have any.  Instead the 
data is best accessed through procedures that return a pointer to their 
internal location.  Macros can be used to hide this from the calling 
programs in the header files to the library.

Incremental linking does not exist on OpenVMS.  I can fake it, but all 
that does is use more disk space.

-John
address@hidden
Personal Opinion Only