首頁猿問在 Go...

在 Go 的上下文中，靜態(tài)和動態(tài)鏈接 wrt 可移植性

Go

慕虎7371278 2023-06-01 17:08:38

讓我先把一些事實(shí)擺在桌面上進(jìn)行事實(shí)核查，以免造成混淆：帶有動態(tài)部分的 ELF 二進(jìn)制文件在編譯時(shí)會帶有一些未解析的符號。解析將在二進(jìn)制文件執(zhí)行期間的某個(gè)時(shí)間由鏈接器執(zhí)行。動態(tài)鏈接有利也有弊。但是，如果您的二進(jìn)制文件所需的目標(biāo)庫不存在于系統(tǒng)中（在所需版本中），則二進(jìn)制文件將不會運(yùn)行。靜態(tài)鏈接緩解了這個(gè)問題，但在下層引入了一個(gè)新問題。通過靜態(tài)鏈接二進(jìn)制文件，庫的可執(zhí)行代碼嵌入到您的二進(jìn)制文件中，因此二進(jìn)制庫接口不再有問題。但是，現(xiàn)在庫-OS 界面可能會出現(xiàn)問題。那是對的嗎？這里可能會出現(xiàn)什么問題？現(xiàn)在讓我們在 Go 的上下文中討論這個(gè)問題。我注意到，如果我使用構(gòu)建一個(gè)二進(jìn)制文件CGO_ENABLED=1 go build ...，我會得到一個(gè)帶有動態(tài)部分的二進(jìn)制文件：david@x1 /tmp (git)-[master] % readelf -d rtloggerd.cgo1Dynamic 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 時(shí)CGO_ENABLED=0 go build ...沒有動態(tài)部分：130 david@x1 /tmp (git)-[master] % readelf -d rtloggerd.cgo0There is no dynamic section in this file.這是否意味著庫是靜態(tài)鏈接的？我想是的，但大小差異在我的機(jī)器上可以忽略不計(jì)（大約 72 kB），這讓我感到驚訝。關(guān)于跨 Linux 系統(tǒng)的可移植性，哪個(gè)更好，為什么？Go的標(biāo)準(zhǔn)庫是如何開展業(yè)務(wù)的呢？它實(shí)際上是在調(diào)用libc（在我的例子中）提供的 C 函數(shù)嗎？glibc我假設(shè)有一個(gè)本地系統(tǒng)調(diào)用接口。另一方面，我想在原生 Go 中重新實(shí)現(xiàn)整個(gè) stdlib 會很困難。最后，我聽說“不能保證不同的發(fā)行版，甚至同一發(fā)行版的不同版本都兼容 ABI”。這是真的？我假設(shè) ABI 主要是二進(jìn)制可執(zhí)行格式（Linux 上的 ELF 有一段時(shí)間），所以我假設(shè)這里沒有問題。這意味著什么？謝謝！

查看完整描述

1 回答

楊__羊羊

TA貢獻(xiàn)1943條經(jīng)驗(yàn) 獲得超7個(gè)贊

在 GNU/Linux 上，幾乎所有的 Go 可執(zhí)行文件都屬于這些類別：

那些包括應(yīng)用程序、Go 運(yùn)行時(shí)和 glibc（的一部分）的靜態(tài)鏈接副本。
那些只包含應(yīng)用程序和 Go 運(yùn)行時(shí)的靜態(tài)鏈接，沒有 glibc。
那些只包括應(yīng)用程序和 Go 運(yùn)行時(shí)、靜態(tài)鏈接和動態(tài)鏈接到 glibc 的。

不幸的是，與 Go 相關(guān)的工具通常會混淆這些鏈接模式。依賴 glibc 的主要原因是應(yīng)用程序使用主機(jī)名和用戶查找（功能如getaddrinfo和getpwuid_r）。?CGO_ENABLED=0從src/os/user/cgo_lookup_unix.go（使用 glibc）等實(shí)現(xiàn)切換到src/os/user/lookup_unix.go（不使用 glibc）。非 glibc 實(shí)現(xiàn)不使用 NSS，因此提供的功能有些有限（通常不會影響不在 LDAP/Active Directory 中存儲用戶信息的用戶）。

在您的情況下，設(shè)置CGO_ENABLED=0將您的應(yīng)用程序從第三類移至第二類。（還有其他與 Go 相關(guān)的工具可以構(gòu)建第一種應(yīng)用程序。）非 NSS 查找代碼不是很大，因此二進(jìn)制大小的增加并不顯著。由于 Go 運(yùn)行時(shí)已經(jīng)靜態(tài)鏈接，靜態(tài)鏈接減少的開銷甚至可能導(dǎo)致可執(zhí)行文件大小的凈減少。

這里要考慮的最重要的問題是 NSS、線程和靜態(tài)鏈接在 glibc 中并不是那么好。所有的 Go 程序都是多線程的，（靜態(tài)）將 glibc 鏈接到 Go 程序中的原因正是訪問 NSS 函數(shù)。因此，將 Go 程序靜態(tài)鏈接到 glibc 始終是錯誤的做法。它基本上總是?有問題。即使 Go 程序不是多線程的，使用 NSS 函數(shù)的靜態(tài)鏈接程序在運(yùn)行時(shí)也需要與構(gòu)建時(shí)使用的 glibc版本完全相同，因此此類應(yīng)用程序的靜態(tài)鏈接會降低可移植性。

所有這些都是第一類 Go 應(yīng)用程序如此糟糕的原因。使用生成靜態(tài)鏈接的應(yīng)用程序CGO_ENABLED=0沒有這些問題，因?yàn)檫@些應(yīng)用程序（第二類）不包含任何 glibc 代碼（以用戶/主機(jī)查找功能的功能減少為代價(jià)）。

如果你想創(chuàng)建一個(gè)需要 glibc 的可移植二進(jìn)制文件，你需要動態(tài)鏈接你的應(yīng)用程序（第三種），在你想要支持的最舊的 glibc 系統(tǒng)上。然后應(yīng)用程序?qū)⒃谠?glibc 版本和所有更高版本上運(yùn)行（目前，Go 沒有正確鏈接 libc，所以即使是 glibc 也沒有很強(qiáng)的兼容性保證）。發(fā)行版通常與 ABI 兼容，但它們具有不同版本的 glibc。glibc 竭盡全力確保動態(tài)鏈接到舊版本 glibc 的應(yīng)用程序?qū)⒗^續(xù)在新版本的 glibc 上運(yùn)行，但反之則不然：一旦您將應(yīng)用程序鏈接到特定版本的 glibc，它可能會獲得功能（符號）在舊版本上不可用，因此該應(yīng)用程序?qū)o法與那些舊版本一起使用。

反對回復(fù) 2023-06-01