> 64 Automatic choice of "64" or "64=ARGV".
> 64=ARGV Manual choice of "64=ARGV".
> 64= Manual choice of plain "64".
Seems to be done, and the compiler test activity no longer leaves
junk object and/or listing files lying around. Original (*.*_orig) and
changed files (with VMS version numbers) should be available here:
http://antinode.info/ftp/openssl/1_0_0d/openssl-SNAP-20110321_s1.zip
Changes other than to the than the VMS builders:
crypto/evp/evp_enc.c The fix here (previously discussed on this
list) should already be in the normal code.
apps/openssl.c Reformed argv[] duplication code. (Looks at
VMS_TRUST_ARGV only for 64-bit argv[]. A 32-bit
argv[] with 64-bit other-pointers must always be
duplicated, no matter how trusting the victim may
be.)
ssl/dtls1.h Someone keeps adding stuff like:
/* Unless _XOPEN_SOURCE_EXTENDED is defined, struct timeval will not be
properly defined with DEC C, at least on VMS */
#if defined(__DECC) || defined(__DECCXX)
#define _XOPEN_SOURCE_EXTENDED
#endif
I keep getting compiler complaints because of it:
[...]
Building The SSLTEST Test Program.
#define _XOPEN_SOURCE_EXTENDED 1 /* Or gethostname won't be declared properly
................................^
%CC-W-MACROREDEF, The redefinition of the macro "_XOPEN_SOURCE_EXTENDED"
conflicts with a current definition because the replacement lists
differ. The redefinition is now in effect.
at line number 189 in file
IT$DKC0:[UTILITY.SOURCE.OPENSSL.openssl-SNAP-20110321.ssl]ssltest.c;1
[...]
So I keep taking it out. I need more info than "DEC C, at least on VMS"
to understand what the problem is, wherever it is, if there actually is
one. I don't see it around here, where the "cure" always seems to be
worse than the disease.
util/libeay.num As usual, these guys were mismatched with
util/ssleay.num reality, especially where VMS uses shortened
names ("crypto/symhacks.h"). (And we ain't got
no 128-bit integers, so "EC_GFp_nistp224_method"
had to be tossed out.) I added a helpful comment
section at the end of each file, and enhanced
"VMS/mkshared.com" to include the concept of a
comment, so that it could ignore these new
comments. If these ".num" files are actually
created automatically, then these changes may
make little sense. Similarly, if there's some
other consumer who reads these files, then he
needs to ignore the comments, too. (Or else, the
comments need to be removed, but if these files
are being hand-edited (carelessly), then it's
just possible that some comments might save us
from some of these recurring shortened-name
problems.
I've tested these VMS builders with every pointer-size option ("",
"32", "64", "64=", and "64=ARGV"), and the results look good on Alpha
and IA64, except for one harmless quirk for which I blame HP. As I read
the docs, an explicit /POINTER_SIZE=32 option should be equivalent to
the default, /NOPOINTER_SIZE, but stuff in <stdlib.h> causes some
(spurious, I claim) info messages, like:
[...]
Compiling The mem.c File. (LIBRARY,LIB)
static void *(*realloc_func)(void *, size_t)= realloc;
..................................^
%CC-I-FUNCMIXPTR, In the initializer for realloc_func, function types
differ because this declaration specifies "short pointer" and a previous
declaration specifies "long pointer".
at line number 83 in file
IT$DKC0:[UTILITY.SOURCE.OPENSSL.openssl-SNAP-20110321.crypto]mem.c;1
static void (*free_func)(void *) = free;
..............................^
%CC-I-FUNCMIXPTR, In the initializer for free_func, function types
differ because this declaration specifies "short pointer" and a previous
declaration specifies "long pointer".
at line number 90 in file
IT$DKC0:[UTILITY.SOURCE.OPENSSL.openssl-SNAP-20110321.crypto]mem.c;1
[...]
More compiler bug info:
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1474331
The complaints are only informational ("-I-"), so the build procedure
is unaffected, and the stuff works, so they don't seem to matter much,
and any sane victim will say "" instead of "32", so the whole annoyance
should never be noticed, but you heard it here first.
It's supposed to snow here, so I'll fire up the VAX, and verify that
all is still well there. (What could go wrong? If the power stays up
for a couple of days, that is.)
SMS.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
