时间戳

首页 > 解决方案 > 在 Go 的上下文中，静态和动态链接 wrt 可移植性

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

问题描述

让我首先将一些事实放在桌面上以进行事实检查，以免造成混淆：

现在让我们在 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

david@x1 /tmp (git)-[master] % ldd rtloggerd.cgo1
    linux-vdso.so.1 (0x00007ffd9a972000)
    libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fcb2853c000)
    libc.so.6 => /usr/lib/libc.so.6 (0x00007fcb28378000)
    /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fcb2858a000)

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

130 david@x1 /tmp (git)-[master] % readelf -d rtloggerd.cgo0
There is no dynamic section in this file.

谢谢！

标签： linuxgolinkerglibcelf

解决方案

在 GNU/Linux 上，几乎所有 Go 可执行文件都属于以下类别：

  1. 那些包括应用程序、Go 运行时和 glibc（部分）的静态链接副本。
  2. 那些只包括应用程序和 Go 运行时，静态链接，没有 glibc。
  3. 那些只包括应用程序和 Go 运行时、静态链接和动态链接到 glibc。

不幸的是，与 Go 相关的工具经常将这些链接模式混为一谈。glibc 依赖的主要原因是应用程序使用主机名和用户查找（和 之类的函数getaddrinfo）getpwuid_r。 从（使用 glibc）CGO_ENABLED=0等实现切换到（不使用 glibc）。非 glibc 实现不使用 NSS，因此提供了一些有限的功能（通常不会影响未将用户信息存储在 LDAP/Active Directory 中的用户）。src/os/user/cgo_lookup_unix.gosrc/os/user/lookup_unix.go

在您的情况下，设置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 版本上链接应用程序，它可能会获得特性（符号）在旧版本上不可用，因此该应用程序不适用于这些旧版本。

推荐阅读