Jose Baars wrote:
> Op 3/14/2010 8:21 PM, Peter Stuge schreef:
>
> 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).
An additional restriction is that the once the order of the jump vectors
are established they must not change.
Libtool is not being used to build shared images with curl, it is just
being used to compile the module.
For libtool to be useful for building VMS shared images, there has to be
a way for it to know what the previous list contained and order it.
> 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.
Actually Windows DLLs have the same restriction as VMS for full
compatibility that the order of the symbols never changes for future
versions.
This is because Windows DLLs support calling by ordinal, which is the
routine number.
The last time I corresponded with the libtool maintainers, it could not
handle this. Neither they or myself know of any examples of this
actually causing a problem.
Right now, linking a VMS shared image is so foreign to the existing
builds for any other platform it is best to leave it as a set of VMS
specific scripts.
For the Curl package that I produced, all the binaries in the kit were
linked using VMS specific command procedures.
-John
wb8tyw_at_qsl.net
Personal Opinion Only
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2010-03-15