Building with SSL on Windows - Linker errors

1,723 views
Skip to first unread message

Ed Norris

unread,
May 8, 2013, 11:29:22 AM5/8/13
to mongod...@googlegroups.com
I've been following the instructions on http://www.mongodb.org/about/tutorial/build-mongodb-with-visual-studio-2010/, basically

1. Install Git 1.8.1.2
2. Install Python 2.7.3
3. Install OpenSSL-Win64-1.0.1e
4. Download source
5. Run "scons --ssl" from the mongo source directory

That gives " fatal error C1083: Cannot open include file: 'openssl/ssl.h': No such file or directory" so I found https://jira.mongodb.org/browse/BUILDBOT-193 and modified the command line to

scons --ssl --extrapath=c:\openssl-win64

That failed for me with "error C2065: '_WIN32_WINNT_VISTA' : undeclared identifier", so after a bit of googling I realized that this line from the scons output was key "Windows SDK Root 'C:/Program Files/Microsoft SDKs/Windows/v6.0a'".  That's an older version of the Windows SDK, so I modified the command line to

scons --ssl --extrapath=C:\OpenSSL-Win64 --cpppath="c:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Include"

Which compiles but fails to link, showing these errors

sock.obj : error LNK2001: unresolved external symbol _ERR_error_string
sock.obj : error LNK2001: unresolved external symbol _SSL_get_error
sock.obj : error LNK2001: unresolved external symbol _SSL_shutdown
sock.obj : error LNK2001: unresolved external symbol _SSL_write
sock.obj : error LNK2001: unresolved external symbol _SSL_free
sock.obj : error LNK2001: unresolved external symbol _SSL_read
sock.obj : error LNK2001: unresolved external symbol _ERR_get_error
ssl_manager.obj : error LNK2001: unresolved external symbol _SSL_get_verify_result
ssl_manager.obj : error LNK2001: unresolved external symbol _SSLv23_method
ssl_manager.obj : error LNK2001: unresolved external symbol _SSL_CTX_set_session_id_context
ssl_manager.obj : error LNK2001: unresolved external symbol _SSL_CTX_ctrl
ssl_manager.obj : error LNK2001: unresolved external symbol _ERR_error_string_n
ssl_manager.obj : error LNK2001: unresolved external symbol _SSL_CTX_get_cert_store
ssl_manager.obj : error LNK2001: unresolved external symbol _SSL_accept
[snip]

I've checked that the include directory looks correct - /LIBPATH:C:\OpenSSL-Win64\lib - and the scons command line is actually looking for the OpenSSL lib files libeay32.lib and ssleay32.lib, AND that C:\OpenSSL-Win64\lib\ssleay32.lib & libeay32.lib are being read by link.exe (using procmon to check disk activity).

Any ideas?  I'm out of them right now...

I'm on Windows 7 64 bit, using Visual Studio 2010, compiling Mongo 2.4.3 with OpenSSL 1.0.1e (from the Win64OpenSSL-1_0_1e.exe installer)

Thanks,
Ed



Andrew Morrow

unread,
May 8, 2013, 12:34:24 PM5/8/13
to mongod...@googlegroups.com
On Wed, May 8, 2013 at 11:29 AM, Ed Norris <ed.norr...@gmail.com> wrote:
I've been following the instructions on http://www.mongodb.org/about/tutorial/build-mongodb-with-visual-studio-2010/, basically

1. Install Git 1.8.1.2
2. Install Python 2.7.3
3. Install OpenSSL-Win64-1.0.1e
4. Download source
5. Run "scons --ssl" from the mongo source directory


What version of Scons? I'd recommend using SCons 2.3.0 if at all possible.
 
That gives " fatal error C1083: Cannot open include file: 'openssl/ssl.h': No such file or directory" so I found https://jira.mongodb.org/browse/BUILDBOT-193 and modified the command line to

scons --ssl --extrapath=c:\openssl-win64

Are you intending a 64 bit build? Based on the name of the SSL library I'm guessing yes, in which case I'd recommend adding --64 to the build line. You should also specify --release, unless you want a debug build.
 

That failed for me with "error C2065: '_WIN32_WINNT_VISTA' : undeclared identifier", so after a bit of googling I realized that this line from the scons output was key "Windows SDK Root 'C:/Program Files/Microsoft SDKs/Windows/v6.0a'".  That's an older version of the Windows SDK, so I modified the command line to

The complaint about _WIN32_WINNT_VISTA is a known defect: https://jira.mongodb.org/browse/SERVER-9408.
 

scons --ssl --extrapath=C:\OpenSSL-Win64 --cpppath="c:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Include"

