我正在使用包含 libLLVM*.so 文件和相应的 libLLVM*.a 文件的本地 LLVM 构建来构建 Julia。这是首先使用 BUILD_SHARED_LIBS=ON 构建的，它负责 libLLVM*.so 文件的存在。
libjulia.so，julia 可执行文件使用的库，始终链接到 libLLVM*.so 文件，即使我使用 BUILD_SHARED_LIBS=OFF（默认配置）重建 LLVM。 llvm-config --libs $LIB 的输出有和没有BUILD_SHARED_LIBS=ON 变化不大，似乎没有任何迹象表明llvm-config 发出链接选项，引导链接器链接*.so 文件或*.a 文件。
为什么会这样？即使存在 .a 同名文件，链接器是否默认使用 .so 文件？或者，是否有 Julia 重用的构建配置缓存？
【问题讨论】：
是的，要满足选项-lfoo，ld 将默认链接libfoo.so 而不是libfoo.a，如果两者都
在同一个搜索目录中找到，当它找到任何一个时
不会再看了。
您只能通过将-static 传递给链接来强制静态库的链接，
但在这种情况下，必须为 all 库找到静态版本 - 包括
默认系统库——不仅仅是那些你明确提到的。
要选择性地链接静态库libfoo.a，而不指定-static，
您可以使用 -l 选项的显式形式：-l:libfoo.a 而不是
-lfoo.
llvm-config 将在-lfoo 表单中发出库选项，无论您构建
静态或共享库，因为这些选项适用于
要么，但是您需要了解在使用它们时链接器如何
行为。如果你不告诉它，它会链接共享而不是
比静态库面临选择的时候。
稍后
为什么 ld 更喜欢链接共享库而不是静态库？
AFAIK，ld 的开发人员为何长期做出这个决定并没有记录在案
以前，但原因很明显：如果动态链接是默认的，那么
默认情况下，可执行文件不会物理包含额外的代码副本
可以通过共享库中的单个共享副本提供给所有可执行文件。因此
默认情况下，可执行文件将节省其代码大小和
构成您的系统或我的系统的可执行文件将大大小于
它必须没有共享。共享库和动态链接
被发明出来是为了让系统不必因为重复的代码而臃肿。
动态链接带来了可执行文件的复杂性 与共享库链接，当分发到系统以外的系统时 它是在其上构建的，它不携带它的动态依赖关系。它是 因此，所有已批准的安装新二进制文件的机制 在系统上 - 包管理器 - 确保它们的所有动态依赖项 也安装好了。
【讨论】：
ld 更喜欢链接共享库而不是静态库？