0.9.8j v. VMS

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

0.9.8j v. VMS

Steven M. Schweda-2
   Greetings:

   Is anyone interested in updates to the VMS builders to accomodate
IA64 systems?  I've been playing with 0.9.8j, and I believe that I've
changed all the "if Alpha" things to "if .not. VAX", and added the
architecture-specific directories for IA64.  (And added the new module
names, and fixed a small boat-load of other problems.)  The result seems
to be working stuff on VAX, Alpha, and IA64, but some more serious
testing would probably be wise.

   I haven't gone through and checked that all the modules which should
be in the libraries are actually in them, but the test programs can be
linked again.  While it should now be possible to build simultaneously
on VAX, Alpha, and IA64 in one directory tree, I haven't gone through
and rejiggered all the "[.test]t*.com" files to do their work in
architecture-specific directories, so actual test runs may still
collide.  (So far, I've tried not to learn too much about the actual
tests.)

   If there is interest, how should I package the changes?

------------------------------------------------------------------------

   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                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 0.9.8j v. VMS

Richard Levitte - VMS Whacker
Yes, it is very interesting, thanks for doing the work!

There are two alternatives:

- produce Unix diffs for all your changes.  If you have GNU diff on
  your machine, that should be fairly simple.
- zip the changed files into an archive.

Whichever alternative you use, please send the result to me as
attachments.

Cheers,
Richard

In message <[hidden email]> on Mon, 12 Jan 2009 07:27:32 -0600 (CST), [hidden email] (Steven M. Schweda) said:

sms>    Greetings:
sms>
sms>    Is anyone interested in updates to the VMS builders to accomodate
sms> IA64 systems?  I've been playing with 0.9.8j, and I believe that I've
sms> changed all the "if Alpha" things to "if .not. VAX", and added the
sms> architecture-specific directories for IA64.  (And added the new module
sms> names, and fixed a small boat-load of other problems.)  The result seems
sms> to be working stuff on VAX, Alpha, and IA64, but some more serious
sms> testing would probably be wise.
sms>
sms>    I haven't gone through and checked that all the modules which should
sms> be in the libraries are actually in them, but the test programs can be
sms> linked again.  While it should now be possible to build simultaneously
sms> on VAX, Alpha, and IA64 in one directory tree, I haven't gone through
sms> and rejiggered all the "[.test]t*.com" files to do their work in
sms> architecture-specific directories, so actual test runs may still
sms> collide.  (So far, I've tried not to learn too much about the actual
sms> tests.)
sms>
sms>    If there is interest, how should I package the changes?
sms>
sms> ------------------------------------------------------------------------
sms>
sms>    Steven M. Schweda               sms@antinode-info
sms>    382 South Warwick Street        (+1) 651-699-9818
sms>    Saint Paul  MN  55105-2547
sms> ______________________________________________________________________
sms> OpenSSL Project                                 http://www.openssl.org
sms> Development Mailing List                       [hidden email]
sms> Automated List Manager                           [hidden email]
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: 0.9.8j v. VMS

Green, Paul
In reply to this post by Steven M. Schweda-2
Disclaimer: I am not a VMS person. But I have done a lot of work with
configuration scripts over the years. In my opinion, your code would be
much more future-proof if you made positive tests than negative tests.
E.g., "if alpha or ia64" rather than "if not vax".

Perhaps you know that the VMS world will never have a 4th platform, in
which case maybe you can live with "not vax".  But at least in the Unix
world, it is hopeless to test for "not" anything; there are over 30
variants of Unix out there, and only positive tests have a chance of
working over many years.

PG


Steven M. Schweda wrote:

> Sent: Monday, January 12, 2009 8:28 AM
> To: [hidden email]
> Subject: 0.9.8j v. VMS
>
>    Greetings:
>
>    Is anyone interested in updates to the VMS builders to accomodate
> IA64 systems?  I've been playing with 0.9.8j, and I believe that I've
> changed all the "if Alpha" things to "if .not. VAX", and added the
> architecture-specific directories for IA64.  (And added the new module
> names, and fixed a small boat-load of other problems.)  The
> result seems
> to be working stuff on VAX, Alpha, and IA64, but some more serious
> testing would probably be wise.
[snip]
>
>    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                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 0.9.8j v. VMS

