[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Implementing LIBTOOL on OpenVMS

From: John E. Malmberg
Subject: Implementing LIBTOOL on OpenVMS
Date: Fri, 18 Nov 2005 15:26:14 -0500
User-agent: Mozilla/5.0 (X11; U; OpenVMS AlphaServer_DS10_466_MHz; en-US; rv:1.7) Gecko/20040621

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.

Personal Opinion Only

reply via email to

[Prev in Thread] Current Thread [Next in Thread]