From: Richard Levitte <levi...@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@antinode-info
382 South Warwick Street (+1) 651-699-9818
Saint Paul MN 55105-2547
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