Steven M. Schweda-2
In reply to this post by Steven M. Schweda-2
From: "Green, Paul" <[hidden email]>

> Disclaimer: I am not a VMS person. But I have done a lot of work with
> configuration scripts over the years. In my opinion, your code would be
> much more future-proof if you made positive tests than negative tests.
> E.g., "if alpha or ia64" rather than "if not vax".
>
> Perhaps you know that the VMS world will never have a 4th platform, in
> which case maybe you can live with "not vax".  But at least in the Unix
> world, it is hopeless to test for "not" anything; there are over 30
> variants of Unix out there, and only positive tests have a chance of
> working over many years.

   The VMS world is smaller than the UNIX(-like) world.

   Saying that I "know" would be going too far, but in the VMS world,
there are very nearly only two variants.  The VAX code base is old,
nearly stable (apparently stuck for all time at V7.3), and incompatible
in some ways with the newer code used on (and shared between) Alpha and
IA64.  I expect any future VMS platform to be added to the existing
(more portable) Alpha and IA64 code base, leaving the VAX as the only
odd-ball, then as now.

   Any new platform will have its own name, so some things may need to
be added for it, but in this situation, ".NOT. VAX" _is_ much more
likely to continue to work than is than any other arrangement.

   One more (dreary) example leaps to mind:
      http://h71000.www7.hp.com/opensource/gnupg.html
Note that one can "Download GnuPG V1.4-7 for OpenVMS for Integrity
servers and OpenVMS Alpha", but you're stuck with "Download GnuPG V1.2-3
for OpenVMS VAX".  Investigation will reveal that the (truly sloppy)
porting effort there was derailed exactly because of those positive
tests for Alpha instead of .NOT. VAX.  The (truly sloppy) fixes used in
the builder to accomodate IA64 left the VAX build broken (and the Alpha
build suboptimal, apparently unnoticed).  It's a trend.  I'll take my
chances.

------------------------------------------------------------------------

   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                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 0.9.8j v. VMS

Steven M. Schweda-2
In reply to this post by Steven M. Schweda-2
From: Richard Levitte <[hidden email]>

> - produce Unix diffs for all your changes.  If you have GNU diff on
>   your machine, that should be fairly simple.

   It's getting GNU diff that requires the effort.

> - zip the changed files into an archive.

   Some stuff is in:

      http://antinode.info/ftp/openssl/0_9_8j/

   I assume that "gdiff -ru" is suitable.
             Original:      Modified:
   gdiff -ru openssl-0.9.8j openssl-0_9_8j
      http://antinode.info/ftp/openssl/0_9_8j/0_9_8j.dru

   Complete source kit:
      http://antinode.info/ftp/openssl/0_9_8j/openssl-0_9_8j_s4.zip

   Notes (included in the source kit):
      http://antinode.info/ftp/openssl/0_9_8j/notes_0_9_8j.txt


   I claim that the builders (now) work everywhere (for particular
values of everywhere), but I'm always open to a persuasive
counter-example.  Original files should be preserved as "*.*_orig".

   Wake me if you have any questions, or when it all goes bad.  If I get
more bored, I'll see if I can get the work files for the tests out of
the common areas.  Then it should be safe to build and test on all the
host types at one time.  (And I can do about twenty builds on my non-VAX
systems (each) in the time it takes to do one on the VAX 4200.)

   Before I forget, is there some good reason not to have the usual

#ifndef _OPENSSLCONF_H
#  define _OPENSSLCONF_H
<everything useful>
#endif /* ndef _OPENSSLCONF_H */

guards in "opensslconf.h"?

