Jose Baars wrote:
> Thanks for the guidance John. To be honest I don't want libssh2 for the sake
> of curl, but for it's own sake. On the other hand it would probably be a useful
> exercise.I'll see how far I get.
It gives you a program that you can use to sanity check the build of
libssh2 that the libssh2 developers are familiar with to answer questions.
> libssh2 has only lowercase functions, no real problems there, some
> functions exceed the maximum lenght for the linker, though.
For the VMS, this should be handled the following way:
1. Set the compiler to use exact case and shortened names. It generates
a CRC for the internal name and creates an alias database. The GNV
curl/libcurl build instructions show how to set that up.
For Universal symbols longer than 31 characters in a new shared image,
follow all 4 steps. For less than 31 characters only 2 aliases are used.
1. Primary should be exact case CRC shortened.
2. First alias should be upper case CRC shortened, takes an additional
compile step outside of the normal build. Only needed once per module
with Universal symbols.
3. Second alias should be exact case, but manually truncated if it will
still be unique at 31 characters, if not, then come up with a new alias.
4. Third alias should be the same as the third, but upper case only.
If you are refreshing a port that has a shared image with the symbols
only in upper case truncated, add the aliases to them to make things
complete to the end of the transfer vector list.
This way the shared image can be usually be used no matter what the
compile settings are.
>> 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.
> A test if a socket is blocking or non blocking in libssh2 is stack
> specific I'm afraid.
> I do a test on the definition of SO_STATE to execute the TCP/IP
> services specific statement.
> The setting a socket nonblocking might not be an issue, but of that
> I'm not sure.
Linking against a specific TCP/IP stack should be avoided. If it can
not be avoided, I would recommend a VMS specific wrapper routine that
dynamically loads the image/symbol just like the C runtime does. That
way if the other stacks ever add the same functionality, there is a
chance that it will just work, because they will be anticipating the C
library being extended to use that call.
If it does not, it is a place where a developer can put the code to
detect which TCP/IP stack is present and dynamically load the right
routine, or attempt to let the program know that the feature is not
present, if there is a way to work around it.
It is also possible that people on Encompasserve may have useful
suggestions for support of all three stacks.
>> 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.
> As far as I understand configure scripts are useful to discern between
> the hundreds
> of *ix implementations, and the complex versioning issues on these systems.
> On VMS, I see hardly any added value. I'd rather stay clear of it, it solves an
> issue that hardly exists on VMS, but I understand that for conformity one would
> go that way. I'll have a look.
On the typical recent configure scripts that I have run, at least 1/3 of
the tests have no value as a previous identical test already provide all
the information needed, and most of the tests are done with out using
the header files. With out using the header files to define a routine,
the tests are guaranteed to always give the wrong results on any
platform that maintains backwards binary compatibility, and needed to
make a change to better comply with the standards.
Configure runs very slowly on VMS, so those redundant tests hurt.
When a test incorrectly fails on VMS because of a past issue with the C
library, the work around that Configure enables may have issues or not
work at all, unlike on a real Unix, where the end program binary just
ends up being slightly larger and possibly slower than it needs to be.
Somewhere, I also have a DCL script that will generate a pretty accurate
config.h based on config.h.in. It does not actually do anything but
look up header files and universal symbols in shared images, and works
on IA64 or Alpha.
I stopped using it because for SAMBA V4, the MMS equivalent of the
makefile could not be derived from hand, which required me to solve the
configure issues. Once solved, it has been much easier to simply find
out what it takes to get the Configure scripts to run.
> No problems there either. libssh2 is only depending on OpenSSL (I use HP's,
> for convenience) , and zlib. Zlib on encompasserve seems like the way to go.
>> 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.
> That was also suggested by Thorvald. I like the idea of using git,
> though, as it might save me manual labour in the end.
In that case, NFS mount an ODS-5 volume on a *Nix system and you will
have all the *NIX tools to maintain a build tree.
> Question: should I do that against a current tarball or the latest
> stable release?
Until I get something working, I use the latest stable release.
Building against the current tarball is useful for verifying that your
changes actually work the way they were intended.
Personal Opinion Only
Received on 2010-02-26