From: Richard Levitte <rich...@levitte.org>
> The current build system is based on the assumption that you have a
> the base VMS installation with only a C compiler added. No MMS, no
> MMK, no Perl, no nothing. The world doesn't look that way and hasn't
> for a long time, time to catch up.
I don't get out much these days, but I suspect that it _does_ look
largely that way in some (many?) places. If your target audience is
software developers, then you can demand more, but there may be some
people who want to build an OpenSSL kit without having to drag along a
whole, elaborate tool chain. (If HP fails to provide current stuff, and
there's no other trusted supplier of pre-built stuff, then people may
have little choice but to build their own.)
That said, a requirement of MMK or MMS should not be too great a
burden. (In the stuff I work on, I believe that only Zip and UnZip
still offer DCL script builders. Everything else has only MMK/MMS
builders.) But I'd think very hard before demanding more than that.
> Please join me, let's talk about what's needed, what tools we can
> expect people to have available (more than just the basic operating
> system and a C compiler), and what we can do, and make the needed
> changes. Feel free to fork my github repo, make changes and propose
> them.
The big problem I see with OpenSSL on VMS is that, regardless of the
builders, no one tests this stuff on VMS before a release. For example,
I just took a quick look at 0.9.8zb, and the build failed because the
builders (ssl/ssl-lib.com) hadn't been updated to include s3_cbc.c, and
crypto/symhacks.h hadn't gotten the new longer-than-31-character names.
I also ran into a problem because I extracted the "tar" kit preserving
symlinks, and the old/lame makevms.com tried to copy the header files
onto actual symlinks in [.include.openssl], which reflected them back to
their source directories. (Stealing some code from the 1.0.1i
makevms.com helps (crudely) with that.)
So, assuming that no one will ever reliably test this stuff on VMS
before a release (and experience suggests that this is a pretty safe
bet), I'd worry first about creating some kind of automation which might
keep the source module lists accurate in _any_ kind of builders. _Then_
I might worry more about getting something better than the current DCL
scripts to be kept accurate. (The names-longer-than-31-characters
problem means that keeping accurate module lists is not enough, but
adding stuff to crypto/symhacks.h is much easier than chasing through
the code to find the modules which will resolve all the %LINK-I-UDFSYM
complaints.)
If the Grand Plan solves these problems, too, then that's fine, but
if it doesn't, then I don't see it as a significant improvement. If
people did actual OpenSSL development on VMS, than a "make"-like
incremental build capability would have more value, but my (uninformed)
impression is that people _use_ OpenSSL on VMS, but don't do much (any?)
actual development of OpenSSL on VMS, so one giant build-all DCL script
is about as good for practically everyone as a fancy MMK/MMS scheme
would be. (Especially if the DCL script actually worked.)
Some changed files for 0.9.8zb should be available at:
http://antinode.info/ftp/openssl/0_9_8zb/
1.0.1i was not entirely happy, either:
[...]
@@@ mkshared.com
%LINK-W-NUDFSYMS, 1 undefined symbol:
%LINK-I-UDFSYM, SSL_TEST_FUNCTIONS
%LINK-W-USEUNDEFSYMV, undefined symbol SSL_TEST_FUNCTIONS referenced
in symbol vector option
[...]
but I haven't investigated that one. I haven't yet tried 1.0.0n,
either, but complete success there would be amazing, too.
------------------------------------------------------------------------
Steven M. Schweda sms@antinode-info
382 South Warwick Street (+1) 651-699-9818
Saint Paul MN 55105-2547
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
