C/C++建筑步骤
有人可以描述一下，当使用 ./configure 和 时，*nix-like 系统下的 lib_xxxx 库的链接阶段会发生什么make 命令？
实际上，我有一个具体的问题：
与简单地归档所需的 .o 对象文件相比，在 makefile 的链接阶段后面会发生什么？
所以，我很确定，例如，任何 C 库都可以使用对象文件夹中的以下命令组合在一起：ar r libXYZ.a *.o。
但我怀疑，这并不是实际完成的（因为 makefile 使用 libtool 等，...）。
这样做的目的是什么以及如何完成？
编译C++代码库时的链接阶段怎么样（在简单的情况下，例如，当没有跨对象优化时）是必须的）？
我怀疑您还可以将生成的目标文件放入存档中并将其用作静态库。
那么到底隐藏了什么以及其目的是什么？
谢谢。
Could someone please describe, what happens beneath the linking stage of lib_xxxx libraries under *nix-like systems when using ./configure and make commands?
Actually, I have a concrete question:
What happens behind the linking stage in makefiles compared to simply archiving the required .o object files?
So, I'm pretty sure that, for example, any C library can be combined together using command like: ar r libXYZ.a *.o from the object folder.
But I suspect, that this is not what is actually done (because the makefiles use libtool, etc, ...).
What's the purpose of that and how is it done?
What about the linking stage when compiling C++ code libraries (in a simple case, for example, when no cross-object optimization is required)?
I suspect you also can put the resulting object files into an archive and use it as a static library.
So what's actually hidden and what's the purpose of that?
Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
并非所有 ar 实用程序都是一样的。
libtool隐藏了不同工具链所需的不同选项等，并且还支持创建共享库和静态库。Not all
arutilities are created equal.libtoolhides different options, etc., required by different toolchains, and also supports creation of both shared and static libraries.你刚才所说的有很多不同的步骤：
configure是一个设置构建环境的 shell 脚本make是一个工具，它根据文件依赖关系（依赖文件是否比目标文件新）调用编译器的各种实例（以及许多其他东西）。实际的“编译器”调用可能是您最感兴趣的：预处理、编译、汇编，您似乎对这些很满意。
最后，链接：所有目标文件都必须转换为可执行文件：链接器将查找一个入口点（通常为
main()）。出现的所有符号（即函数和全局变量）都必须用其他目标文件中提供的实际代码的地址填充。一旦使用了本地目标文件中的所有符号，您可能仍然有需要从库中提供的“未定义符号”。因此，完整链接的结果通常是一个二进制文件，其中所有函数名称（可能）已被删除并替换为代码的实际地址（更不用说 PIC）或对加载时共享库的引用。本质上，您的初始对象集合在链接的二进制文件中不再可见。 （现代链接时优化实际上可能会非常严重地混合和修剪您的代码。）另一方面，使用
ar创建的静态库只是原始代码的集合 ，未链接的对象及其所有符号都完好无损，可用于链接。嗯，这是对一个庞大主题的非常忙碌的概述，所以自然这远不完整或不具有代表性，而且可能只是部分正确。如果您有具体问题，请发表评论。
There are many different steps in what you just said:
configureis a shell script that sets up the build environmentmakeis a tool that invokes various instances of the compiler (and many other things) depending on file dependencies (whether dependent files are newer than target files).The actual "compiler" invocation is perhaps what you're most interested in: Preproccessing, compiling, assembling, you seem to be happy with those.
Finally, linking: All the object files have to be turned into an executable: The linker will look for one entry point (typically
main()). All symbols (i.e. functions and global variables) that appear have to be filled in with the address of actual code that's supplied in other object files. Once all the symbols from your local object files have been used, you may still have "undefined symbols" which need to be fed from libraries.So the result of a complete linking typically is a binary where all the names of functions (may) have been removed and replaced by the actual addresses (never mind PIC) of code or references to load-time shared libraries. Essentially, your initial collection of objects is no longer visible in the linked binary. (Modern link-time optimization may in fact mix up and prune your code very severely.) On the other hand, a static library created with
aris just a collection of raw, unlinked objects with all their symbols intact which may be used for linking.Hm, this was a very hectic overview of a vast subject, so naturally this is nowhere near complete or representative, and probably only partially correct. Post a comment if you have a specific concern.
我在这里发布了非常详细的链接描述
I have posted quite a detailed description of linking over here
ar仅在创建静态库时使用，静态库基本上只是一团目标文件（因此，只能用作ld的输入 - 它们可以'不会在运行时加载）。创建动态库是一个完全独立的过程，ld必须参与其中。在除 OS X 之外的大多数 UNIXy 系统上，
libtool只是一个编译器和链接器的前端。幕后发生的大部分事情只是(g)cc和ld。（在 OS X 上，
libtool是一个单独的实用程序，用于创建.a静态库和.dylib共享库文件。）aronly gets used when creating static libraries, which are basically just a blob of object files (and, as such, are only usable as input told-- they can't be loaded at runtime). Creating a dynamic library is a completely separate process whichldhas to get involved in.On most UNIXy systems besides OS X,
libtoolis just a front-end to the compiler and linker. Most of what goes on behind the scenes is just(g)ccandld.(On OS X,
libtoolis a separate utility which gets used to create both.astatic libraries and.dylibshared library files.)libtool的目的是隐藏调用系统实际库工具的复杂性（例如，ar、nm、ld em>、lipo 等），目的是使包在类似 POSIX 的操作系统之间更加可移植。 ./configure 脚本将在执行期间输出libtool 脚本。包维护者不必使用libtool（并且依赖于使用正确的标志手动调用本机工具），但它确实使工作变得更容易。
正如您所怀疑的，命令行工具用于构建库，但隐藏在libtool后面。您可以通过检查 libtool 输出的 .la 库文件之一来了解如何完成此操作，但这只是答案的一部分。答案的其余部分取决于要使用库的平台，因为库可以交叉编译。
同样，答案取决于使用库的平台。对于静态库，使用 ar 归档它们通常就足够了。对于动态库，答案因系统而异。 libtool 脚本已内置此信息，因此当调用make install 时，就会发生正确的事情。
The purpose of libtool is to hide the complexity of invoking the system's actual library tools (e.g., ar, nm, ld, lipo, etc.) for the purposes of making the package more portable across POSIX-like OSes. The ./configure script will output the libtool script during its execution. The package maintainer doesn't have to use libtool (and rely on manually invoking the native tools with the correct flags), but it does make the job easier.
As you suspected, the command line tools are used to build libraries, but are hidden behind libtool. You can find out more about how this is accomplished by examining one of the .la library files output by libtool, but this is only part of the answer. The rest of the answer depends on the platform where the libraries are to be used as libraries can be cross compiled.
Again, the answer depends on the platform where the libraries are to be used. For static libraries, archiving them with ar is usually enough. For dynamic libraries, the answer varies by system. The libtool script has this information built into it so the Right Thing happens when make install is invoked.