[openssl-dev] 1.1.0-pre5-dev (2016-03-20) v. VMS

[Steven M. Schweda]

From: Richard Levitte <levitte at openssl.org>

> Could you show me how you configured and what your default directory
> was?  Also, if you could tell me the difference between utility5_dev
> and ALP$DKC100, that would be great.

ALP $ show logical utility5_dev
   "UTILITY5_DEV" = "ALP$DKC100:" (LNM$SYSTEM_TABLE)

$ set default -
 utility5_dev:[UTILITY.source.openssl.openssl-master_2016-03-20]

$ @ config.com
$ mms

> sms>       logical names  (one rooted for the top-level dir?)
> 
> I'm starting to consider that.

   I tried to fool it:

$ define /translation_attributes = concealed OSSL_TOP -
   utility5_dev:[UTILITY.source.openssl.]

$ set default OSSL_TOP:[openssl-master_2016-03-20]

   But that led to (the not especially informative):

Configured for vms-alpha.
*************************************************
***                                           ***
***   Please run the same mms command again   ***
***                                           ***
*************************************************

so I figured that more care would be required somewhere to cope with the
logical names.  (Interactive advice is not much use in a batch job.)

> sms>       continuation lines
> 
> Regardless of that, there will still be a limit on the total line
> length, won't it?

   Probably.  MMS already seems to be breaking things apart.

sms>       relative directory specs

> Configure tries its best when possible.  However, from the command
> line above, the source and build tree appear to be on different
> devices, and it won't try to expand the logical names (or even worse,
> trying to use realpath(), you've already seen first hand what happens
> then).

   I'll try it again with more physical, fewer logical names.  Perhaps
some f$trnlnm() action (lather, rinse, repeat) could solve this kind of
thing automatically.

> sms>       documentation of the default directory spec length limit
> 
> Another thing I could see is recommending users to create rooted
> logicals "SRC" and "BLD" and use those.

   Better if the builders do it than the victims.

>     --with-zlib-include=3DINCDIR
>     --with-zlib-lib=3DLIBDIR
> 
> Apart from that, what I've done so far is tentative.  From all the
> searches I've been doing, it looks like GNV$LIBZSHR is the zlib name
> du jour, is that your assessment as well?

   My assessment is that this stuff is where I put it.  Some place like,
say, utility_root:[source.zlib.zlib-1_2_6], where I see LIBZ.OLB,
LIBZ_64.OLB, and libzshr.exe.  I'd need to look more closely to see what
the 32-/64-bit situation is for zlib.  I'd expect only a minority of
victims to have GNV installed, and I don't know its 32-/64-bit
situation, either.

> sms>    3.  Shared images?
> 
> Add "shared" to the Configure line.

   I'll try it (when I get past the too-long-line problem).

>   Generally speaking, I'd love it
> if you had a look at INSTALL, that file covers Unix, Windows and VMS

   Reading further than the first few paragraphs might have helprd in my
case.

> sms>    (I haven't verified it yet, but I believe that the "-010" compiler,
> sms> recently made available to us lowly hobbyists, fixes the 64-bit argv[]
> sms> NULL-termination problems on Alpha.)
> 
> Interesting.  So that would make the hack in [.apps]vms_decc_init.c
> less necessary then?

   It should.  

>   Does keeping that hack in place hurt in any way?

   It'll waste a little time, but not enough to matter.  Probably safer
to leave it in there until the newer compiler diffuses more.  A recent
posting in comp.os.vms said:

      $ cc /version
      HP C V7.3-009 on OpenVMS Alpha V8.3

so it's clearly not yet reached everyone.

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

   Steven M. Schweda               sms at antinode-info
   382 South Warwick Street        (+1) 651-699-9818
   Saint Paul  MN  55105-2547