blocks|key|17149|text|静态库仅仅是包含目标文件(即单独编译的源文件)的归档文件。因此，在构建静态库时，您不是“链接”它，而是“存档”它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|17150|在链接可执行文件或共享库时，必须解析符号。此时，链接器会尝试解析所有符号，如果无法解析，则会出现undefined+reference错误。但是，再说一次，这与链接有关。静态库不需要在其中定义所有符号。|offset|length|style|CODE|17151|在您的示例中，如果A、B、C和D是静态库，则它们将独立构建。要从C和D构建A，唯一需要的就是头文件，编译器需要这些文件。|17152|在构建可执行文件时，即使Main不“直接”引用C或D中的符号，也需要指定所有静态库。|17153|现在，尽管静态库不能隐式依赖于其他库，但CMake提供了一种在构建系统级别上表达这种依赖关系的方法。您可以执行以下操作|17154|add_library(C+STATIC+${B_SOURCES})
add_library(D+STATIC+${D_SOURCES})

add_library(A+STATIC+${A_SOURCES})
target_link_libraries(A+PUBLIC+C+D)|code-block|syntax|javascript|17155|上面的target_link_libraries命令不会导致A与C和D链接-正如我所写的，这不是静态库的工作。相反，它通知CMake在使用A链接可执行文件时，还必须将其与C和D链接：|17156|add_executable(Main+${MAIN_SOURCES})
target_link_libraries(Main+PRIVATE+A)|17157|即使target_link_libraries只包含A，由CMake生成的Makefile也将链接C和D+-因为它们被指定为A的依赖项。|17158|17159|dllexport和dllimport|BOLD|17160|这两个属性仅与共享库(DLL)有关。它们控制从DLL导出哪些符号(即可从链接到该DLL的可执行文件访问)。描述这一想法的Here's+a+link及其在Linux上的等价物。|17161|entityMap|0|LINK|mutability|MUTABLE|url|https://gcc.gnu.org/wiki/Visibility^0|0|1C|J|0|9|1|B|1|D|1|F|1|W|1|Y|1|11|1|0|C|4|N|1|P|1|0|0|0|3|L|U|1|W|1|Y|1|1X|1|2D|1|2F|1|0|0|2|L|Q|1|1D|1|1F|1|1Q|1|0|0|0|J|0|1O|D|0|0^^$0|@$1|2|3|4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1D|8|@$D|1E|E|1F|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|1G|8|@$D|1H|E|1I|F|G]|$D|1J|E|1K|F|G]|$D|1L|E|1M|F|G]|$D|1N|E|1O|F|G]|$D|1P|E|1Q|F|G]|$D|1R|E|1S|F|G]|$D|1T|E|1U|F|G]]|9|@]|A|$]]|$1|J|3|K|5|6|7|1V|8|@$D|1W|E|1X|F|G]|$D|1Y|E|1Z|F|G]|$D|20|E|21|F|G]]|9|@]|A|$]]|$1|L|3|M|5|6|7|22|8|@]|9|@]|A|$]]|$1|N|3|O|5|P|7|23|8|@]|9|@]|A|$Q|R]]|$1|S|3|T|5|6|7|24|8|@$D|25|E|26|F|G]|$D|27|E|28|F|G]|$D|29|E|2A|F|G]|$D|2B|E|2C|F|G]|$D|2D|E|2E|F|G]|$D|2F|E|2G|F|G]|$D|2H|E|2I|F|G]]|9|@]|A|$]]|$1|U|3|V|5|P|7|2J|8|@]|9|@]|A|$Q|R]]|$1|W|3|X|5|6|7|2K|8|@$D|2L|E|2M|F|G]|$D|2N|E|2O|F|G]|$D|2P|E|2Q|F|G]|$D|2R|E|2S|F|G]|$D|2T|E|2U|F|G]]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|2V|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|2W|8|@$D|2X|E|2Y|F|11]]|9|@]|A|$]]|$1|12|3|13|5|6|7|2Z|8|@]|9|@$D|30|E|31|1|32]]|A|$]]|$1|14|3|-4|5|6|7|33|8|@]|9|@]|A|$]]]|15|$16|$5|17|18|19|A|$1A|1B]]]]

Static libraries are merely archives containing object files (i. e. separately compiled source files). For this reason, when building a static library you don't "link" it, but "archive" it. 

Symbols have to be resolved when linking an executable or a shared library. At this point linker tries to resolve all symbols, at if it cannot, you get <code>undefined reference</code> errors. But, again, this pertains to linking. Static libraries do not need to have all symbols defined within them.

In your case, if <code>A</code>, <code>B</code>, <code>C</code> and <code>D</code> are static libs, they will be built independently from each other. The only thing you need to build <code>A</code> from <code>C</code> and <code>D</code> are header files, which are needed by the compiler.

When you are building an executable, you need to specify all static libraries, even if <code>Main</code> doesn't "directly" reference symbols from <code>C</code> or <code>D</code>.

Now, even though static libraries cannot implicitly depend on other libraries, CMake provides a way to express such dependencies on build system level. You can do the following

<pre><code>add_library(C STATIC ${B_SOURCES})
add_library(D STATIC ${D_SOURCES})

add_library(A STATIC ${A_SOURCES})
target_link_libraries(A PUBLIC C D)
</code></pre>

<code>target_link_libraries</code> command above does not cause <code>A</code> to be linked with <code>C</code> and <code>D</code> - as I wrote, that's not have static libs work. Instead, it informs CMake that when linking an executable with <code>A</code>, it has to link it with <code>C</code> and <code>D</code> too:

<pre><code>add_executable(Main ${MAIN_SOURCES})
target_link_libraries(Main PRIVATE A)
</code></pre>

Even though <code>target_link_libraries</code> includes only <code>A</code>, Makefile generated by CMake will also link <code>C</code> and <code>D</code> - because they were specified as dependencies of <code>A</code>.

<hr>

dllexport and dllimport

These two attributes pertain only to shared libraries (DLLs). They control which symbols are exported from a DLL (i. e. accessible from an executable which links to that DLL). <a href="https://gcc.gnu.org/wiki/Visibility" rel="nofollow noreferrer">Here's a link</a> describing the idea and equivalent on Linux.

I have a Visual studio solution with 5 projects

<ul>
<li>Main: application</li>
<li>A,B,C,D: static libraries</li>
</ul>

Main depends on A,B. A depends on C,D.

I have a fragile understanding of the build process.

The libs were building alone fine, especially A; I did not feel I was linking C and D to A.

And to build the Main application, I had to have A,B,C and D as input libraries even though Main only directly depends on A,B.

Now I am trying to build he whole thing on Linux with CMake, and I find myself exposed to these linking again. This time I don't want to use brute force and would prefer to understand how this links together.

Should I just build A,B,C and D as .a static libraries and have the Main include them all?

How is it possible for A to build without the symbols from C and D?

C++ build process - lib dependencies

编译器

Linux

我有一个包含5个项目的Visual studio解决方案应用程序库Main：A、B、C、D: static librariesMain取决于A，B。A取决于C，D。我对构建过程的理解很脆弱。libs单独构建很好，特别是A；我不觉得我是在将C和D与A联系起来。为了构建主应用程序，我必须使用A、B、C和D作为输入库，即使M...

问C++构建过程-库依赖关系
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问C++构建过程-库依赖关系EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问C++构建过程-库依赖关系
EN