Re: Implementing LIBTOOL on OpenVMS

[Ralf Wildenhues]

Hi John,

[ not responding to everyting ]

* John E. Malmberg wrote on Mon, Dec 05, 2005 at 09:14:05PM CET:
> 
> No problem, I am fighting with pkg-config right now. 

I'm sorry.

> Ralf Wildenhues wrote:
> > I had to read a bit about OpenVMS first.
> 
> I assume that you found the documentation link at 
> http://www.hp.com/go/openvms .

I was looking at http://openvms.org before.

> There are a few public access OpenVMS systems on the wild wild web,

Thanks for the pointers!

> >I'm still not quite sure how libtool should deal with this
> >information on OpenVMS.  But generally, whether the changes are
> >compatible or not *should* be specified by the library author with
> >the version triple, as explained in info Libtool Versioning and
> >following chapters.  It's not exactly trivial, but it's quite 
> >important that it be followed closely by both library authors and 
> >libtool implementations on specific systems.  Otherwise software 
> >packaging and use will be very frustrating.
> 
> See GSMATCH explanation below.  It looks like a similar method.

The thing with libtool is: you can specify per-system maps of

  (CURRENT, REVISION, AGE) <-- system-specific version

  (CURRENT, REVISION, AGE) --> allowed set of system-specific versions

So you could invent one that matches the abstract libtool model with
(one of the) VMS versioning models.  The code in ltmain dealing with
version_type does this.

> >Hmm.  What does the GSMATCH number convey exactly?  What are its 
> >semantics for VMS?
> 
> A GSmajor and GSminor "version" type number.  The GSmajor number changes 
> with incompatible changes to the public interface.  The GSminor number 
> generally changes with upward compatible changes to the public interface.
> 
> A shared image can be set so that both numbers must match, or just that 
> the major number matches and the minor number of the shared image is 
> equal or higher than the one that the calling image was linked against.
> 
> Encoding is up to the programmer.

So you have two possibilities for maps.  Hmm, I don't know whether we
can support both at the same time in libtool.


> When an image is activated through 
> running a program, these checks are done, and if they do not pass, the 
> image does not get activated.  With a dload(), these checks are not done 
> on that image, but the loaded image may trigger the attempt to load 
> other shared libraries.

Note: in ltdl.m4, you need to add an *sys_dlopen_deplibs=yes to the
macro about the deplibs.

> These numbers may not want to track a triple of x.y.z, because bar-2.0.0 
> may be upward compatible with bar-1.9.9, so the GSmajor would stay at 1, 
> and if new public interfaces were added, the GSminor would get bumped by 
> at least 1.




> What is happening is that some programmers came up with a hack to scan 
> an object library or set of object modules for the public symbols and 
> then build a shared image exporting all of them.  Of course nothing 
> could be predicted about what order they would show up in.

True.

> This did allow building a shared image automatically from an OpenSource 
> project, but everything must either have a private version of the image 
> instead of it being shared, or all applications must be relinked if the 
> common shared image is rebuilt.

So it would be better if the library authors provided a list.
Hmm.  Maybe you can convince a few.  If the list can be kept platform-
independent, maybe a few more people will move to using
-export-symbols-list..

> It sort of defeats the purposes of having a shared library.

Not totally.  It limits it quite severely, but that is still better than
nothing.

> >Does OpenVMS only allow to load one shared library of a certain name
> >at a time? In which context: per-process, per-user, or globally 
> >system-wide?
> 
> System wide there can be multiple libraries sharing a name, however an
> executing program will generally only see one of those libraries.

OK.

> And a shared image is only really shared if it is "Installed".
> Otherwise a private copy is loaded.
> 
> A logical name can be used to cause a private copy to be loaded instead
> of the existing system wide installed one or to cause an alternate 
> system wide library to be used.

OK.  So this mechanism is very good to test uninstalled libraries.


> Now with OpenVMS, the convention is not to request a load of
> /usr/lib/foo/bar.so but to just request a load of "foo_bar".  The system
> looks first for a logical name of "foo_bar" and if found, treats it like
> a symbolic link to find the real file.  Then it looks for
> /sys$share/foo_bar.exe to find it.

OK

> >Ouch.  I know libraries that contain 1000 objects. Does the linker
> >have something similar as GNU ld's --whole-archive flag?
> 
> Actually the equivalent flag is set by the librarian, if not set, the
> linker grabs the entire file.  As a shared library needs public symbols,
> which in OpenVMS terms are universal symbols, resolving those usually
> pulls in all the library modules for a shared image.

OK.

> However, the AR emulation on OpenVMS does not always create a library, 
> sometimes it just concatenates the object files.

What's the difference in semantics to a, say, unix-like ar?

> --------
> 
> For my first passes at things, I plan to just do what I can to get 
> libtool to generate static libraries like it is attempting to do, and 
> then I will then add my own link procedure to generate a shared library 
> if that is needed.

Good idea.  You can still go on from that.

Cheers,
Ralf