需要为新的工具集版本更新Visual Studio NuGet包

我在尝试将libpng链接到Visual Studio 2013时遇到了这个问题。问题是，程序包文件只有用于Visual Studio2010和2012的库。

正确的解决方案是希望开发人员发布一个更新的包，然后进行升级，但这对我来说很管用，我破解了VS2013的一个额外设置，指向VS2012库文件。

我通过在该文件中找到packagename\build\native\packagename.targets并复制所有v110节来编辑包(在解决方案目录内的packages文件夹中)。我将**条件字段中的v110更改为v120**非常小心地将文件名路径全部保留为v110。这只是允许Visual Studio 2013链接到2012年的库，在这种情况下，它起作用了。

针对共享库进行链接时，请确保使用的符号没有隐藏。

GCC的默认行为是所有符号都是可见的。但是，当使用选项-fvisibility=hidden构建转换单元时，只有标有__attribute__ ((visibility ("default")))的函数/符号在生成的共享对象中是外部的。

您可以通过调用以下命令来检查您正在寻找的符号是否为外部符号：

# -D shows (global) dynamic symbols that can be used from the outside of XXX.so

nm -D XXX.so | grep MY_SYMBOL

隐藏/本地符号由nm显示，符号类型为小写，例如t而不是代码段的`t：

nm XXX.so
00000000000005a7 t HIDDEN_SYMBOL
00000000000005f8 T VISIBLE_SYMBOL

您还可以使用带有选项-C的nm来取消名称的混乱(如果使用的是C++)。

与Windows-dll类似，可以使用定义标记公共函数，例如DLL_PUBLIC定义为：

# define DLL_PUBLIC __attribute__ ((visibility ("default")))

DLL_PUBLIC int my_public_function(){
  ...
}

大致对应于Windows的/MSVC版本：

# ifdef BUILDING_DLL

    #define DLL_PUBLIC __declspec(dllexport) 

# else

    #define DLL_PUBLIC __declspec(dllimport) 

# endif

更多information about visibility可以在GCC维基上找到。

当用-fvisibility=hidden编译翻译单元时，所得到的符号仍然具有外部链接(由nm以大写符号类型表示)，并且如果目标文件成为静态库的一部分，则可以用于外部链接而没有问题。仅当目标文件链接到共享库时，该链接才变为本地链接。

要查找对象文件中隐藏的符号，请执行以下操作：

>>> objdump -t XXXX.o | grep hidden
0000000000000000 g     F .text  000000000000000b .hidden HIDDEN_SYMBOL1
000000000000000b g     F .text  000000000000000b .hidden HIDDEN_SYMBOL2

尽管这是一个相当古老的问题，有多个公认的答案，但我想分享一下如何解决一个晦涩“未定义的引用”错误。

不同版本的库

我使用别名来引用std::filesystem::path：文件系统从C17开始就在标准库中，但我的程序需要**也用C14编译**，所以我决定使用变量别名：

# if (defined _GLIBCXX_EXPERIMENTAL_FILESYSTEM) //is the included filesystem library experimental? (C++14 and newer: <experimental/filesystem>)

using path_t = std::experimental::filesystem::path;

# elif (defined _GLIBCXX_FILESYSTEM) //not experimental (C++17 and newer: <filesystem>)

using path_t = std::filesystem::path;

# endif

假设我有三个文件：main.cpp、file.h、file.cpp：

• file.h**#Include的<实验性：：文件系统>并包含上面的代码
• file.cpp**，file.h的实现，#INCLUDE的“file.h”
• main.cpp**#Include的<文件系统>和“file.h”

注意main.cpp和file.h中使用的不同的库。因为main.cpp#includd‘d“file.h”在<filessystem>之后，所以那里使用的文件系统版本是C++17版本。我过去常常使用以下命令编译该程序：

$g++ -g -std=c++17 -c main.cpp->将main.cpp编译为main.o
$g++ -g -std=c++17 -c file.cpp->将file.cpp和file.h编译为file.o
$g++ -g -std=c++17 -o executable main.o file.o -lstdc++fs->链接main.o和file.o

这样，需要path_t的file.o中包含并在main.o中使用的任何函数都会出现“未定义的引用”错误，因为main.o引用了std::filesystem::path，但file.o引用了std::experimental::filesystem::path**。

解决方案

要解决这个问题，我只需要将file.h中的<实验性：：文件系统>更改为<文件系统>。

const变量声明/定义中缺少extern(仅限C++)

对于来自C语言的人来说，在C++中，全局e1d1d1变量具有内部(或静态)链接，这可能会令人惊讶。在C中情况并非如此，因为所有全局变量都隐式为extern(即，当缺少关键字static时)。

示例：

// file1.cpp
const int test = 5;    // in C++ same as "static const int test = 5"
int test2 = 5;

// file2.cpp
extern const int test;
extern int test2;

void foo()
{
 int x = test;   // linker error in C++ , no error in C
 int y = test2;  // no problem
}

正确的做法是使用头文件并将其包含在file2.cpp和file1.cpp中

extern const int test;
extern int test2;

或者，可以使用显式extern在file1.cpp中声明const变量

清理重建

一个“干净”的构建可以去除以前的构建、失败的构建、不完整的构建以及其他与构建系统相关的构建问题留下的“枯木”。

通常，IDE或构建将包括某种形式的“干净”函数，但这可能未正确配置(例如，在手动Makefile中)或可能失败(例如，中间或结果二进制文件是只读的)。

一旦“清理”完成，确认“清理”已成功，并且所有生成的中间文件(例如，自动生成的Makefile)都已被成功删除。

这个过程可以看作是最后的手段，但通常是一个很好的第一步；特别是如果最近添加了与错误相关的代码(无论是在本地还是从源代码存储库中)。

UNICODE定义不一致

Windows Unicode构建时，TCHAR等被定义为wchar_t等。如果不使用UNICODE构建，TCHAR定义为char等。这些UNICODE和_UNICODE定义会影响所有"T" string types；LPTSTR、LPCTSTR及其ELK。

在定义了UNICODE的情况下生成一个库并尝试将其链接到未定义UNICODE的项目中会导致链接器错误，因为TCHAR的定义与wchar_t的定义不匹配。

错误通常包括具有char或wchar_t派生类型的函数a值，也可能包括std::basic_string<>等。当浏览代码中受影响的函数时，通常会引用TCHAR或std::basic_string<TCHAR>等。这是一个迹象，表明代码最初是用于Unicode和多字节字符(或“窄”)构建的。

要纠正此问题，请使用UNICODE(和_UNICODE)的一致定义构建所有必需的库和项目。

1.这可以用任何一种方式来完成；

# define UNICODE

# define _UNICODE

1.或在项目设置中；
项目属性>常规>项目默认设置>字符集
1.或在命令行上；

/DUNICODE /D_UNICODE

替代方案也适用，如果不打算使用Unicode，请确保未设置定义，和/或在项目中使用并一致应用多字符设置。

不要忘记在“发布”和“调试”版本之间也要保持一致。

When your include paths are different

Linker errors can happen when a header file and its associated shared library (.lib file) go out of sync. Let me explain.

How do linkers work? The linker matches a function declaration (declared in the header) with its definition (in the shared library) by comparing their signatures. You can get a linker error if the linker doesn't find a function definition that matches perfectly.

Is it possible to still get a linker error even though the declaration and the definition seem to match? Yes! They might look the same in source code, but it really depends on what the compiler sees. Essentially you could end up with a situation like this:

// header1.h
typedef int Number;
void foo(Number);

// header2.h
typedef float Number;
void foo(Number); // this only looks the same lexically

Note how even though both the function declarations look identical in source code, but they are really different according to the compiler.

You might ask how one ends up in a situation like that?Include pathsof course! If when compiling the shared library, the include path leads to header1.h and you end up using header2.h in your own program, you'll be left scratching your header wondering what happened (pun intended).

An example of how this can happen in the real world is explained below.

Further elaboration with an example

I have two projects: graphics.lib and main.exe. Both projects depend on common_math.h. Suppose the library exports the following function:

// graphics.lib    

# include "common_math.h"

void draw(vec3 p) { ... } // vec3 comes from common_math.h

And then you go ahead and include the library in your own project.

// main.exe

# include "other/common_math.h"

# include "graphics.h"

int main() {
    draw(...);
}

Boom! You get a linker error and you have no idea why it's failing. The reason is that the common library uses different versions of the same include common_math.h (I have made it obvious here in the example by including a different path, but it might not always be so obvious. Maybe the include path is different in the compiler settings).

Note in this example, the linker would tell you it couldn't find draw(), when in reality you know it obviously is being exported by the library. You could spend hours scratching your head wondering what went wrong. The thing is, the linker sees a different signature because the parameter types are slightly different. In the example, vec3 is a different type in both projects as far as the compiler is concerned. This could happen because they come from two slightly different include files (maybe the include files come from two different versions of the library).

Debugging the linker

DUMPBIN is your friend, if you are using Visual Studio. I'm sure other compilers have other similar tools.

The process goes like this:

1. Note the weird mangled name given in the linker error. (eg. draw@graphics@XYZ).
2. Dump the exported symbols from the library into a text file.
3. Search for the exported symbol of interest, and notice that the mangled name is different.
4. Pay attention to why the mangled names ended up different. You would be able to see that the parameter types are different, even though they look the same in the source code.
5. Reason why they are different. In the example given above, they are different because of different include files.

[1] By project I mean a set of source files that are linked together to produce either a library or an executable.

EDIT 1: Rewrote first section to be easier to understand. Please comment below to let me know if something else needs to be fixed. Thanks!

Befriending templates...

Given the code snippet of a template type with a friend operator (or function);

template <typename T>
class Foo {
    friend std::ostream& operator<< (std::ostream& os, const Foo<T>& a);
};

The operator<< is being declared as a non-template function. For every type T used with Foo, there needs to be a non-templated operator<<. For example, if there is a type Foo<int> declared, then there must be an operator implementation as follows;

std::ostream& operator<< (std::ostream& os, const Foo<int>& a) {/*...*/}

Since it is not implemented, the linker fails to find it and results in the error.

To correct this, you can declare a template operator before the Foo type and then declare as a friend, the appropriate instantiation. The syntax is a little awkward, but is looks as follows;

// forward declare the Foo
template <typename>
class Foo;

// forward declare the operator <<
template <typename T>
std::ostream& operator<<(std::ostream&, const Foo<T>&);

template <typename T>
class Foo {
    friend std::ostream& operator<< <>(std::ostream& os, const Foo<T>& a);
    // note the required <>        ^^^^
    // ...
};

template <typename T>
std::ostream& operator<<(std::ostream&, const Foo<T>&)
{
  // ... implement the operator
}

The above code limits the friendship of the operator to the corresponding instantiation of Foo, i.e. the operator<< <int> instantiation is limited to access the private members of the instantiation of Foo<int>.

Alternatives include;

• Allowing the friendship to extend to all instantiations of the templates, as follows;

template <typename T>
class Foo {
    template <typename T1>
    friend std::ostream& operator<<(std::ostream& os, const Foo<T1>& a);
    // ...
};

• Or, the implementation for the operator<< can be done inline inside the class definition;

template <typename T>
class Foo {
    friend std::ostream& operator<<(std::ostream& os, const Foo& a)
    { /*...*/ }
    // ...
};

• Note*, when the declaration of the operator (or function) only appears in the class, the name is not available for "normal" lookup, only for argument dependent lookup, from cppreference;

A name first declared in a friend declaration within class or class template X becomes a member of the innermost enclosing namespace of X, but is not accessible for lookup (except argument-dependent lookup that considers X) unless a matching declaration at the namespace scope is provided...

There is further reading on template friends at cppreference and the C++ FAQ.

Code listing showing the techniques above.

• As a side note to the failing code sample; g++ warns about this as follows*

warning: friend declaration 'std::ostream& operator<<(...)' declares a non-template function [-Wnon-template-friend]

note: (if this is not what you intended, make sure the function template has already been declared and add <> after the function name here)

A wrapper around GNU ld that doesn't support linker scripts

Some .so files are actually GNU ld linker scripts, e.g. libtbb.so file is an ASCII text file with this contents:

INPUT (libtbb.so.2)

Some more complex builds may not support this. For example, if you include -v in the compiler options, you can see that the mainwin gcc wrapper mwdip discards linker script command files in the verbose output list of libraries to link in. A simple work around is to replace the linker script input command file with a copy of the file instead (or a symlink), e.g.

cp libtbb.so.2 libtbb.so

Or you could replace the -l argument with the full path of the .so, e.g. instead of -ltbb do /home/foo/tbb-4.3/linux/lib/intel64/gcc4.4/libtbb.so.2

Your linkage consumes libraries before the object files that refer to them

• You are trying to compile and link your program with the GCC toolchain.
• Your linkage specifies all of the necessary libraries and library search paths
• If libfoo depends on libbar, then your linkage correctly puts libfoo before libbar.
• Your linkage fails with undefined reference tosomething errors.
• But all the undefined somethings are declared in the header files you have #included and are in fact defined in the libraries that you are linking.

Examples are in C. They could equally well be C++

A minimal example involving a static library you built yourself

my_lib.c

# include "my_lib.h"

# include <stdio.h>

void hw(void)
{
    puts("Hello World");
}

my_lib.h

# ifndef MY_LIB_H

# define MT_LIB_H

extern void hw(void);

# endif

eg1.c

# include <my_lib.h>

int main()
{
    hw();
    return 0;
}

You build your static library:

$ gcc -c -o my_lib.o my_lib.c
$ ar rcs libmy_lib.a my_lib.o

You compile your program:

$ gcc -I. -c -o eg1.o eg1.c

You try to link it with libmy_lib.a and fail:

$ gcc -o eg1 -L. -lmy_lib eg1.o 
eg1.o: In function `main':
eg1.c:(.text+0x5): undefined reference to `hw'
collect2: error: ld returned 1 exit status

The same result if you compile and link in one step, like:

$ gcc -o eg1 -I. -L. -lmy_lib eg1.c
/tmp/ccQk1tvs.o: In function `main':
eg1.c:(.text+0x5): undefined reference to `hw'
collect2: error: ld returned 1 exit status

A minimal example involving a shared system library, the compression library libz

eg2.c

# include <zlib.h>

# include <stdio.h>

int main()
{
    printf("%s\n",zlibVersion());
    return 0;
}

Compile your program:

$ gcc -c -o eg2.o eg2.c

Try to link your program with libz and fail:

$ gcc -o eg2 -lz eg2.o 
eg2.o: In function `main':
eg2.c:(.text+0x5): undefined reference to `zlibVersion'
collect2: error: ld returned 1 exit status

Same if you compile and link in one go:

$ gcc -o eg2 -I. -lz eg2.c
/tmp/ccxCiGn7.o: In function `main':
eg2.c:(.text+0x5): undefined reference to `zlibVersion'
collect2: error: ld returned 1 exit status

And a variation on example 2 involving pkg-config:

$ gcc -o eg2 $(pkg-config --libs zlib) eg2.o 
eg2.o: In function `main':
eg2.c:(.text+0x5): undefined reference to `zlibVersion'

What are you doing wrong?

In the sequence of object files and libraries you want to link to make your program, you are placing the libraries before the object files that refer to them. You need to place the libraries after the object files that refer to them.

Link example 1 correctly:

$ gcc -o eg1 eg1.o -L. -lmy_lib

Success:

$ ./eg1 
Hello World

Link example 2 correctly:

$ gcc -o eg2 eg2.o -lz

Success:

$ ./eg2 
1.2.8

Link the example 2 pkg-config variation correctly:

$ gcc -o eg2 eg2.o $(pkg-config --libs zlib) 
$ ./eg2
1.2.8

The explanation

• Reading is optional from here on*.

By default, a linkage command generated by GCC, on your distro, consumes the files in the linkage from left to right in commandline sequence. When it finds that a file refers to something and does not contain a definition for it, to will search for a definition in files further to the right. If it eventually finds a definition, the reference is resolved. If any references remain unresolved at the end, the linkage fails: the linker does not search backwards.

First,example 1, with static library my_lib.a

A static library is an indexed archive of object files. When the linker finds -lmy_lib in the linkage sequence and figures out that this refers to the static library ./libmy_lib.a, it wants to know whether your program needs any of the object files in libmy_lib.a.

There is only object file in libmy_lib.a, namely my_lib.o, and there's only one thing defined in my_lib.o, namely the function hw.

The linker will decide that your program needs my_lib.o if and only if it already knows that your program refers to hw, in one or more of the object files it has already added to the program, and that none of the object files it has already added contains a definition for hw.

If that is true, then the linker will extract a copy of my_lib.o from the library and add it to your program. Then, your program contains a definition for hw, so its references to hw are resolved.

When you try to link the program like:

$ gcc -o eg1 -L. -lmy_lib eg1.o

the linker has not addedeg1.oto the program when it sees -lmy_lib. Because at that point, it has not seen eg1.o. Your program does not yet make any references to hw: it does not yet make any references at all, because all the references it makes are in eg1.o.

So the linker does not add my_lib.o to the program and has no further use for libmy_lib.a.

Next, it finds eg1.o, and adds it to be program. An object file in the linkage sequence is always added to the program. Now, the program makes a reference to hw, and does not contain a definition of hw; but there is nothing left in the linkage sequence that could provide the missing definition. The reference to hw ends up unresolved, and the linkage fails.

Second,example 2, with shared library libz

A shared library isn't an archive of object files or anything like it. It's much more like a program that doesn't have a main function and instead exposes multiple other symbols that it defines, so that other programs can use them at runtime.

Many Linux distros today configure their GCC toolchain so that its language drivers (gcc,g++,gfortran etc) instruct the system linker (ld) to link shared libraries on an as-needed basis. You have got one of those distros.

This means that when the linker finds -lz in the linkage sequence, and figures out that this refers to the shared library (say) /usr/lib/x86_64-linux-gnu/libz.so, it wants to know whether any references that it has added to your program that aren't yet defined have definitions that are exported by libz

If that is true, then the linker will not copy any chunks out of libz and add them to your program; instead, it will just doctor the code of your program so that:-

• At runtime, the system program loader will load a copy of libz into the same process as your program whenever it loads a copy of your program, to run it.
• At runtime, whenever your program refers to something that is defined in libz, that reference uses the definition exported by the copy of libz in the same process.

Your program wants to refer to just one thing that has a definition exported by libz, namely the function zlibVersion, which is referred to just once, in eg2.c. If the linker adds that reference to your program, and then finds the definition exported by libz, the reference is resolved

But when you try to link the program like:

gcc -o eg2 -lz eg2.o

the order of events is wrong in just the same way as with example 1. At the point when the linker finds -lz, there are no references to anything in the program: they are all in eg2.o, which has not yet been seen. So the linker decides it has no use for libz. When it reaches eg2.o, adds it to the program, and then has undefined reference to zlibVersion, the linkage sequence is finished; that reference is unresolved, and the linkage fails.

Lastly, the pkg-config variation of example 2 has a now obvious explanation. After shell-expansion:

gcc -o eg2 $(pkg-config --libs zlib) eg2.o

becomes:

gcc -o eg2 -lz eg2.o

which is just example 2 again.

I can reproduce the problem in example 1, but not in example 2

The linkage:

gcc -o eg2 -lz eg2.o

works just fine for you!

(Or: That linkage worked fine for you on, say, Fedora 23, but fails on Ubuntu 16.04)

That's because the distro on which the linkage works is one of the ones that does not configure its GCC toolchain to link shared libraries as-needed.

Back in the day, it was normal for unix-like systems to link static and shared libraries by different rules. Static libraries in a linkage sequence were linked on the as-needed basis explained in example 1, but shared libraries were linked unconditionally.

This behaviour is economical at linktime because the linker doesn't have to ponder whether a shared library is needed by the program: if it's a shared library, link it. And most libraries in most linkages are shared libraries. But there are disadvantages too:-

• It is uneconomical at runtime, because it can cause shared libraries to be loaded along with a program even if doesn't need them.
• The different linkage rules for static and shared libraries can be confusing to inexpert programmers, who may not know whether -lfoo in their linkage is going to resolve to /some/where/libfoo.a or to /some/where/libfoo.so, and might not understand the difference between shared and static libraries anyway.

This trade-off has led to the schismatic situation today. Some distros have changed their GCC linkage rules for shared libraries so that the as-needed principle applies for all libraries. Some distros have stuck with the old way.

Why do I still get this problem even if I compile-and-link at the same time?

If I just do:

$ gcc -o eg1 -I. -L. -lmy_lib eg1.c

surely gcc has to compile eg1.c first, and then link the resulting object file with libmy_lib.a. So how can it not know that object file is needed when it's doing the linking?

Because compiling and linking with a single command does not change the order of the linkage sequence.

When you run the command above, gcc figures out that you want compilation + linkage. So behind the scenes, it generates a compilation command, and runs it, then generates a linkage command, and runs it, as if you had run the two commands:

$ gcc -I. -c -o eg1.o eg1.c
$ gcc -o eg1 -L. -lmy_lib eg1.o

So the linkage fails just as it does if you do run those two commands. The only difference you notice in the failure is that gcc has generated a temporary object file in the compile + link case, because you're not telling it to use eg1.o. We see:

/tmp/ccQk1tvs.o: In function `main'

