Go调用Google Cloud语音转文本API报GLIBC版本缺失问题咨询

这个GLIBC版本报错和Google Go API库更新没有直接关系，本质是Go编译时默认开启cgo，动态链接了编译环境的高版本glibc，和Go宣称的可移植性不冲突。你在CentOS本地编译仍出现相同报错，要么是编译时没有关闭cgo，要么是你本地安装的Go版本本身就是动态编译版本，编译过程中链接了当前系统的glibc。
不需要在旧版本系统重编所有依赖，直接在任意环境编译时加以下参数即可解决：

CGO_ENABLED=0 go build -o stt3

编译出的纯静态二进制不依赖任何系统glibc版本，可以直接在CentOS6、CentOS7、Ubuntu等所有Linux发行版上运行。

• Google Cloud API Go语言库源码托管位置：所有官方维护的Google Cloud Go客户端库统一放在Google Cloud官方开源组织下的google-cloud-go主仓库中，按不同云服务拆分对应子目录，Speech-to-Text服务的相关代码就在speech子目录下，库依赖的所有gRPC、proto生成代码也都在同一组织的对应开源仓库内，没有混入闭源二进制组件。
• 源码检索难度高的原因、是否为闭源软件：这类库全部是开源软件，不属于闭源专有软件。检索难度高主要有两点原因：第一，库的拆分粒度非常细，除了核心服务仓库外，大量自动生成的API依赖、工具链依赖分散在同组织的数十个关联仓库中，用户搜索单一服务名时很容易被第三方镜像、过时教程内容干扰，找不到官方源码入口；第二，多数底层依赖是通过Go模块间接引入的，不会直接出现在业务代码的顶层import路径里，顺着依赖链溯源需要逐层核对各层级的go.mod文件，很容易出现遗漏。
• 是否需要放弃Google服务迁移至Nuance或其他同类服务：不需要因为当前的编译问题直接迁移服务。前面提到的纯静态编译方案可以100%解决跨发行版运行的兼容问题，不需要做任何服务侧替换。如果后续遇到识别准确率、调用成本、服务可用性等核心需求不匹配的情况，再结合自身业务场景评估其他服务的适配成本即可，仅因为编译配置问题替换服务的成本过高，完全没有必要。
• 官方bug反馈渠道：这类客户端库的问题可以直接在对应源码托管仓库的Issue区提交反馈，提交时需要附上你使用的Go版本、依赖库版本、完整编译命令、报错日志、可以稳定复现问题的最小代码片段。注意你当前遇到的问题属于Go通用编译配置问题，并非客户端库本身的代码缺陷，提交前可以先检索历史Issue确认是否有同类问题记录，避免提交无效反馈。

内容的提问来源于stack exchange，提问作者user60381