为什么在 Windows 上将动态库链接到静态库显然很容易，但在 Linux 上“-fPIC”却变得困难？

Question

我正在努力调整现有的 ODBC 驱动程序，以便它可以针对 Linux。

ODBC 驱动程序通常在 Windows 上作为 DLL 分发，在 Linux 上作为共享对象 (.so) 分发。

驱动程序依赖于Boost。在 Windows 上，我们始终链接静态 (.lib) 库，没有任何特殊问题！

但是，如果我们想要将 Linux .so 文件静态链接到静态 (.a) 库，我们发现需要使用

-fPIC

重建 Boost（分布式静态库二进制文件通常不使用

-fPIC

进行编译）。

为什么在 Linux 上有这种额外的复杂性，而在 Windows 上却没有？

与 Linux 不同，Windows 总是将其共享库构建为“位置无关代码”吗？

我发现了几个与此主题有些相关的问题，但找不到任何直接解决 Linux 和 Windows 上存在差异的问题

示例：链接 Boost 静态库

Answer 1

为什么在 Linux 上有这种额外的复杂性，而在 Windows 上却没有？

因为 Windows 编译器默认创建

-fPIC

代码，而 UNIX 编译器通常不会。

使用

-fPIC

会导致代码稍慢且稍大，并且在 UNIX 历史的很长一段时间内根本不支持共享库 ，因此当该支持最终实现时，几乎没有理由更改默认并悲观所有现有的二进制文件。

在 Windows 上，我们始终链接静态 (.lib) 库

与您可能认为的相反，在 Windows 上链接到

.lib

不 意味着您正在链接到静态库。 foo.lib

 可能只是 

foo.dll

 的导入库。