I'm not sure this is sufficient, but, more importantly, the SConstruct should be locating SDK v7.0A if that is where it is installed:


I'm not saying it is directly relevant to your problem, but I'd definitely recommend figuring out why the SDK location logic isn't finding the newer SDK, and repairing that, before going further.
 

Which compiles but fails to link, showing these errors

sock.obj : error LNK2001: unresolved external symbol _ERR_error_string
sock.obj : error LNK2001: unresolved external symbol _SSL_get_error
sock.obj : error LNK2001: unresolved external symbol _SSL_shutdown
sock.obj : error LNK2001: unresolved external symbol _SSL_write
sock.obj : error LNK2001: unresolved external symbol _SSL_free
sock.obj : error LNK2001: unresolved external symbol _SSL_read
sock.obj : error LNK2001: unresolved external symbol _ERR_get_error
ssl_manager.obj : error LNK2001: unresolved external symbol _SSL_get_verify_result
ssl_manager.obj : error LNK2001: unresolved external symbol _SSLv23_method
ssl_manager.obj : error LNK2001: unresolved external symbol _SSL_CTX_set_session_id_context
ssl_manager.obj : error LNK2001: unresolved external symbol _SSL_CTX_ctrl
ssl_manager.obj : error LNK2001: unresolved external symbol _ERR_error_string_n
ssl_manager.obj : error LNK2001: unresolved external symbol _SSL_CTX_get_cert_store
ssl_manager.obj : error LNK2001: unresolved external symbol _SSL_accept
[snip]

I've checked that the include directory looks correct - /LIBPATH:C:\OpenSSL-Win64\lib - and the scons command line is actually looking for the OpenSSL lib files libeay32.lib and ssleay32.lib, AND that

Can you post the directory listing of the lib directory? Also the 'dumpbin /exports' of the libraries in there might be useful.  
 
 C:\OpenSSL-Win64\lib\ssleay32.lib & libeay32.lib are being read by link.exe (using procmon to check disk activity).

It is a little hard to tell without more information. Can you please post the actual link line that is failing? You can omit the long list of .o files to make it more readable.
 

Any ideas?  I'm out of them right now...

I'm on Windows 7 64 bit, using Visual Studio 2010, compiling Mongo 2.4.3 with OpenSSL 1.0.1e (from the Win64OpenSSL-1_0_1e.exe installer)

Thanks,
Ed



--
--
You received this message because you are subscribed to the Google
Groups "mongodb-user" group.
To post to this group, send email to mongod...@googlegroups.com
To unsubscribe from this group, send email to
mongodb-user...@googlegroups.com
See also the IRC channel -- freenode.net#mongodb
 
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Ed Norris

unread,
May 8, 2013, 2:16:41 PM5/8/13
to mongod...@googlegroups.com


On Wednesday, May 8, 2013 12:34:24 PM UTC-4, acm wrote:



On Wed, May 8, 2013 at 11:29 AM, Ed Norris <ed.norr...@gmail.com> wrote:
I've been following the instructions on http://www.mongodb.org/about/tutorial/build-mongodb-with-visual-studio-2010/, basically

1. Install Git 1.8.1.2
2. Install Python 2.7.3
3. Install OpenSSL-Win64-1.0.1e
4. Download source
5. Run "scons --ssl" from the mongo source directory


What version of Scons? I'd recommend using SCons 2.3.0 if at all possible.

Thanks for the reply!

It's 2.3.0 
 
That gives " fatal error C1083: Cannot open include file: 'openssl/ssl.h': No such file or directory" so I found https://jira.mongodb.org/browse/BUILDBOT-193 and modified the command line to

scons --ssl --extrapath=c:\openssl-win64

Are you intending a 64 bit build? Based on the name of the SSL library I'm guessing yes, in which case I'd recommend adding --64 to the build line. You should also specify --release, unless you want a debug build.

I was intending to make a 64-bit build of Mongo - I'll add those two options to the scons command. 

 

That failed for me with "error C2065: '_WIN32_WINNT_VISTA' : undeclared identifier", so after a bit of googling I realized that this line from the scons output was key "Windows SDK Root 'C:/Program Files/Microsoft SDKs/Windows/v6.0a'".  That's an older version of the Windows SDK, so I modified the command line to

The complaint about _WIN32_WINNT_VISTA is a known defect: https://jira.mongodb.org/browse/SERVER-9408.
 

scons --ssl --extrapath=C:\OpenSSL-Win64 --cpppath="c:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Include"

I'm not sure this is sufficient, but, more importantly, the SConstruct should be locating SDK v7.0A if that is where it is installed:


