Hello, It is interesting that not forcing the /pointer_size=64 - the build is OK (by running @makevms all "" nodebug)
Until now, I believed that DCC will use 64-bit pointers on a 64-bit architecture when the pointer size is not explicitly specified. LIBCRYPTO.OLB;3 12952 15-FEB-2011 11:40:04.66 (/pointer_size not specified - everything is OK) LIBCRYPTO.OLB;2 12501 10-FEB-2011 18:28:46.78 (/pointer_size=64 FAILED) LIBCRYPTO32.OLB;2 12404 15-FEB-2011 11:40:05.13 (/pointer_size=32) LIBCRYPTO32.OLB;1 12404 10-FEB-2011 18:28:47.14 (/pointer_size=32) Seems, there is some kind of smart cast around descriptors when not explicitly specified that the pointers' size is 64-bit. It is time to dig deeper into the literature. Regards, Z -----Original Message----- From: Steven M. Schweda [mailto:s...@antinode.info] Sent: den 14 februari 2011 19:52 To: openssl-dev@openssl.org Subject: Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS From: "Arpadffy Zoltan via RT" <r...@openssl.org> > I have tested 1.0.0d release on OpenVMS and found many warnings during th= > e build with 64bits pointer size that produced many annoying warning mess= > ages during linking against the library - like: > > Building The BNTEST Test Program. > %ILINK-W-COMPWARN, compilation warnings > module: DSO_VMS > file: USRDSK:[ZAY.WORK.OPENSSL-100D.IA64.EXE.CRYPTO]LIBCRYPTO.OLB= > ;1 You get the LINK warning bacause you didn't fix the compiler warnings. > Unfortunately the 64bit pointer size build on ALPHA has the very same fai= > l. > Compaq C V6.4-008 on OpenVMS Alpha V7.3-2 That's not _un_fortunate, that's _fortunate_. _Un_fortunate would be if you got results on Alpha which differed from those on IA64. > Compiling The o_dir.c File. (LIBRARY,LIB) > > (*ctx)->filespec_dsc.dsc$a_pointer =3D (*ctx)->filespec; > ...........................................^ > %CC-W-MAYLOSEDATA2, In this statement, "(*ctx)->filespec" has a larger da= > ta size > than "short pointer to char". Assignment can result in data loss. > at line number 121 in file USRDSK:[ZAY.WORK.OPENSSL-100D.CRYPTO]LPDIR_VMS= > .C;1 Well, yeah. I'd expect a complaint every time you use a 32-bit descriptor in a 64-bit-pointer environment. While I've never used one, I assume that that's why 64-bit descriptors exist, and I'd guess that you'll need to fix all the (VMS-specific) code which uses descriptors. Knowing nothing, I'd assume that you'd need to add some 64-bit-descriptor declarations, contitional on __INITIAL_POINTER_SIZE ("if __INITIAL_POINTER_SIZE == 64", say). With any luck, the consumers of these descriptors might accept either descriptor type. > setvbuf(in, NULL, _IONBF, 0); /* don't do buffered reads */ > ..................^ > %CC-W-MAYLOSEDATA2, In this statement, "in" has a larger data size than "= > short p > ointer to short pointer to struct _iobuf". Assignment can result in data= > loss. > at line number 147 in file USRDSK:[ZAY.WORK.OPENSSL-100D.CRYPTO.RAND]RAND= > FILE.C; Apparently (<stdio,h>), setvbuf() is in the category of "functions and declarations which do not support 64 bit pointers being passed (or returned)." I'd guess that you'll need to disable that code on VMS, at least when 64-bit pointers are used. (It may be unwise to have the behavior on VMS depend on the pointer size, so it might be better to disable it always on VMS.) Any such change should include a good explanation in its comments. ------------------------------------------------------------------------ Steven M. Schweda sms@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 ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
