> Looks like it is still there in 1.0.0g Right, modification made to 1.0.1 as focus was on beta...
> Again, it's an alignment issue of function pointers put into an array > processed by the C-runtime normally used for doing things like global > constructors. I actually have hard time imagining how misalignment can actually happen. Even if x86_64cpuid.asm aligns .CRT$XCU at DWORD, it's *appended* to segment aligned at QWORD *and* contains QWORD itself. Therefore it shouldn't disrupt alignment. And I can't reproduce the problem with openssl.exe and any of the test programs [produced with nt.mak]. Can you confirm that it fails in say openssl.exe or are you referring to your [or 3rd party] application that is failing? The only scenario I can imagine is that some other object module specifies unaligned .CRT prior $XCU and places DWORD there, thus disrupting the alignment. But if this is the case, then it's more important to fix actually guilty one... If openssl.exe crashes, can you submit map file? Add /m to LFLAGS in nt.mak... > Its in crypto/perlasm/x86_64-xlate.pl:558 > Currently: > $v.=" READONLY DWORD"; > Should be: > $v.=" READONLY ALIGN(8)"; For reference, the original reason for sticking to DWORD was because initial ml64 versions didn't understand ALIGN(N). So that formally solution should be to choose between DWORD and ALIGN(8) depending on assembler version [and pray for DWORD to work with old version], see http://cvs.openssl.org/chngview?cn=22061. And in case of doubt use nasm, which is actually preferred option. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
