用VS 2010编译带调试符号（debugging symbols）的OpenSSL库文件

在我的博文《64位Win7下用VS2010编译OpenSSL》（网址：/article/8760210.html ）中介绍了用 VS 2010编译 OpenSSL 的方法，但是那样编译出的库文件中不包含调试符号（debugging symbols）。在
OpenSSL 自带的文件 INSTALL.W64 中并没有介绍在编译时如何带上调试符号，但是文件最后一句话是： TBD, for now see INSTALL.W32.

说明可能有关信息被包含在 OpenSSL 自带的文件 INSTALL.W32 中了。阅读 INSTALL.W32，找到下面的话：

There are various changes you can make to the Win32 compile environment. By default the library is not compiled with debugging symbols. If you use the platform debug-VC-WIN32 instead of VC-WIN32 then debugging symbols will be compiled in.

这句话告诉我们如何在编译时加入调试符号，即：

1. 如果要编译x64架构 CPU 上可用的 64 位 OpenSSL 库文件，将命令 perl Configure VC-WIN64A 替换为perl Configure debug-VC-WIN64A

（对于很少见的 Itanium IA64 架构 CPU，是将命令 perl Configure VC-WIN64I 替换为perl Configure debug-VC-WIN64I ）

2. 如果要编译 32 位的 OpenSSL 库文件，将命令 perl Configure VC-WIN32替换为perl Configure debug-VC-WIN32

其他的编译步骤与博文《64位Win7下用VS2010编译OpenSSL》中介绍的相同。这样编译出来的 OpenSSL 库文件中就会包含调试符号了。

此外，文件 INSTALL.W32 中还介绍了一些其他方面的有用信息，比如下面的两段话：

1) By default in 1.0.0 OpenSSL will compile builtin ENGINES into the separate shared librariesy. If you specify the "enable-static-engine" option on the command line to Configure the shared library build (ms\ntdll.mak) will compile the engines into libeay32.dll
instead.

2) Linking your application

------------------------

If you link with static OpenSSL libraries [those built with ms/nt.mak], then you're expected to additionally link your application with WS2_32.LIB, ADVAPI32.LIB, GDI32.LIB and USER32.LIB. Those developing non-interactive service applications might
feel concerned about linking with the latter two, as they are justly associated with interactive desktop, which is not available to service processes. The toolkit is designed to detect in which context it's currently executed, GUI, console app or service,
and act accordingly, namely whether or not to actually make GUI calls. Additionally those who wish to /DELAYLOAD:GDI32.DLL and /DELAYLOAD:USER32.DLL and actually keep them off service process should consider implementing and exporting from .exe image in
question own _OPENSSL_isservice not relying on USER32.DLL.

E.g., on Windows Vista and later you could:

__declspec(dllexport) __cdecl BOOL _OPENSSL_isservice(void)

{ DWORD sess;

if (ProcessIdToSessionId(GetCurrentProcessId(),&sess))

return sess==0;

return FALSE;

}

If you link with OpenSSL .DLLs, then you're expected to include into your application code small "shim" snippet, which provides glue between OpenSSL BIO layer and your compiler run-time. Look up OPENSSL_Applink reference page for further details.