[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.
-John
address@hidden
Personal Opinion Only
- Implementing LIBTOOL on OpenVMS,
John E. Malmberg <=