1

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.)

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.

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.

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.

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.

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.)

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.

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.

Thanks so much to anyone who might be able to help debug this issue!

BDJ
  • 21
  • 1
  • 4

1 Answers1

1

OK, so the answer to this question appears to be a little of both. Yes, there does appear to be some more work to do with the assembler version of the 64-bit version of OpenSSL 1.0.1e. And, yes, there is a work-around for the time being that should have been obvious.

Using the no-asm instruction where I was using no-shared in the perl Configuration step above.

This, of course, tells OpenSSL that we are not building assembler libs, so it will compile in the C code instead. Problem solved!

Thanks, Eric and Tim, for this very valuable software library that you provide to the rest of us for free!

BDJ
  • 21
  • 1
  • 4
  • i'm trying to compile openssl on win 7 for 64 bit as well, like you i used the x86_amd64 env. i finally got it to work but i get duplicate symbols for bn_mul_mont, it resides in the c file bn_asm.c and in x86_64-mont.asm which both are used for compiling libeay32.lib. the functio in the C code is protected by #ifdef, but the assembly code is not (if it even can) and also there's no code in the makefile to prevent the assembly code from compiling. So i'm not sure what should have happen, this of course will happen when you include no-asm in the configure script. Any ideas ? – codeScriber Apr 23 '13 at 06:32