[openssl-dev] Upcoming build system change

Richard Levitte levitte at openssl.org
Tue Feb 9 07:41:37 UTC 2016


In message <16020900205830_2020AB3E at antinode.info> on Tue, 9 Feb 2016 00:20:58 -0600 (CST), "Steven M. Schweda" <sms at antinode.info> said:

sms> > - Perl!  Reports tell me that version 5.10.1 works fine [...]
sms> 
sms>    Perhaps, but around here, the current version fails pretty badly:
sms> 
sms> ALP $ perl --version
sms> 
sms> This is perl 5, version 22, subversion 1 (v5.22.1) built for
sms> VMS_AXP

In my case:

    $ perl --version
    
    This is perl 5, version 20, subversion 1 (v5.20.1) built for VMS_AXP

I sure hope things haven't gone for the worse...

sms>    The generated descrip.mms is defective.  It starts out reasonable,
sms> with stuff like:
sms> 
sms> SRCDIR=DISK$UTIL5ALPX:[UTILITY.SOURCE.OPENSSL.openssl-refactor-build]
sms> BUILDDIR=DISK$UTIL5ALPX:[UTILITY.SOURCE.OPENSSL.openssl-refactor-build]
sms> 
sms> but many (supposedly relative) derived paths are bad.  For example:
sms> 
sms>         DEFINE SRCTOP [-.DISK$UTIL5ALPX.UTILITY.SOURCE.OPENSSL.openssl-refactor-build]
sms>         DEFINE BLDTOP [-.DISK$UTIL5ALPX.UTILITY.SOURCE.OPENSSL.openssl-refactor-build]
sms>         $(PERL) [-.DISK$UTIL5ALPX.UTILITY.SOURCE.OPENSSL.openssl-refactor-build.test]run_tests.pl $(TESTS)

That's...  bad.

I would like three things from you:

1. The configuration command line you used.
2. configdata.pm (it's produced by Configure)
3. descrip.mms

("We are the Spanish Inquisition...")

sms> copy-certs :
sms>         @ IF F$SEARCH("[.DISK$UTIL5ALPX.UTILITY.SOURCE.OPENSSL.openssl-refactor-build]certs.dir") .EQS. "" THEN -
sms>              CREATE/DIR [.DISK$UTIL5ALPX.UTILITY.SOURCE.OPENSSL.openssl-refactor-build.certs]
sms> 
sms> and so on.  With all this device-directory confusion ("DISK$UTIL5ALPX:"
sms> v. "[.DISK$UTIL5ALPX]"), failures come thick and fast.
sms> 
sms>    Apparently, all the realpath() and abs2rel() stuff does horrible
sms> things on VMS in some circumstances (like mine).

It seems there are circumstances I haven't tested (yet).  Although, I
recall having some (unrelated) trouble with realpath(), that might be
something for me to look into.

sms> My default device:[directory] spec does not include the DISK$volume_label device
sms> name:
sms> 
sms> ALP $ show default
sms>   UTILITY5_DEV:[UTILITY.source.openssl.openssl-refactor-build]

Was this the directory you configured and built in as well?
(I'm asking, because Configure now supports building outside of the
source directory)

sms> ALP $ show logical UTILITY5_DEV
sms>    "UTILITY5_DEV" = "ALP$DKC100:" (LNM$SYSTEM_TABLE)
sms> 
sms> ALP $ show logical DISK$UTIL5ALPX
sms>    "DISK$UTIL5ALPX" = "ALP$DKC100:" (LNM$SYSTEM_TABLE)
sms> 
sms>    If there's a requirement to use the DISK$volume_label device name,
sms> then there needs to be some (seriously restrictive and/or confusing)
sms> documentation, or else some improved automation to set it as required.

No such requirement.  Configure is supposed to figure things out from
your default directory and other given data.

sms>    Knowing approximately nothing about Perl, I'm ill-equipped to
sms> contribute much more to this discussion than complaints about how badly
sms> it works, but I'm open to requests for details or more testing.

Thanks.

sms> For a little recent, related Perl-on-VMS discussion, there's a thread on
sms> comp.os.vms: 
sms> 
sms> https://groups.google.com/forum/#!topic/comp.os.vms/npJUbALe9Lo

(Oh my, I haven't approached Usenet or whatever it has become in ages)

sms>    I fetched my openssl-refactor-build.zip kit around 14-JAN-2016, so if
sms> significantly changes were made since then, then I don't know about
sms> them.

Things have changed a bit, it might be that a newer fetch clears
things up.  Not going to guarantee it, though, so let me check through
the stuff I hope you'll send me first.

sms> >     ! There is no install target yet.
sms> >     ! As a matter of fact, I'd like to talk about exactly where it
sms> >     ! should install.  Let's talk!
sms> 
sms>    Because VMS lacks a popular default localtion (like /usr/local), I
sms> suggest asking the victim where he'd like it.

Actually, from looking at what the vms-ports folks do, it seems that
SYS$COMMON:['name'...] is a popular location

sms> > Feedback welcome!
sms> 
sms>    I'm almost always willing to complain.

Heh ;-)

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


More information about the openssl-dev mailing list