I'm not saying it is directly relevant to your problem, but I'd definitely recommend figuring out why the SDK location logic isn't finding the newer SDK, and repairing that, before going further.

Well this is interesting, I have the following SDK directories on my system:

C:\Program Files\Microsoft SDKs\Windows\v6.0A
C:\Program Files (x86)\Microsoft SDKs\Windows\v5.0
C:\Program Files (x86)\Microsoft SDKs\Windows\v6.0A
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A

So it's finding the 64-bit 6.0A before the 32-bit 7.0A.  I'm not sure how or why that happened, but I've changed SConstruct to check 32-bit first (I have to support a bunch of different Visual Studio solutions so I can't really uninstall anything)

 

Which compiles but fails to link, showing these errors

sock.obj : error LNK2001: unresolved external symbol _ERR_error_string
sock.obj : error LNK2001: unresolved external symbol _SSL_get_error
sock.obj : error LNK2001: unresolved external symbol _SSL_shutdown
sock.obj : error LNK2001: unresolved external symbol _SSL_write
sock.obj : error LNK2001: unresolved external symbol _SSL_free
sock.obj : error LNK2001: unresolved external symbol _SSL_read
sock.obj : error LNK2001: unresolved external symbol _ERR_get_error
ssl_manager.obj : error LNK2001: unresolved external symbol _SSL_get_verify_result
ssl_manager.obj : error LNK2001: unresolved external symbol _SSLv23_method
ssl_manager.obj : error LNK2001: unresolved external symbol _SSL_CTX_set_session_id_context
ssl_manager.obj : error LNK2001: unresolved external symbol _SSL_CTX_ctrl
ssl_manager.obj : error LNK2001: unresolved external symbol _ERR_error_string_n
ssl_manager.obj : error LNK2001: unresolved external symbol _SSL_CTX_get_cert_store
ssl_manager.obj : error LNK2001: unresolved external symbol _SSL_accept
[snip]

I've checked that the include directory looks correct - /LIBPATH:C:\OpenSSL-Win64\lib - and the scons command line is actually looking for the OpenSSL lib files libeay32.lib and ssleay32.lib, AND that

Can you post the directory listing of the lib directory? Also the 'dumpbin /exports' of the libraries in there might be useful.  

 C:\OpenSSL-Win64\lib contains
  1,876 4758cca.lib
  1,824 aep.lib
  1,866 atalla.lib
  1,840 capi.lib
  1,840 chil.lib
  1,866 cswift.lib
  1,824 gmp.lib
  1,840 gost.lib
780,164 libeay32.lib
  1,850 nuron.lib
  1,876 padlock.lib
 66,342 ssleay32.lib
  1,892 sureware.lib
  1,850 ubsec.lib

ssleay32.lib dumpbin is here:  http://pastebin.com/M5R5vB9i
libeay32.lib dumpbin is here: http://pastebin.com/y8Mmj7da



 
 C:\OpenSSL-Win64\lib\ssleay32.lib & libeay32.lib are being read by link.exe (using procmon to check disk activity).

It is a little hard to tell without more information. Can you please post the actual link line that is failing? You can omit the long list of .o files to make it more readable.

Here's the full command where the link fails.  I've snipped out both lists of obj files and most of the link errors for clarity.

