为什么我们将链接器和加载器分成单独的程序
伙计们，我想知道为什么我们应该将链接器和加载程序分开？我的理解是，链接器生成可重定位代码，还构建符号表，还提供有关任何动态链接库的信息，而加载器只需将可执行文件加载到内存中？为什么我们不能将它们合并呢？
谢谢
Guys I want to why should we separate the linker and loaders prog? What I understand is that linker's produce a relocatable code and also build the symbol table and also provide info about any dynamically linked lib, and the loader's 've to just load the executable files into memory? Why cant we merge them both?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
原因有很多。其中之一与静态库有关，它可能包含数千个不同的函数。但是单个程序可能只使用特定库中的少数函数。如果链接器和加载器是同一个程序，则您必须将整个静态库与您的应用程序一起提供。想象一个只有几千字节大小的小型 C++ 程序。它是通过链接静态运行时库创建的，静态运行时库的大小有很多兆字节。
如果您需要加载程序进行链接，则会增加加载程序的复杂性并增加操作系统内核的大小。链接是一项非常复杂的工作，可能需要花费大量时间。这不是操作系统的工作。操作系统应该关心执行程序，而不是构建它们。
There are a number of reasons. One has to do with static libraries, which may contain thousands of different functions. But a single program might use only a few of the functions that are in a particular library. If the linker and loader were the same program, you'd have to ship the entire static library with your application. Think of a small C++ program that's only a few kilobytes in size. It's created by linking against the static runtime library, that is many megabytes in size.
If you require the loader to do the linking, you increase the complexity of the loader and increase the size of the operating system kernel. Linking is a hugely complex job that can take significant time. It's not the job of the operating system. The OS should be concerned with executing programs, not building them.