Subject: Re: so name bump; impact on major, minor and patch version

Re: so name bump; impact on major, minor and patch version

From: Jose Baars <>
Date: Sun, 14 Mar 2010 22:55:16 +0100

Op 3/14/2010 8:21 PM, Peter Stuge schreef:
> However, it will require some education of us unix guys without
> strong VMS background. I know next to nothing about VMS so far, but
> if we can make changes to libssh2 code or development practice to fit
> better into VMS then I think those changes should be considered very
> carefully.
Ok, I'll try. ( I'm going for Olympic Geek medal here :-))

see also :
if you really want know:
if you don't get scared quickly, for a really geeky use of shared images :

In short, there are 2 features for shared images on VMS that are
different to .dll's and .so's:
- Normally, when developing applications using a shared image, you link
against the shared
   image on the system. At link time, the jump vectors in the shared
image are read and coded into the
   resulting executable ( the application you wrote).

   This is fundamentally different on Unix and Windows, where at run
time the shared image
   (excuse my French) after an extensive search is opened, and the
application is
   directed to the proper routine in the shared image based on the name
of the routine.

   This means that on VMS if a new routine is added to the shared image
without further ado,
   the vector table after this new routine has shifted one place, and
executables linked against the
   the old version will bomb, or worse, do something really horrible,
if any of these routines is

   The standard solution is of course to make sure new routines are
added at the
   end of the vector table, so all old routines keep the same vector.
And as a safeguard
   there is the global section match.

   ( there is way to use shared images on VMS with a dynamic lookup,
lib$find_image_symbol but that is not a common way
     to offer access to a complete API, although it does exist for
Apache apparently.)

- To make sure the available shared image on a system and the shared
image at link time
    of an application are compatible, every shared image is linked with
a Major version and a Minor version,
    and a match parameter, usually Less or Equal, meaning the major
version of the shared image against
    which the application has been linked must match, and the Minor
version at runtime has to be at least
    the Minor version at linktime.

    When an application is started, VMS will open the shared image
available, and will immediately bomb
    out if this global section match as it is called doesn't meet the
conditions in the shared image.

    This is the version that will need to be maintained. It roughly
matches the ld version, but needs extra care
    and attention, and maybe more 'bumping'.

Pro's and con's:

    This sounds all a bit restrictive and complicated, but there are
some advantages too:

    - as a developer, it is possible to guard against mismatches of
applications and shared libraries.
    - dll hell, is an almost non-existent phenomenon on VMS, and if it
is, it's a bug introduced by the
       developer of the shared image, noone else. That is a mixed blessing.
    - there is no such thing as opendl. That problem has already been
solved at link time.

   Anyway, these are design decisions made in the 70's and a discussion
on the pro's and con's
   is pretty useless: it won't change.


   So, I will not be following the ld versioning in the global section
match id,, but the major ld
   version and major * 1000000 + minor*1000 + patch of the build version
to start with, as
   this will probably be most close to what the glocal section id is
intended for.
   It is a number that actually doesn't mean anything, it's just a
safeguard against DDL hell.

   In the actual identification of the image ( the string that describes
the shared library ) I'll use both the ld version
   and the build version to exactly identify the image.

   To make sure several versions of libssh2 can exist on a VMS system
I'll also make sure the Major (
    and if necessary Minor version) are in the filename of shared image
in the binary kit if it is an incompatible
    version to the last one. To make this transparent the logical name
pointing to the image library has to reflect
    this version as well.

    I don't think it would be fair for the libssh2 maintainers to take
these restrictions into account,
    as it is so VMS specific. On the other hand, it would be nice to
have a routine vs. date-added/deleted/modified
    cross reference.

> The overall goal is that libssh2 should be very portable. That means
> we love VMS too. :)
> //Peter

LOL! The actual VMS specific changes in the code are very small, I am
trying keeping up with the daily builds now,
my agenda is now making a VMS PCSI ( binary) kit and automating the
process of producing this
as automatically as possible.



Received on 2010-03-14