> Date: Thu, 18 Feb 2010 06:28:04 -0600 (CST)
>
> From: Arpadffy Zoltan <zoltan.arpad...@scientificgames.se>
>
> > Also if it is not too late, it would be nice to add 32 at the end of the
> > sharable images if the are build with 32 bits pointer size (64 is the
> > default).
> >
> > I mean to have like this:
> > LIBCRYPTO32.OLB;1
> > LIBSSL32.OLB;1
> > LIBCRYPTO.OLB;1
> > LIBSSL.OLB;1
> > SSL_LIBCRYPTO_SHR32.EXE;1
> > SSL_LIBSSL_SHR32.EXE;1
> > SSL_LIBCRYPTO_SHR.EXE;1
> > SSL_LIBSSL_SHR.EXE;1
>
> For the record, HP's shareable images look like this:
>
> Directory SYS$COMMON:[SYSLIB]
>
> SSL$LIBCRYPTO_SHR.EXE;1
> SSL$LIBCRYPTO_SHR32.EXE;1
> SSL$LIBSSL_SHR.EXE;1
> SSL$LIBSSL_SHR32.EXE;1
>
> While not entirely trivial, it would be relatively easy to re-jigger
> the VMS builders to use different product-file directories for builds
> with /POINTER_SIZE = 32 and /POINTER_SIZE = 64 ('ARCH = ARCH+ "32"', or
> whatever), and then to produce (and install) the results with
> HP-like names. Also, I know of nothing which would stop users from
> linking (SET FILE /ENTER) any desired old names to the newer (better)
> "SSL_LIB*[32]" names. So, why, exactly, aren't we doing this?
Did I miss the discussion when this was all resolved? Or is no
decision the decision, so it'll all stay as it is (that is, different
from, and not so good as, HP's scheme)?
Other lingering complaints...
"vms/install.com" still hard-codes the procedure's own location
inside OPENSSL_STARTUP.COM, which causes everything to fail if the user
renames the installation directory. I'd prefer that OPENSSL_STARTUP.COM
use its own location to find the installation directory, as previously
suggested.
"makevms.com" still writes architecture-specific stuff into a
generated OPENSSLCONF.H file. I claim that all that stuff could be done
(once) in the "opensslconf.h.in" source file, as previously suggested.
When I last looked, "makevms.com" was still copying various source
and test files around, cluttering/corrupting the original source tree in
an unnecessary attempt to complensate for the lack of symbolic links on
VMS file systems (until recently, at least). Revised builder schemes to
avoid this have been previously suggested.
There are probably more items which belong here, but it's been a
while since I went through this frustrating exercise.
Or would evryone be happier if I just went away? (Or is VMS itself
(even) more of a nuisance than I am?)
------------------------------------------------------------------------
Steven M. Schweda s...@antinode-info
382 South Warwick Street (+1) 651-699-9818
Saint Paul MN 55105-2547
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
