>>> * Tru64 cc(1) can't preprocess stdin; it needs a file >> You can't make such broad statement, as it was verified to work on >> 5.x. > > Well, it doesn't work for 5.1: > > $ uname -a > OSF1 darkstar V5.1 732 alpha > $ echo __osf__ | cc -E - > cc: Error: No source or object files specified on the command line > > It might be 5.1A or 5.1B-* that can do this.
Or it's more likely that we're formulating it wrong. In sense that it's not OS, but *compiler* version that is crucial. It was tested with V6.5. >>> * I'm not sure why tee(1) was being used here, but I removed it so >>> that it doesn't mask a potential error from the preprocessor >> 'tee' is there because without compilation was failing on multi-CPU >> Tru64 5.x system. Yes, it masks exit code, but it was mask or get >> nothing. > > Is there an e-mail thread discussing that somewhere? No. I was struggling with it from the beginning and it simply was a compromise kludge. > You might want to have a "test -s" in there or something---I was > originally getting link errors as the .s files were empty due to the > "cc -E -" error going uncaught. I do understand the limitations, and the nature of reply was not "won't fix", but mere answer to specific question "why tee is there". >>> * Tru64 has AF_INET6 and PF_INET6, but no sockaddr_in6; >> Too broad statement again, it was tested on Tru64 5.x and sockaddr_in6 >> were there :-) > > Yes, 5.1 has it. > >>> checking for an additional IPv6 symbol here is enough to get the >>> correct result >> Question is how does it affect other systems. Meanwhile I'd suggest to >> configure with explicit -DOPENSSL_USE_IPV6=0, i.e. pass it as extra >> argument to ./config. > > I do see now that 5.1 doesn't have IPPROTO_IPV6, so that's probably not > the best symbol to use as an additional check. Maybe AI_NUMERICHOST? Question is not how does it affect other Tru64 systems, but *all* other systems. >>> as1: Error: pre-ghash-alpha.s, line 557: Redefinition of symbol: rem_4bit >>> as1: Error: pre-ghash-alpha.s, line 566: Redefinition of symbol: rem_4bit >>> *** Exit 1 >> Please double-check >> http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=d24d1d7daf515aa19fbf18f6371e3e617028a07c. > > But then when I run the complete test suite, I get this: > > Testing cipher id-aes128-GCM(encrypt/decrypt) > Key > 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > IV > 0000 00 00 00 00 00 00 00 00 00 00 00 00 > Plaintext > Ciphertext > Tag > 0000 58 e2 fc ce fa 7e 30 61 36 7f 1d 57 a4 e7 45 5a > Unaligned access pid=20271 <evp_test> va=0x12010b11c pc=0x12010b160 > ra=0x1200cc978 inst=0xa51b0000 > Unaligned access pid=20271 <evp_test> va=0x12010b11c pc=0x12010b1b0 > ra=0x1200cc978 inst=0xa51b0000 > Unaligned access pid=20271 <evp_test> va=0x12010b11c pc=0x12010b1f0 > ra=0x1200cc978 inst=0xa51b0000 > [several more "Unaligned access" lines] > Tag mismatch > Got > 0000 17 ad e0 00 49 56 34 fa 75 46 59 89 5b 18 ba a1 > Expected > 0000 58 e2 fc ce fa 7e 30 61 36 7f 1d 57 a4 e7 45 5a > *** Exit 9 > Stop. Oh! It was late yesterday and ghash-alpha.pl modification was apparently a bad call. http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=33446493f4ccd26562431b25fad304cfe857c887 > (This is with git 96180cac plus the changes I submitted earlier) As for remaining changes. The answer is not "won't fix", but "will be considered more carefully and [not necessarily originally suggested] action will be taken." ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
