Hello,
I have tested openssl-1.0.1-stable-SNAP-20101215 on IA64, VAX and ALPHA
architectures to build both 32 and 64 bit pointer size libraries and executables
I can happily announce that the build, the test and the installation on IA64
and ALPHA worked perfect, without any problem in all cases.
Finally, we have reached this highly desired status on the most popular
platform IA64 and ALPHA too.
Thank you, Richard for all your effort.
This is a very nice Christmas present - or better Lussekatt :)
On VAX the APPS and ENGINES build fails (please find the correcting patch
below).
However, the tests on VAX that does not use openssl executable pass correctly.
Indeed, there were some informational messages during the 32 bit pointer size
build.
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" an
d a previous declaration specifies "long pointer".
at line number 83 in file
USRDSK:[ZAY.WORK.OPENSSL-101-STABLE-SNAP-20101215.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
USRDSK:[ZAY.WORK.OPENSSL-101-STABLE-SNAP-20101215.CRYPTO]MEM.C;1
static void (*free_locked_func)(void *) = free;
.....................................^
%CC-I-FUNCMIXPTR, In the initializer for free_locked_func, function types
differ because this declaration specifies "short pointer
" and a previous declaration specifies "long pointer".
at line number 98 in file
USRDSK:[ZAY.WORK.OPENSSL-101-STABLE-SNAP-20101215.CRYPTO]MEM.C;1
Also on ALPHA and VAX appear several BADSUBSCRIPT messages like:
nist_set_384(t_d,buf,0,0,0,0,0,0,0,23,23,0,0,0);
........^
%CC-I-BADSUBSCRIPT, In this statement, an array subscript expression is either
less than zero or greater than the largest value that can be represented by
the size_t type.
At line number 747 in
DKA400:[ZOLI.OPENSSL-101-STABLE-SNAP-20101215.CRYPTO.BN]BN_NIST.C;1.
...but I have not experience any effect during tests, usage, linking etc.
A bit weird, that on VAX during APPS build appeared the following text:
Building The SSLTEST Test Program.
SSLTEST Needs A TCP/IP Library. Can't Link. Skipping...
Therefore the OPENSSL executable is not linked.
I have not investigated deeper, but guess it have not found the TCPIP product
libraries by default as it did successfully on other architectures.
...also on VAX the ENGINES build fails because can not find the include files:
Compiling The 4758cca Library Files. (ENGINES)
e_4758cca
#include "hw_4758_cca.h"
.^
%CC-F-NOINCLFILE, Cannot find file "hw_4758_cca.h" specified in #include
directive.
At line number 73 in
DKA400:[ZOLI.OPENSSL-101-STABLE-SNAP-20101215.ENGINES]E_4758CCA.C;1.
#include "hw_4758_cca.h"
.^
%VCG-I-NOBJECT, No object file produced.
At line number 73 in
DKA400:[ZOLI.OPENSSL-101-STABLE-SNAP-20101215.ENGINES]E_4758CCA.C;1.
%LINK-W-NUDFSYMS, 2 undefined symbols:
%LINK-I-UDFSYM, BIND_ENGINE
%LINK-I-UDFSYM, V_CHECK
%LINK-W-USEUNDEF, undefined symbol BIND_ENGINE referenced
in psect $$ENGINE offset %X00000000
in module ENGINE file
DKA400:[ZOLI.OPENSSL-101-STABLE-SNAP-20101215.VAX.OBJ.ENGINES]ENGINE_VECTOR.OBJ;5
In fact none of the include files are found from VENDOR_DEFNS because:
Main C Compiling Command:
CC/OPTIMIZE/NODEBUG/NOLIST/INCLUDE=(SYS$DISK:[],SYS$DISK:[-],SYS$DISK:[.ENGINE.VENDOR_DEFNS])/DEFINE=("
FLAT_INC=1","VAXC",TCPIP_TYPE_NONE,DSO_VMS)
While ALPHA and IA64 correctly used SYS$DISK:[.VENDOR_DEFNS]
The following patch (that adds SYS$DISK:[.VENDOR_DEFNS] to the include path)
fixes this minor problem:
TITAN2_ZAY $ diff <.ENGINES>MAKEENGINES.COM
************
File USRDSK:<ZAY.WORK.OPENSSL-101-STABLE-SNAP-20101215.ENGINES>MAKEENGINES.COM;2
783
"/INCLUDE=(SYS$DISK:[],SYS$DISK:[-],SYS$DISK:[.VENDOR_DEFNS],SYS$DISK:[.ENGINE.VENDOR_DEFNS])"
+ -
784 CCEXTRAFLAGS
******
File USRDSK:<ZAY.WORK.OPENSSL-101-STABLE-SNAP-20101215.ENGINES>MAKEENGINES.COM;1
783
"/INCLUDE=(SYS$DISK:[],SYS$DISK:[-],SYS$DISK:[.ENGINE.VENDOR_DEFNS])" + -
784 CCEXTRAFLAGS
************
************
File USRDSK:<ZAY.WORK.OPENSSL-101-STABLE-SNAP-20101215.ENGINES>MAKEENGINES.COM;2
815
"/INCLUDE=(SYS$DISK:[],SYS$DISK:[-],SYS$DISK:[.VENDOR_DEFNS],SYS$DISK:[.ENGINE.VENDOR_DEFNS])"
+ -
816 CCEXTRAFLAGS
******
File USRDSK:<ZAY.WORK.OPENSSL-101-STABLE-SNAP-20101215.ENGINES>MAKEENGINES.COM;1
815
"/INCLUDE=(SYS$DISK:[],SYS$DISK:[-],SYS$DISK:[.ENGINE.VENDOR_DEFNS])" + -
816 CCEXTRAFLAGS
************
Number of difference sections found: 2
Number of difference records found: 2
Thank you.
Regards,
Z
-----Original Message-----
From: Richard Levitte via RT [mailto:r...@openssl.org]
Sent: den 16 december 2010 01:12
To: Arpadffy Zoltan
Cc: openssl-dev@openssl.org
Subject: [openssl.org #2393] [PATCH] 32/64 bit pointer_size choice in the VMS
build
I've now tested to build with the pointer size arguments "32", "64" and "".
The scripts
appear to do what they should, so I'm resolving this ticket.
However, a warning: with the pointer size specified to "32" or "64", there are
warnings
about pointer size differences (short pointer vs. long pointer), which might
have pretty
serious results. It's an effort of its own to resolve those problems, but I'd
say that
requires separate tickets, as this one was about changes to the build scripts.
--
Richard Levitte
levi...@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
