有静态库，然后有共享库。如果需要的话，难道不可能只拥有共享的并静态链接它们吗？
用-fPIC编译一次，不编译一次似乎是浪费。我对汇编不太了解，但把可重新定位的代码转换成静态代码的速度难道不应该比重新编译所有代码快几个数量级吗？
这部分是历史问题。曾经只有静态库。它们被静态地链接到系统编译的每个二进制文件。然而，这是一场维护噩梦，需要在修补或更改库时重新编译所有正在使用的包。
然后共享库出现了，解决了这些问题。现在，对于您的问题，首先，在静态链接的库中可以进行一些重要的优化，而这些优化是不可能在动态库上执行的，因此，即使将动态库转换为静态库，其效率也可能低于最初静态编译的代码。
其次，大多数现代系统都只使用共享库，所以没有太大问题，作为共享库只编译一次。
顺便说一句，尽管仍然相关，你可能会考虑预链接。这一步骤减少了一些启动开销（尽管仍不一定能达到与静态链接相同的性能），并允许在库中动态链接的软件更快地启动。
尽管在理论上，肯定可以将动态库后期处理为静态库，但这项任务的难度——尤其是做好这项任务——将与从头开始编译相当。通过后处理和从头开始执行静态构建获得相同的结果可能比简单地重新构建更困难，而且任何这样做的工具都会承担自己的维护负担。既然已经有很好的方法来实现同样的目标，为什么还要这么做呢？
此外，决不需要同时构建静态库和共享库。即使在您想这样做的地方，这样做的增量成本也（应该）只是整个开发时间的一小部分。
当您希望可执行文件不依赖于某个库时，您将使用静态库。基本上，库是在可执行文件中"附带"的。
当然，这是非常情境化的，因为大多数时候共享图书馆是可行的。