c - 将共享库链接到静态库 : must the static library be compiled differently than if an application were linking it?

Question

至少在 Linux 和 Solaris 上，静态库实际上只是一堆编译后的 .o 被扔进一个大文件中。编译静态库时，通常会省略 -fpic 标志，因此生成的代码是位置相关的。

现在说我的静态库是 B。我已经构建了它并得到了生成的 .a 文件，它实际上只是所有位置相关的 .o 文件的集合。现在我有一个要构建的共享库 A，我希望它静态链接 B。当我构建 A 时，我自然会使用 -fpic 标志使生成的代码位置独立。但是如果我链接 B，我不是混合了位置相关和位置无关的目标文件吗？

除非我还指定了 -mimpure-text，否则我会遇到很多文本重定位错误，我认为这可能是原因。看来我编译库的时候真的要编译3次，一个shared版本，一个static版本，一个static-that-c​​an-used-by-shared-libs版本.我对吗？我可以继续使用 -mimpure-text 但 g++ 手册页说，如果你这样做，对象实际上并没有最终被共享(目前还不清楚它是全部未共享还是只是静态链接的部分，有人知道吗？) .

Answer 1

您不必在共享对象中使用 PIC 代码(正如您发现的那样，您可以使用 -mimpure-text 选项来允许这样做)。

也就是说，共享对象中的非 PIC 代码更重量级。使用 PIC 代码，内存中的文本页只是磁盘上文本页的直接内存映射。这意味着如果多个进程正在使用共享对象，它们可以共享内存页。

但是如果您没有 PIC 代码，当运行时链接器加载共享对象时，它必须对文本页面应用修正。这意味着使用共享对象的每个进程都将拥有它自己的任何文本页面的唯一版本，该文本页面上有修复(即使共享对象加载到与写时复制相同的地址，只注意到该页面是修改而不是它以相同的方式修改)。

对我来说，重要的问题是您是否会同时运行多个进程，每个进程都加载共享对象。如果这样做，确保 SO 中的所有代码都是 PIC 绝对值得。

但如果不是这种情况，并且只有一个进程加载了共享对象，那么它就没有那么重要了。