在 Go 的上下文中，静态和动态链接 wrt 可移植性

Question

让我先把一些事实摆在桌面上进行事实核查，以免造成混淆：

• 带有动态部分的 ELF 二进制文件在编译时会带有一些未解析的符号。解析将在二进制文件执行期间的某个时间由链接器执行。

• 动态链接有利也有弊。但是，如果您的二进制文件所需的目标库不存在于系统中（在所需版本中），则二进制文件将不会运行。

• 静态链接缓解了这个问题，但在下层引入了一个新问题。通过静态链接二进制文件，库的可执行代码嵌入到您的二进制文件中，因此二进制库接口不再有问题。但是，现在库-OS 界面可能会出现问题。那是对的吗？这里可能会出现什么问题？

现在让我们在 Go 的上下文中讨论这个问题。我注意到，如果我使用 构建一个二进制文件CGO_ENABLED=1 go build ...，我会得到一个带有动态部分的二进制文件：

david@x1 /tmp (git)-[master] % readelf -d rtloggerd.cgo1

Dynamic section at offset 0x7a6140 contains 19 entries:

  Tag        Type                         Name/Value

 0x0000000000000004 (HASH)               0x914e40

 0x0000000000000006 (SYMTAB)             0x915340

 0x000000000000000b (SYMENT)             24 (bytes)

 0x0000000000000005 (STRTAB)             0x915100

 0x000000000000000a (STRSZ)              570 (bytes)

 0x0000000000000007 (RELA)               0x914a38

 0x0000000000000008 (RELASZ)             24 (bytes)

 0x0000000000000009 (RELAENT)            24 (bytes)

 0x0000000000000003 (PLTGOT)             0xba6000

 0x0000000000000015 (DEBUG)              0x0

 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]

 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

 0x000000006ffffffe (VERNEED)            0x914de0

 0x000000006fffffff (VERNEEDNUM)         2

 0x000000006ffffff0 (VERSYM)             0x914d80

 0x0000000000000014 (PLTREL)             RELA

 0x0000000000000002 (PLTRELSZ)           816 (bytes)

 0x0000000000000017 (JMPREL)             0x914a50

 0x0000000000000000 (NULL)               0x0

另一方面，如果 I 时CGO_ENABLED=0 go build ...没有动态部分：

130 david@x1 /tmp (git)-[master] % readelf -d rtloggerd.cgo0

There is no dynamic section in this file.

• 这是否意味着库是静态链接的？我想是的，但大小差异在我的机器上可以忽略不计（大约 72 kB），这让我感到惊讶。

• 关于跨 Linux 系统的可移植性，哪个更好，为什么？

• Go的标准库是如何开展业务的呢？它实际上是在调用libc（在我的例子中）提供的 C 函数吗？glibc我假设有一个本地系统调用接口。另一方面，我想在原生 Go 中重新实现整个 stdlib 会很困难。

• 最后，我听说“不能保证不同的发行版，甚至同一发行版的不同版本都兼容 ABI”。这是真的？我假设 ABI 主要是二进制可执行格式（Linux 上的 ELF 有一段时间），所以我假设这里没有问题。这意味着什么？

谢谢！

Answer 1

在 GNU/Linux 上，几乎所有的 Go 可执行文件都属于这些类别：那些包括应用程序、Go 运行时和 glibc（的一部分）的静态链接副本。那些只包含应用程序和 Go 运行时的静态链接，没有 glibc。那些只包括应用程序和 Go 运行时、静态链接和动态链接到 glibc 的。不幸的是，与 Go 相关的工具通常会混淆这些链接模式。依赖 glibc 的主要原因是应用程序使用主机名和用户查找（功能如getaddrinfo和getpwuid_r）。 CGO_ENABLED=0从src/os/user/cgo_lookup_unix.go（使用 glibc）等实现切换到src/os/user/lookup_unix.go（不使用 glibc）。非 glibc 实现不使用 NSS，因此提供的功能有些有限（通常不会影响不在 LDAP/Active Directory 中存储用户信息的用户）。在您的情况下，设置CGO_ENABLED=0将您的应用程序从第三类移至第二类。（还有其他与 Go 相关的工具可以构建第一种应用程序。）非 NSS 查找代码不是很大，因此二进制大小的增加并不显着。由于 Go 运行时已经静态链接，静态链接减少的开销甚至可能导致可执行文件大小的净减少。这里要考虑的最重要的问题是 NSS、线程和静态链接在 glibc 中并不是那么好。所有的 Go 程序都是多线程的，（静态）将 glibc 链接到 Go 程序中的原因正是访问 NSS 函数。因此，将 Go 程序静态链接到 glibc 始终是错误的做法。它基本上总是 有问题。即使 Go 程序不是多线程的，使用 NSS 函数的静态链接程序在运行时也需要与构建时使用的 glibc版本完全相同，因此此类应用程序的静态链接会降低可移植性。所有这些都是第一类 Go 应用程序如此糟糕的原因。使用 生成静态链接的应用程序CGO_ENABLED=0没有这些问题，因为这些应用程序（第二类）不包含任何 glibc 代码（以用户/主机查找功能的功能减少为代价）。如果你想创建一个需要 glibc 的可移植二进制文件，你需要动态链接你的应用程序（第三种），在你想要支持的最旧的 glibc 系统上。然后应用程序将在该 glibc 版本和所有更高版本上运行（目前，Go 没有正确链接 libc，所以即使是 glibc 也没有很强的兼容性保证）。发行版通常与 ABI 兼容，但它们具有不同版本的 glibc。glibc 竭尽全力确保动态链接到旧版本 glibc 的应用程序将继续在新版本的 glibc 上运行，但反之则不然：一旦您将应用程序链接到特定版本的 glibc，它可能会获得功能（符号）在旧版本上不可用，因此该应用程序将无法与那些旧版本一起使用。