In message <14082111271510_20200...@antinode.info> on Thu, 21 Aug 2014 11:27:15 -0500, "Steven M. Schweda" <s...@antinode.info> said:
sms> From: Richard Levitte <rich...@levitte.org> sms> sms> > The current build system is based on the assumption that you have a sms> > the base VMS installation with only a C compiler added. No MMS, no sms> > MMK, no Perl, no nothing. The world doesn't look that way and hasn't sms> > for a long time, time to catch up. sms> sms> I don't get out much these days, but I suspect that it _does_ look sms> largely that way in some (many?) places. If your target audience is sms> software developers, then you can demand more, but there may be some sms> people who want to build an OpenSSL kit without having to drag along a sms> whole, elaborate tool chain. (If HP fails to provide current stuff, and sms> there's no other trusted supplier of pre-built stuff, then people may sms> have little choice but to build their own.) Philosophically speaking, of course it would be great if someone made an installation kit for the supported VMS platforms. It's not necessarily going to be us (I've access to Alphas with quite up to date VMS and C compiler versions, but that's about all from within the team), and it's not necessarily going to be HP (or VMS Software Inc). Someone else might be just as interested in stepping up, who's to know? (Vms Software Inc. might actually be interested...) sms> That said, a requirement of MMK or MMS should not be too great a sms> burden. (In the stuff I work on, I believe that only Zip and UnZip sms> still offer DCL script builders. Everything else has only MMK/MMS sms> builders.) But I'd think very hard before demanding more than that. There is some similar package for Perl, isn't there? Is that very much of a pain? The reason I ask is that there are a number of useful tools written in Perl already, reproducing them in DCL feels like an exercise in futility, really, and is prone to exactly the kind of problem we have today with the current VMS build scripts (more on that below). sms> > Please join me, let's talk about what's needed, what tools we can sms> > expect people to have available (more than just the basic operating sms> > system and a C compiler), and what we can do, and make the needed sms> > changes. Feel free to fork my github repo, make changes and propose sms> > them. sms> sms> The big problem I see with OpenSSL on VMS is that, regardless of the sms> builders, no one tests this stuff on VMS before a release. So far, it's been me, and well, you and Zoltan, but that's more as an afterthought on already released stuff rather than current development. I took a pause, for several years, for all kinds of personal reasons, ranging from "tired of this shit" to other reasons that don't have to do with computing at all. I'm getting myself back to this as we speak. sms> For example, I just took a quick look at 0.9.8zb, and the sms> build failed because the builders (ssl/ssl-lib.com) hadn't been sms> updated to include s3_cbc.c, and crypto/symhacks.h hadn't gotten sms> the new longer-than-31-character names. Very true. I've concentrated on the 1.0.0 and up branches and haven't caught up on the 0.9.8 branch yet... But your example is exactly the kind of thing I want to address with a remake of the VMS build thingy. More on that below. sms> I also ran into a problem because I extracted the "tar" kit sms> preserving symlinks, and the old/lame makevms.com tried to copy sms> the header files onto actual symlinks in [.include.openssl], sms> which reflected them back to their source directories. (Stealing sms> some code from the 1.0.1i makevms.com helps (crudely) with that.) I'm behind on things, it seems... there are symlinks in VMS these days? That must have happened while I looked away... did you extract the "tar" kit with some other tool than the trusty old VMSTAR, or has VMSTAR learned to handle symlinks? I haven't looked at VMSTAR in ages, but back when I tinkered with it, it didn't have that capability. sms> So, assuming that no one will ever reliably test this stuff on VMS sms> before a release (and experience suggests that this is a pretty safe sms> bet), I'd worry first about creating some kind of automation which might sms> keep the source module lists accurate in _any_ kind of builders. _Then_ sms> I might worry more about getting something better than the current DCL sms> scripts to be kept accurate. (The names-longer-than-31-characters sms> problem means that keeping accurate module lists is not enough, but sms> adding stuff to crypto/symhacks.h is much easier than chasing through sms> the code to find the modules which will resolve all the %LINK-I-UDFSYM sms> complaints.) My absolutely first aim with this effort is exactly to not having to do the silly update of modules in the DCL scripts any more. The information is already there in the Makefiles, there's really no good reason why the information should be duplicated like it currently is. Quite honestly, the tinkering with modules in the DCL scripts is pure annoyance and something I'd like to avoid in as near a future as possible. "I'm tired of this shit" sure applies in this case. sms> If the Grand Plan solves these problems, too, then that's fine, but sms> if it doesn't, then I don't see it as a significant improvement. If sms> people did actual OpenSSL development on VMS, than a "make"-like sms> incremental build capability would have more value, but my (uninformed) sms> impression is that people _use_ OpenSSL on VMS, but don't do much (any?) sms> actual development of OpenSSL on VMS, so one giant build-all DCL script sms> is about as good for practically everyone as a fancy MMK/MMS scheme sms> would be. (Especially if the DCL script actually worked.) It's true that OpenSSL development doesn't primarly happen on VMS. Not even for me, I primarly work with a laptop running Linux, and basically only log into the VMS boxes to do builds (yup, I do that on a semi regular basis since a few weeks) and fixing the stuff I see needs being fixed (not a lot except for modules that need added some times, and the occasional more-than-31-character-symbol thing). sms> Some changed files for 0.9.8zb should be available at: sms> http://antinode.info/ftp/openssl/0_9_8zb/ sms> sms> 1.0.1i was not entirely happy, either: sms> sms> [...] sms> @@@ mkshared.com sms> %LINK-W-NUDFSYMS, 1 undefined symbol: sms> %LINK-I-UDFSYM, SSL_TEST_FUNCTIONS sms> %LINK-W-USEUNDEFSYMV, undefined symbol SSL_TEST_FUNCTIONS referenced sms> in symbol vector option sms> [...] ssl_utst is missing in [.ssl]ssl-lib.com. It's a fairly new unit testing module that exists in the 1.0.1, 1.0.2 and master branches, but not the older ones. Btw, the effort that I want to pull through will primarly be directed at the master branch for the moment being. Just FYI. Cheers, Richard -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ "Life is a tremendous celebration - and I'm invited!" -- from a friend's blog, translated from Swedish ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
