Table of contents
01. Correspondence between VS and VC version numbers
| VS version | VC version number | release time |
|---|---|---|
| VS97 | VC = 5 | 1997-02 |
| VS6.0 | VC = 6 | 1998-06 |
| VS2002 | VC = 7 | 2002-02-13 |
| VS2003 | VC = 7.1 | 2003-04-24 |
| VS2005 | VC = 8 | 2005-11-07 |
| VS2008 | VC = 9 | 2007-11-19 |
| VS2010 | VC = 10 | 2010-04-12 |
| VS2012 | VC = 11 | 2012-09-12 |
| VS2013 | VC = 12 | 2013-10-17 |
| VS2015 | VC = 14 | 2015-07-20 |
| VS2017 | VC = 15 | 2017-03-07 |
| VS2019 | VC = 16 | 2019-04-02 |
02. libcurl static compilation and dynamic compilation
Here I take VS2019 as an example, and you actually select the corresponding version number according to the above correspondence.
//静态库，debug，x86
nmake /f Makefile.vc mode=static VC=16 DEBUG=yes MACHINE=x86
//静态库，release，x86
nmake /f Makefile.vc mode=static VC=16 MACHINE=x86
//动态库，debug，x64
nmake /f Makefile.vc mode=dll VC=16 DEBUG=yes MACHINE=x64
//动态库，release，x64
nmake /f Makefile.vc mode=dll VC=16 MACHINE=x64
The default DEBUG is no. If you want to support it, you need to add it manually. The default RELEASE is yes.
The code compiled here, as well as path settings and drive letter settings, please refer to the previous article: https://blog.csdn.net/m0_43458204/article/details/116595250
03. A little experience sharing about the libcurl library
- Version : Before compiling, make sure that the version compiled above corresponds to the VS version number you actually use
- Encoding : Before generating the software version, you must pay attention to the correspondence between your project encoding and the encoding of the static library (libcurl_a.lib).
- Inconsistency between compiling the lib library and referencing the lib library options :
1), one lib library adopts "multi-threaded DLL (/MD)" configuration, while the other project adopts "multi-threaded (/MT)" compilation configuration
2), one lib library Use the "use Unicode character set" configuration, while another project uses the "use multi-byte character set" compilation configuration
3), a lib library uses the "release version" configuration, and another project uses the "debug version" compilation configuration
4), one lib library adopts "wind32 platform" configuration, while the other project adopts "wind64 platform" compilation configuration - Did not add the specified precompiled macro :
When using the curl static library, I encountered a compilation link error:
The solution is to add a precompiled macro, CURL_STATICLIB, to your project properties.1>testcurl.obj : error LNK2001: unresolved external symbol __imp__curl_easy_init 1>testcurl.obj : error LNK2001: unresolved external symbol __imp__curl_easy_setopt 1>testcurl.obj : error LNK2001: unresolved external symbol __imp__curl_easy_perform 1>testcurl.obj : error LNK2001: unresolved external symbol __imp__curl_easy_cleanup
Therefore, in order to avoid the above problems, we must check the following steps when using third-party libraries:
- When referencing a third-party library, confirm whether the lib library uses the same compilation platform
- Confirm that the compilation options are consistent. such as runtime libraries and character sets
- If necessary, add the specified compilation macro
- Add additional library directories and additional dependencies
04. Summary
The above content is a little experience I have summarized in solving the problems encountered in compiling and generating versions this time. If you also encounter these problems, you can learn from them, try to solve them, and eliminate them.
Copyright statement: Technology sharing articles, welcome to reprint!