C:\Dev\mongo>scons --ssl --extrapath=c:\openssl-win64 --cpppath="c:\program files (x86)\Microsoft SDKs\Windows\v7.0A\Include"
scons: Reading SConscript files ...
scons version: 2.3.0
python version: 2 7 3 'final' 0
found visual studio at c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN
Windows SDK Root 'C:/Program Files/Microsoft SDKs/Windows/v6.0a'
Checking whether the C++ compiler works(cached) yes
Checking for C header file unistd.h... (cached) no
Checking whether clock_gettime is declared... (cached) no
Checking for C++ header file execinfo.h... (cached) no
Checking for C library pcap... (cached) no
Checking for C library wpcap... (cached) no
scons: done reading SConscript files.
scons: Building targets ...
generate_buildinfo(["build\buildinfo.cpp"], ['\n#include <string>\n#include <boost/version.hpp>\n\n#include "mongo/util/version.h"\n\nnamespace mongo
{\n    const char * gitVersion() { return "%(git_version)s"; }\n    const char * compiledJSEngine() { return "%(js_engine)s"; }\n    const char * allo
cator() { return "%(allocator)s"; }\n    const char * loaderFlags() { return "%(loader_flags)s"; }\n    const char * compilerFlags() { return "%(compi
ler_flags)s"; }\n    std::string sysInfo() { return "%(sys_info)s BOOST_LIB_VERSION=" BOOST_LIB_VERSION ; }\n}  // namespace mongo\n'])
Using tempfile c:\users\me\appdata\local\temp\tmp1kcn3f.lnk for command line:
link /nologo /LTCG /DEBUG /LARGEADDRESSAWARE /NODEFAULTLIB:MSVCPRT "/OUT:build\win32\cpppath_c__program files (x86)_Microsoft SDKs_Windows_v7.0A_Inclu
de\extrapath_c__openssl-win64\ssl\mongo\mongod.exe" /LIBPATH:C:\openssl-win64\lib /LIBPATH:C:\openssl-win64\lib64 "/LIBPATH:C:\Program Files\Microsoft
 SDKs\Windows\v6.0a\Lib" /LIBPATH:C:\Dev\mongo\source2\winpcap\Lib [snip a bunch of obj files]
link @c:\users\me\appdata\local\temp\tmp1kcn3f.lnk
Using tempfile c:\users\me\appdata\local\temp\tmpt17dwi.lnk for command line:
link /nologo /LTCG /DEBUG /LARGEADDRESSAWARE /NODEFAULTLIB:MSVCPRT "/OUT:build\win32\cpppath_c__program files (x86)_Microsoft SDKs_Windows_v7.0A_Inclu
de\extrapath_c__openssl-win64\ssl\mongo\mongod.exe" /LIBPATH:C:\openssl-win64\lib /LIBPATH:C:\openssl-win64\lib64 "/LIBPATH:C:\Program Files\Microsoft
 SDKs\Windows\v6.0a\Lib" /LIBPATH:C:\Dev\mongo\source2\winpcap\Lib [snip more obj files]
sock.obj : error LNK2001: unresolved external symbol _ERR_error_string
sock.obj : error LNK2001: unresolved external symbol _SSL_get_error
sock.obj : error LNK2001: unresolved external symbol _SSL_shutdown
sock.obj : error LNK2001: unresolved external symbol _SSL_write
[snip more link errors]
build\win32\cpppath_c__program files (x86)_Microsoft SDKs_Windows_v7.0A_Include\extrapath_c__openssl-win64\ssl\mongo\mongod.exe : fatal error LNK1120:
 41 unresolved externals
scons: *** [build\win32\cpppath_c__program files (x86)_Microsoft SDKs_Windows_v7.0A_Include\extrapath_c__openssl-win64\ssl\mongo\mongod.exe] Error 112
0 
scons: building terminated because of errors.
 


I'll recompile with these new options and update the thread 

Ed Norris

unread,
May 9, 2013, 8:41:01 AM5/9/13
to mongod...@googlegroups.com
Long story short, it now compiles, links and runs with SSL, which is nice.

My final command line:
scons --ssl --extrapath=c:\openssl-win64 --64 --release

I'm not sure what fixed the linker errors, but based on acm's response, I did two things: 
1. I altered SConstruct to prefer "C:/Program Files (x86)/Microsoft SDKs/Windows/v7.0A" over "C:/Program Files/Microsoft SDKs/Windows/v6.0A"
2. I added --64 and --release to the command line (I had assumed that those would be the defaults, which is probably a bad idea)

So I hope this helps someone, and thanks for reading!

Ed

Andrew Morrow

unread,
May 16, 2013, 10:58:33 AM5/16/13
to mongod...@googlegroups.com

There is not (currently) a way to specify the desired version of the MS compiler or SDK as an argument to our SConstruct file. If you are willing to experiment, you may be able to achieve what you want by manually editing the top level SConstruct. You would need to add to the Environment object declaration settings for the following variables, which SCons uses internally to help locate the Microsoft toolchain components:

MSSDK_VERSION
MSVC_VERSION

I have not yet experimented with these, so I can't recommend what values they should have. You will need to investigate the SCons internal files in SCons/Tool/MSCommon to figure out the correct values. You can also set SCONS_MSCOMMON_DEBUG=- in your shell environment before running scons to get a lot of additional information about how SCons is searching for the tools.

RE your build errors: these look more like conflicts between the visual studio and SDK headers, rather than a compilation problem with MongoDB itself.



On Thu, May 16, 2013 at 8:12 AM, Jue Stephan <jue.s...@gmail.com> wrote:

I struggled a lot with the task to build MongoDb with SSL on Windows the last days and this post helped me a lot.
I tried this on a Windows 8 and 7 where Visual Studio 2010 and Visual Studio 2012 were both installed.
Scons finds and uses the VS 2012 compiler which finishes with an error. I attached the console output.

Finally I found an old PC with only Visual Studio 2010 installed and there the build works fine.
Is there a possibility to configure scons that it uses the VS 2010 instead of the VS 2012?


Reply all
Reply to author
Forward
0 new messages