解决gccgo在Ubuntu上链接错误：找不到-lgcc_s的指南

本文针对在ubuntu系统上使用gccgo编译go程序时遇到的“cannot find -lgcc_s”链接错误，提供了一种有效的解决方案。该问题源于Ubuntu的一个已知bug，通过在编译时指定-Static-libgcc参数，可以成功地静态链接libgcc库，从而解决编译失败的问题，确保Go程序顺利编译和运行。

问题描述：gccgo链接错误

在使用gccgo编译器在ubuntu系统上编译go程序时，开发者可能会遇到一个常见的链接错误，具体表现为链接器无法找到libgcc_s库。这个错误通常发生在尝试将go源代码编译成可执行文件时，导致编译过程中断并返回错误状态。

以下是一个典型的错误示例：

matt@matt-1005P:~/src/gopath/src/meme$ gccgo cmd/meme/main.go -o meme /usr/bin/ld: cannot find -lgcc_s collect2: error: ld returned 1 exit status

这个错误表明ld（链接器）在标准库路径中未能找到动态版本的libgcc库（即libgcc_s.so）。尽管系统中可能存在其他版本的libgcc，但链接器在默认配置下无法正确识别或定位所需版本，尤其是在特定Ubuntu版本（如Precise，即Ubuntu 12.04）和gccgo版本（如4.7.0）的组合下，这是一个已知的兼容性问题。

问题根源：Ubuntu已知Bug

根据官方社区讨论和错误报告（例如Launchpad上的Bug #966570），gccgo在某些Ubuntu发行版中出现cannot find -lgcc_s的链接问题，被确认为是一个已知的系统级bug。这通常与gccgo包的打包方式或系统默认的链接器配置有关，导致其在寻找特定共享库时出现偏差。

解决方案：静态链接libgcc

为了绕过这个已知的系统bug，最直接且有效的解决方案是强制链接器静态链接libgcc库，而不是尝试寻找动态共享库libgcc_s.so。这可以通过在编译命令中添加-static-libgcc参数来实现。

-static-libgcc参数指示gccgo编译器在链接阶段使用libgcc的静态版本（通常是libgcc.a），而不是默认的动态版本。静态链接意味着libgcc的代码将被直接嵌入到最终的可执行文件中，从而避免了在运行时查找共享库的需要，也解决了编译时找不到libgcc_s.so的问题。

实践操作：使用go build命令

当使用Go的官方构建工具go build来编译Go项目时，可以通过go build命令的-gccgoflags选项来传递gccgo特有的编译参数。

具体操作如下：

go build -compiler gccgo -gccgoflags '-static-libgcc'

命令解析：

• go build: go语言的官方构建命令。
• -compiler gccgo: 指定使用gccgo作为Go程序的编译器，而不是默认的gc（Go Compiler）。
• -gccgoflags ‘-static-libgcc’: 这是关键部分。它告诉go build将字符串’-static-libgcc’作为额外的标志传递给gccgo编译器。单引号是必要的，以确保-static-libgcc作为一个整体参数被传递。

执行此命令后，gccgo将在链接时使用静态libgcc，从而成功完成编译，生成可执行文件。

注意事项与总结

1. 适用性： 此解决方案主要针对在特定Ubuntu版本（如Precise）上使用gccgo时遇到的cannot find -lgcc_s问题。在其他操作系统或更新的Ubuntu版本中，此问题可能已被修复，或者可能存在其他解决方案。
2. 静态链接的副作用： 静态链接libgcc会使最终生成的可执行文件体积略微增大，因为它包含了libgcc的所有必要代码。然而，对于大多数应用而言，这种增幅通常可以接受，并且换来了更好的可移植性（因为运行时不再依赖特定的libgcc_s.so）。
3. 编译器选择： Go语言通常默认使用gc编译器，它通常不会遇到这类c语言运行时库的链接问题。只有当明确需要使用gccgo（例如为了利用GCC的某些特定优化或与其他C/C++库的更紧密集成）时，才需要关注此问题。

通过上述方法，开发者可以有效地解决gccgo在Ubuntu系统上遇到的cannot find -lgcc_s链接错误，确保Go项目的顺利编译和部署。