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 _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
