假设dynamic库与可执行的精灵不同，只有一点：没有入口点可以开始执行。 就我个人而言，我能够用简单的代码创build一个可执行共享库 – 我刚刚设置了一个入口点。 所以，和调用ld-linux.so几乎一样。 现在请不要把西红柿扔给我，但是如果我在这里，为什么我们不能把两个可执行文件链接在一起 – 如果可执行文件和共享目标文件都具有相同的文件格式并且差别很小？ 为什么我们甚至有可执行文件，但不仅仅是共享对象文件？ 接下来的问题是为什么我们不能简单地提供可执行库而不是可执行文件？ 请尽可能地解释。
这听起来更像是一个哲学问题。 诚然，在ELF上，共享库和可执行文件之间至少有不同的东西。 但是，让我们列举一些可以看出它是否使我们更接近答案的差异：
一个可执行文件只有一个入口点，一个库可以有多个（所有的功能都是潜在的入口点）。
一个可执行文件可以预先重定位到一个静态存储器地址（以前是100％真实的，但现在很多系统实现PIE – 位置独立可执行文件的情况不太常见），尽管存在共享库是尝试的系统。
可执行文件不需要公开任何符号。 共享库需要暴露至少一个符号，否则链接到它是没有意义的。
差异很小。 他们更多地关心优化和组织，而不是其他许多东西，这也是为什么ELF中的可执行文件和库之间的区别非常小，并且不需要太多的调整就可以将其转化为另一个。
我们可以提供可执行的库而不是可执行文件，但为什么？ 这只会令人困惑。 只是因为你能概括一些东西并不意味着这样做是个好主意。 我们在/…/bin中存储可执行文件，因为我们期望程序在那里，以便我们可以在运行它们的时候找到它们，我们将库存储在/…/lib中，因为我们期望图书馆在那里，所以我们当我们需要与他们联系的时候可以找到他们。 标题中的细微差别只是为了避免任何理由的错误和混淆。 我从来没有遇到过“我希望我可以运行这个库”或者“我希望我能连接这个二进制文件”的情况。