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

[Richard Levitte]

In message <16032022082387_202140C6 at antinode.info> on Sun, 20 Mar 2016 22:08:23 -0500 (CDT), "Steven M. Schweda" <sms at antinode.info> said:

sms>    1.  An attempt to build on VMS Alpha V8.4 died when MMS choked on a
sms> too-long command:
sms> 
sms> [...]
sms> PURGE [.crypto.evp]digest.OBJ
sms> SET DEFAULT ALP$DKC100:[UTILITY.SOURCE.OPENSSL.openssl-master_2016-03-20.crypto.evp]
sms> CC/DECC /DEFINE=(OPENSSL_THREADS,OPENSSL_NO_DYNAMIC_ENGINE,OPENSSL_PIC,OPENSSLDIR="""SYS$COMMON:[SSL]""",ENGINESDIR="""OSSL$ENGINES:""") /STANDARD=RELAXED/NOLIST/PREFIX=ALL/NAMES=(AS_IS,SHORTENED) /OPTIMIZE/NODEBUG/INCLUDE=(utility5_dev:[UTILITY.source-
sms> .openssl.openssl-master_2016-03-20.include],ALP$DKC100:[UTILITY.SOURCE.OPENSSL.openssl-master_2016-03-20],ALP$DKC100:[UTILITY.SOURCE.OPENSSL.openssl-master_2016-03-20.crypto.include],ALP$DKC100:[UTILITY.SOURCE.OPENSSL.openssl-master_2016-03-20.include]-
sms> ,utility5_dev:[UTILITY.source.openssl.openssl-master_2016-03-20.crypto.include],ALP$DKC100:[UTILITY.SOURCE.OPENSSL.openssl-master_2016-03-20.crypto],ALP$DKC100:[UTILITY.SOURCE.OPENSSL.openssl-master_2016-03-20.crypto.modes]) /MMS=(FILE=utility5_dev:[-
sms> UTILITY.source.openssl.openssl-master_2016-03-20.crypto.evp]e_aes.tmp-MMS,TARGET=[.crypto.evp]e_aes.OBJ) /OBJECT=utility5_dev:[UTILITY.source.openssl.openssl-master_2016-03-20.crypto.evp]e_aes.OBJ /REPOSITORY=utility5_dev:[UTILITY.source.openssl.-
sms> openssl-master_2016-03-20] e_aes.c
sms> %MMS-F-EXETOOBIG, Command too large.  Maximum length is 1019 characters.

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.

sms>    I haven't tried to see how this stuff is generated nowadays,

A combination of information from the build.info files, the .conf
files in [.Configurations] and [.Configurations]descrip.mms.tmpl.

sms> but I'd say that it could use more of at least one of the following:
sms>       logical names  (one rooted for the top-level dir?)

I'm starting to consider that.

sms>       continuation lines

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

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).

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.

sms>    2.  What's the status of zlib support on VMS?  In the old days,
sms> makevms.com had a place to specify a zlib directory.  Is there a way in
sms> the new scheme?  (Documented anywhere?)  All I found was the
sms>       OPTIONS= [...] no-zlib no-zlib-dynamic
sms> in descrip.mms.

There are two, and you're right that they aren't documented (I'm
looking through documentation this week but may be staring myself
blind, so any pointers of the "hey, please remeber to document {blah}"
form is appreciated):

    --with-zlib-include=INCDIR
    --with-zlib-lib=LIBDIR

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?
    
sms>    3.  Shared images?

Add "shared" to the Configure line.  Generally speaking, I'd love it
if you had a look at INSTALL, that file covers Unix, Windows and VMS

sms>    For the record:
sms> 
sms> ALP $ mms /id
sms> %MMS-I-IDENT, MMS V3.8-2 © Copyright 2007 Hewlett-Packard Development Company, L
sms> .P.
sms> 
sms> ALP $ cc /version
sms> HP C V7.3-010 on OpenVMS Alpha V8.4    
sms> 
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?  Does keeping that hack in place hurt in any way?

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/