Dave McCaldon wrote:
> On Feb 25, 2010, at 9:15 AM, Jose Baars wrote:
>
>> I'm at the moment testing libssh2 on VMS. I have most examples
>> working now.
>
> Great, this is something I'd been looking into, but never gotten to.
> Are you building libssh2 as a shared library (or whatever it's called on
> VMS), or linking it into the resulting EXE?
It is usually called a shared image, but shared library can also be used.
>> As make/config tools are not widely available on VMS, I made
>> a simple build procedure for use on VMS. As VMS systems
>> look far more alike than the hundreds of flavours of *ix systems
>> this is not a big issue, in my opinion.
>
> I believe GNU make is available on VMS, but it's going to be an extra
> step to install, so yes, a simple (DCL?) script is probably best.
I used to use DCL scripts, but in order to get Samba V4 to build on VMS,
I had to fix issues with the GNV kit.
Step 1. Telnet to Encompasserve.org with an ANSI terminal and sign up
for an account.
Step 2. Start reading the PORTING_TO_VMS notes conference, it can be
access through NOTES after you read the introductory material on
Encompasserve.
It can also be access via your web browser.
http://encompasserve.org/anon/htnotes/conf?f1=PORTING_TO_VMS
Step 3. Install GNV.
Step 4. Use the instructions in the notes conference and the existing
startup files to fix the GNV installation as needed, including getting
updates from the ftp://encompasserve.org/gnv directory. At the present
time, only Alpha binaries are available, but every thing there has the
source and the instructions to be built on IA64.
Participate in the PORTING_TO_VMS conference there. Encompasserve has
everything needed to build most projects.
And we can help you build kits that look as good or better than
commercial products and comply with VMS packaging standards.
>> I can only test against 1 of the tcp/ip stacks available on VMS, although
>> this is the most commonly used one.
>
> I have access to a several VMS systems for testing, although I don't
> know what TCP stacks they have. I believe most of them are fairly recent
> versions of OpenVMS which I think has a "standard" TCP stack -- that's
> probably what you have.
There are 3 stacks in use on current versions of VMS. For the purposes
of most programs, you do not need to care. The C runtime has wrappers
and dynamically loads the TCP/IP library as needed.
Server applications need to know the difference as there are different
startup scripts.
And it has been recently announced that HP has made some systems
available for Open Source testing.
>> I still have to look in to what zlib I should use, and when testing
>> I found that the most common SSH server on VMS has a maximum
>> window size of 16 Mb, giving the (here well known) message
>> 'Bad window size in WINDOW_ADJUST' causing libssh2
>> to bomb out. I am not brave enough to solve that in libssh2.
>
> zlib is apparently available for VMS:
>
> http://www.openvms.org/stories.php?story=05/07/29/9386511
>
> curl/libcurl uses it and is also available on VMS:
>
> http://www.openvms.org/stories.php?story=09/08/15/0379754
>
>> Could my changes eventually be included in the main stream,
>> and if so, how should that be accomplished?
What I would first recommend is refreshing the CURL/LIBCURL kit on
Encompasserve to the the current release. In the distribution kit there
are two source save sets. One of them is the VMS changes that have not
yet been integrated into the mainstream curl.
You can also search the curl mailing list archives for discussions about
what was wanted to get those changes in.
There are scripts and instructions in that kit on how you download and
build the daily curl tarball to verify your changes.
Once you get the current curl building, you will know how to set up to
build libssh2.
Then you can build libssh2 and re-run the configure script for curl to
find it and build a curl binary that uses it. The hardest part may be
building the PCSI distribution kits.
There are some dragons to slay, but if you can get this far, you can
help with making things better.
One of the biggest challenges is getting the configure script to produce
the correct output. This is from two main problems:
1. Finding the header files and shared images for layered products is
too different on VMS for configure to deal with.
2. Configure is badly broken on all platforms that support backwards
binary compatibility and this really is exposed on VMS and configure
seems to be evolving to be worse in this area instead of better.
There is also a bug in the VMS port of bash that using ${ECHO} instead
of echo causes internal corruption in BASH, so for building Curl, I am
currently using an older configure script than what is in CVS.
> I'd look at how Windows is supported; there's a win32 subdirectory
> that contains the project files and some Windows specific header files.
> If there are specific issues in the common code, then wrap them in an
> #if defined(__VMS)/#endif block, I guess if it requires more involved
> code changes, that might need to be abstracted out somehow.
When I refresh a port of an Open Source project to VMS, I search for
those and try to eliminate them. Many times I find that either they
were never needed, or they were incorrect. There are some in curl that
can be removed by changing the os specific header files to create
wrapper macros to redirect the routines to ones customized for VMS.
The main issue that would likely to show up for libssh2 is that VMS has
a limit on how much it can read/write to a socket in one operation.
VMS also has problems with ".." in #include directives, and some of the
shared images only have uppercase universal symbols.
> I'd suggest creating a vms subdirectory and putting everything in
> there. One you have all of that, then submit as a git patch.
I do not have git working well enough on VMS for submitting git patches.
NCURSES needs to be ported to fix LESS, which is needed for me to
debug the next step and I am too short of time to work on that right now.
So right now, all git can do is fetch a complete copy of a repository,
but not update it.
Using the 'diff -u' option with exact case UNIX style path names in
quotes has been good enough for the projects that I have worked on.
-John
wb8tyw_at_qsl.network
Personal Opinion Only
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2010-02-26