title: Building OpenSSL VC++ Static 64bit Libs
body: <p>I am attempting to build OpenSSL 1.0.1e static 64-bit libs with VC++ 2010. (The last one that I successfully built like this was 1.0.1c, if that might be a factor. And currently I am also able to successfully build the 32-bit flavor of 1.0.1e with no problems.)</p>
  
  <p>I am using ActiveState Perl, nasm, and all the correct tools to do this build, I believe. The INSTALL.W64 file only has instructions for building the DLL, which unfortunately I cannot use.</p>
  
  <p>I am calling the proper "%VS100COMNTOOLS%....\vc\bin\x86_amd64\vcvarsx86_amd64.bat" to set up the environment, and I am making sure that ActivePerl is on the beginning of my path.</p>
  
  <p>I am deleting all the old inc* (except "include" of course), tmp* and out* folders before trying to build. I call "perl Configure no-shared VC-WIN64A" as I did in the past; although, I notice that no-shared seems to be the default in this version. I am editing the ms\do_win64a.bat and changing no-asm to nasm, as I have in previous versions.</p>
  
  <p>Then I run ms\do_win64a.bat, and edit the resulting ms\nt.mak files to change "32" to "64" in part to keep my 64-bit builds from clobbering my 32-bit builds. I also change /MD to /MT (as I have always done in the past), again, for my specific build environment requirements.</p>
  
  <p>Then I run ms\nt.mak. This seems to build all the sources with only a few warning messages, but when the makefile tries to compile libeay32.lib, I get an " unresolved external symbol bn_GF2m_mul_2x2 referenced in function BN_GF2m_mod_mul_arr." (This is in crypto\bn\bn_gf2m.c source code.)</p>
  
  <p>So I know this is because OPENSSL_BN_ASM_GF2m is defined in my CFLAG in nt.mak, and if I understood Perl programming a little better, I could probably track down which configuration option I am not seeing, but right now I just can't figure it out.</p>
  
  <p>Again, 32-bit seems to work just fine following very similar build instructions. I wonder if possibly the venerable Eric Young and Tim Hudson have not had time to test this particular build configuration, or if it is something completely silly that I am overlooking.</p>
  
  <p>Thanks so much to anyone who might be able to help debug this issue!</p>