------------------------------------------------------------------------

   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                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 0.9.8j v. VMS

Ger Hobbelt
On Mon, Jan 12, 2009 at 6:28 PM, Steven M. Schweda <[hidden email]> wrote:
>   Before I forget, is there some good reason not to have the usual
>
> #ifndef _OPENSSLCONF_H
> #  define _OPENSSLCONF_H
> <everything useful>
> #endif /* ndef _OPENSSLCONF_H */
>
> guards in "opensslconf.h"?


Well, yes, there is. (I ran into this issue myself way back when and
forgetting the why, had it happen to me again a sort while ago)

Check out the master file opensslconf.h.in and see this bit for example:

------------------------------
#if defined(HEADER_RC4_LOCL_H) && !defined(CONFIG_HEADER_RC4_LOCL_H)
#define CONFIG_HEADER_RC4_LOCL_H
/* if this is defined data[i] is used instead of *data, this is a 20%
 * speedup on x86 */
#undef RC4_INDEX
#endif

#if defined(HEADER_BF_LOCL_H) && !defined(CONFIG_HEADER_BF_LOCL_H)
#define CONFIG_HEADER_BF_LOCL_H
#define BF_PTR2
#endif /* HEADER_BF_LOCL_H */

#if defined(HEADER_DES_LOCL_H) && !defined(CONFIG_HEADER_DES_LOCL_H)
#define CONFIG_HEADER_DES_LOCL_H
#ifndef DES_DEFAULT_OPTIONS
/* the following is tweaked from a config script, that is why it is a
 * protected undef/define */
#ifndef DES_PTR
#undef DES_PTR
#endif
------------------------------

Notice that there's all those
  #if defined(HEADER_XYZ_H...
checks in there.

Putting 'load once' ifdef/define/endif around the file like you would
normally do for headerfiles like these, this  stuff would fail
dramatically.

(mind you, this is me, not part of the core dev team,
guestimating^H^H^H^H^H^H^H^H^H^H^H'reverse engineering' their original
intent with 1/20 hindsight -- I wear glasses so can't claim 20/20 ;-)
)
In essence those
  #if defined(HEADER_XYZ_H...
  ...
  #endif
bits of code are there to keep those #define'd bits in there as
locally as possible. In other words, it's an attempt to accomplish two
things, each making life a little easier for some, all at the same
time:

1) keep all system-dependent configurable settings in a single
headerfile (so the ./config script only has a single file to
patch/augment)

2) make #defines, which risk collision with other, unknown entities,
*only* *available* for a *limited* set of source files.
In this case, DES_PTR only being created and available for
OpenSSL-internal source code which implements the DES cipher
(HEADER_DES_LOCL_H), etc.

The most tricky bits regarding those 'localized defines' in there are
OPENSSLDIR and ENGINESDIR as they are only brought into existence
when:
  #if defined(HEADER_CRYPTLIB_H) && !defined(OPENSSLDIR)
i.e. only when a source file loads <openssl/crypto.h>, which is a
public headerfile and thus can/will be loaded by OpenSSL-using third
party source code (= anyone using OpenSSL in their projects).



For a suitable contrast [for when you wish to do without those
'localizing' #ifdef HEADER_YADA_H checks aroudn each bit], see this
list's history for an ongoing slew of fatal Windows/winsock collisions
with X509 and other OpenSSL public APIs definitions: those are then
resolved by juggling header file load order and forcibly overriding
the winsock stuff, but it's not a nice game that way either.



Of course, one can question why such defines are in opensslconf.h this
way, but it's part of our heritage by now -- and I don't mind it. It's
just that about once every 5 years or so, I do something akin to what
you suggested and get my memory refreshed by compile error torrent. No
sweat.




--
Met vriendelijke groeten / Best regards,

Ger Hobbelt

--------------------------------------------------
web:    http://www.hobbelt.com/
        http://www.hebbut.net/
mail:   [hidden email]
mobile: +31-6-11 120 978
--------------------------------------------------
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]