[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Implementing LIBTOOL on OpenVMS
Re: Implementing LIBTOOL on OpenVMS
Tue, 6 Dec 2005 08:39:38 +0100
[ 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.
> 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.
> 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
> It sort of defeats the purposes of having a shared library.
Not totally. It limits it quite severely, but that is still better than
> >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 there can be multiple libraries sharing a name, however an
> executing program will generally only see one of those libraries.
> 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.
> >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.
> 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.