instead of:

eg1.o: In function `main':

See also

The order in which interdependent linked libraries are specified is wrong

Putting interdependent libraries in the wrong order is just one way in which you can get files that need definitions of things coming later in the linkage than the files that provide the definitions. Putting libraries before the object files that refer to them is another way of making the same mistake.

Since people seem to be directed to this question when it comes to linker errors I am going to add this here.

One possible reason for linker errors with GCC 5.2.0 is that a new libstdc++ library ABI is now chosen by default.
If you get linker errors about undefined references to symbols that involve types in the std::__cxx11 namespace or the tag [abi:cxx11] then it probably indicates that you are trying to link together object files that were compiled with different values for the _GLIBCXX_USE_CXX11_ABI macro. This commonly happens when linking to a third-party library that was compiled with an older version of GCC. If the third-party library cannot be rebuilt with the new ABI then you will need to recompile your code with the old ABI.

So if you suddenly get linker errors when switching to a GCC after 5.1.0 this would be a thing to check out.

Linked .lib file is associated to a .dll

I had the same issue. Say i have projects MyProject and TestProject. I had effectively linked the lib file for MyProject to the TestProject. However, this lib file was produced as the DLL for the MyProject was built. Also, I did not contain source code for all methods in the MyProject, but only access to the DLL's entry points.

To solve the issue, i built the MyProject as a LIB, and linked TestProject to this .lib file (i copy paste the generated .lib file into the TestProject folder). I can then build again MyProject as a DLL. It is compiling since the lib to which TestProject is linked does contain code for all methods in classes in MyProject.

A bug in the compiler/IDE

I recently had this problem, and it turned out it was a bug in Visual Studio Express 2013. I had to remove a source file from the project and re-add it to overcome the bug.

Steps to try if you believe it could be a bug in compiler/IDE:

• Clean the project (some IDEs have an option to do this, you can also manually do it by deleting the object files)
• Try start a new project, copying all source code from the original one.

使用链接器帮助诊断错误

大多数现代链接器都包含一个详细的选项，可以打印出不同程度的内容；

• 链接调用(命令行)，
• 链接阶段包括哪些库的数据；
• 图书馆的位置；
• 使用的搜索路径。

对于GCC和Clang，您通常会将-v -Wl,--verbose或-v -Wl,-v添加到命令行。更多细节可以在这里找到；

• Linux ld man page。
• LLVM链接程序页面。
• 《GCC入门》chapter 9。

对于MSVC，将/VERBOSE(特别是/VERBOSE:LIB)添加到链接命令行。

• /VERBOSE linker option上的MSDN页面。

假设您有一个用C++编写的大型项目，其中包含一千个.cpp文件和一千个.h文件，假设该项目也依赖于十个静态库。假设我们在Windows上，并且我们在Visual Studio 20xx中构建我们的项目。当您按Ctrl+F7 Visual Studio开始编译整个解决方案时(假设我们在解决方案中只有一个项目)

编译的意义是什么？

• Visual Studio搜索到文件**.vcxproj**，开始编译每个扩展名为.cpp的文件。编译顺序未定义。因此，您不能假定文件main.cpp是首先编译的
• 如果.cpp文件依赖于其他.h文件以查找在文件.cpp中可能定义或可能未定义的符号
• 如果存在一个.cpp文件，而编译器在该文件中找不到一个符号，则会出现编译器时间错误的消息**找不到符号x*
• 对于每个扩展名为.cpp的文件，都会生成一个对象文件.o，并且Visual Studio还会将输出写入名为ProjectName.Cpp.Clean.txt的文件中，该文件包含必须由链接器处理的所有对象文件。

编译的第二步是由Linker完成的。Linker应该合并所有的目标文件，并最终生成输出(可以是可执行文件或库)

链接项目的步骤

• 解析所有目标文件并找到仅在Header中声明的定义(例如：前面答案中提到的类的一个方法的代码，或初始化作为类内成员的静态变量)
• 如果在对象文件中找不到一个符号，也会在其他库中进行搜索。在项目中添加新库时，[配置属性]>[VC++目录]>[库目录]，在这里指定了用于搜索库的附加文件夹和用于指定库名称的[配置属性]>[链接器]>[输入]。-如果链接器找不到您在.cpp中编写的符号，则会引发链接器时间错误，听起来可能像error LNK2001: unresolved external symbol "void __cdecl foo(void)" (?foo@@YAXXZ)

观察

1.链接器一旦找到一个符号，就不会在其他库中搜索该符号
1.链接库的顺序很重要。
1.如果Linker在静态库中发现外部符号，他会将该符号包含在项目的输出中。但是，如果库是共享的(动态)，他不会在输出中包含代码(符号)，但可能会发生运行时崩溃

如何解决此类错误

编译器时间错误：

• 确保您编写的C++项目语法正确。

链接器时间错误

• 定义您在头文件中声明的所有符号
• 使用#pragma once允许编译器不包括一个标头，如果该标头已包含在当前已编译的.cpp中
• 确保您的外部库不包含可能与您在头文件中定义的其他符号冲突的符号
• 使用模板时，请确保在头文件中包含每个模板函数的定义，以允许编译器为任何示例化生成适当的代码。