Several possible reasons for "error LNK2019: unresolved external symbols"

1. ForewordError LNK2019: unresolved external symbols This error has been seen many times before, to know that the most fundamental reason is that the link process did not search for the library file used by the program, that is, *.lib.
Notebook reload system, there are 32Bit liters to 64Bit, run VTK program, always the error is as follows: 1> is creating library E:\Driverprogram\imgport\Debug\imgport.lib and Objects E:\Driverprogram \imgport\debug\imgport.exp
1>monitor.obj:error LNK2019: unresolved external symbol "int __cdecl start_convert (Int,int,char *,bool)" (? start_convert@ @YAHHHPAD_ N@Z), which is referenced in the function "int __stdcall ienddocport (? ienddocport@ @YGHPAX @z)"
1>p2jpg.obj:error LNK2019: unresolved external symbol "void __cdecl jpeg_destroy_compress (struct jpeg_compress_struct *)" (? Jpeg_ destroy_compress@ @YAXPAUjpeg_compress_struct @@@z), the symbol is referenced in the function _bmp2jpg
1>p2jpg.obj:error LNK2019: unresolved external symbol "void __cdecl jpeg_finish_compress (struct jpeg_compress_struct *)" (? Jpeg_ finish_compress@ @YAXPAUjpeg_compress_struct @@@z), the symbol is referenced in the function _bmp2jpg
1>p2jpg.obj:error LNK2019: unresolved external symbol "unsigned int __cdecl jpeg_write_scanlines (struct jpeg_compress_struct *, unsigned char * *,unsigned int) "(? jpeg_write_scanlines@ @YAIPAUjpeg_compress_struct @ @PAPAEI @z), the symbol is referenced in the function _bmp2jpg.
You are convinced that all dependent library files are loaded correctly, and why this problem occurs ... This paper mainly sums up the causes of error LNK2019 and provides corresponding solutions. 2. Induction of Reason 2.1 Use Open source program, forget to add dependenciesThis is the most common problem. The solution is as follows: VC6:
Engineering, Setup, C/C + +, Category: Preprocessor, additional include path: Fill in additional header file directory comma interval multiple entries
Engineering, settings, Link, Category: Input, additional library path: filling in the directory of additional dependent libraries semicolon interval multiple entries
Engineering, settings, Link, Category: Input, Object/Library module: Fill in the name of the additional dependent library. Lib Space interval multiple items
VS20XX:
Projects, properties, C/A + +, additional Include directories: filling in the additional header file directory semicolon interval multiple entries
Projects, properties, Linker, general, additional Library directory: fill in the directory where the attached dependencies are located semicolon interval multiple entries
Projects, properties, linker, input, additional dependencies: Fill in the name of the attached dependent library. lib space or semicolon interval multiple items 2.2 X64 compiled, using Win32debugThis error is the bug that bothers me all day. There was no discovery at all. I have been using the 32Bit operating system for VITK development, because compatible with a foreign open source program method, the replacement of 64Bit system. People who have used VITK know that in using them they must be compiled in the current environment to generate *.lib and *.dll files. So the files were compiled using VS2013 debug+x64, but in the Run-time program The Times were wrong ... This is due to the details of Win32 and X64. Before and after the change is shown in the following figure:


3. VS2010 Win32 Conversion X641. Click the "Win32" drop-down box to open the "Configuration Manager"

2. Click on the "Active Solution Management Platform" drop-down box, select "New"
3. Click the "type or select a new platform" drop-down box, select "x64" and click "OK"

4. Configuration completed, you can see the project platform has become x64, click Close to complete.