Hi, > Hello, I built OpenSSL 1.0.1j this way, which in the case of x86 I have > done with some previous versions as well: > > x86: > perl Configure debug-VC-WIN32 enable-static-engine > ms\do_ms > nmake -f ms\ntdll.mak > > x64: > perl Configure debug-VC-WIN64A enable-static-engine > ms\do_win64a > nmake -f ms\ntdll.mak > > In both cases the makefile uses MASM to compile the assembly. The > INSTALL.W32 seems to contradict that though because it says NASM is the > only supported assembler.
Where is contradiction? It says "the only supported", not "the only working". But don't get this as masm is supposed to work, only as masm *might* work, and if you choose to rely on it, question whether or not all platforom-specific paths are compiled and work as they should on processor other than one you ran test on will remain open. Also note that INSTALL.W32 applies to 32-bit build. In 64-bit case masm support is not explicitly disclaimed, but it's not a priority. > And in the case of x86 do_ms passes arg > 'no-asm' to mk1mf.pl but that doesn't seem to do anything, and I'm not > sure if that's intentional. All tests pass for both x86 and x64. What is > the latest information on whether or not MASM is supported for x86 and > x64 targets? I found an interesting discussion from earlier this year, > but that's all [1]. It's still same: when in doubt use nasm. In 64-bit case, it's sufficient to place it somewhere on the %PATH% prior running do_win64a. Advantage of using nasm kind of results from what is said above: nasm will compile code covering most platforms even with older Studio. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
