深圳聘请做网站人员特色产品推广方案
问题描述
在一台ubuntu 20的机器上通过go 编译生成的可执行程序(使用了cgo)，在其他ubuntu机器上运行时出现如下问题
/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found
问题分析
因为go代码里的依赖库使用到了sndfile，它必须使用cgo了，所以需要gcc基础库依赖。 在编译机器上的gcc版本比较高，在运行机器上的gcc版本稍微老了一点点，所以在运行时抛出了异常。
我们可以使用如下命令来查看当前机器上gcc的版本
strings libc.so.6 | grep GLIBC_
GLIBC_2.2.5
GLIBC_2.2.6
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.3.4
GLIBC_2.4
GLIBC_2.5
GLIBC_2.6
GLIBC_2.7
GLIBC_2.8
GLIBC_2.9
GLIBC_2.10
GLIBC_2.11
GLIBC_2.12
GLIBC_2.13
GLIBC_2.14
GLIBC_2.15
GLIBC_2.16
GLIBC_2.17
GLIBC_2.18
GLIBC_2.22
GLIBC_2.23
GLIBC_2.24
GLIBC_2.25
GLIBC_2.26
GLIBC_2.27
GLIBC_2.28
GLIBC_2.29
GLIBC_2.30
GLIBC_PRIVATE可以看到这里的最大版本就是2.30，所以不支持编译时所使用的2.32
解决思路
有两个思路，一是提升运行环境的gcc版本，二是降低编译环境的gcc版本
但是注意，无论哪一种，我都强烈反对直接对机器的gcc版本做升级或者降级
因为libc是很多基础软件，包括os的底层依赖，一旦单独更新了这个版本，能可能造成整个系统的不稳定，甚至是崩溃。
解决方案
一、 提升运行环境的gcc版本
可以采用容器技术，将该程序部署到指定版本的ubuntu容器中执行
二、 降低编译环境的gcc版本
方案1：
通过CGO参数，可以指定gcc的版本。 不过这个前提是你需要在目标机器上把libc.so文件拷贝出来，然后复制到编译机器上。（注意：不要放置到系统路径下）
然后通过如下参数来编译
CGO_LDFLAGS='-g -O2 -Wl,-rpath=. -Wl, --dynamic-linker=ld-linux-x86-64.so.2' CGO_CFLAGS="-L. -l/my/path/libc.so.6,/my/path/ld-linux-x86-64.so.2"go build
其中-rpath是指运行时指定寻找libc.so的路径，请根据你的环境来修改。
编译完成后，通过ldd看以下依赖.
但是需要注意的是，如果依赖的二进制库也是依赖libc编译的，那么这些库可能也存在一样的依赖问题。所以这种情况只适合没有其他依赖库依赖cgo的情况。
验证
使用LD_PRELOAD可以加载与本机不同的libc来运行程序
LD_PRELOAD=/lib64/libc.so xxx
方案2：
同样采用容器化来部署相同的编译环境
参考
Multiple glibc on a Single Linux Machine
gcc link options
Dynamic Linking to a Different libc
overwrite default /lib64/ld-linux-x86-64.so.2 to call executables