使用cgo的程序如何交叉编译

最新推荐文章于 2024-03-12 10:20:36 发布

hejingdong123

最新推荐文章于 2024-03-12 10:20:36 发布

阅读量4.3k

点赞数 2

分类专栏：问题记录

本文链接：https://blog.csdn.net/hejingdong123/article/details/102678751

版权

问题记录专栏收录该内容

23 篇文章 1 订阅

订阅专栏

背景

最近在研究读取配置相关的开源项目–libconfig。libconfig项目目前仅支持c版本和c++版本。我们当前项目是用golang编写的，于是就想通过cgo的方式调用libconfig里面的功能。刚开始一切顺利，分别编译libconfig的windows版本库和linux版本库;分别在windows环境和linux环境下写DEMO程序，这些都没有任何问题。

问题出现

由于，我们开发环境在windows系统下，而线上环境是linux。为了发布方便,我们采用了交叉编译。现在通过cgo方式引入libconfig后，问题来了！通过以下脚本编译失败了！

SET GO111MODULE=off
SET CGO_ENABLED=1
SET GOOS=linux
SET GOARCH=amd64
go build -a -v -o cpptest.exe main.go

报错截图如下:
在这里插入图片描述
红色框内,就是报错具体类容了。最开始，一直怀疑是minGW版本问题，换了几个版本，还是同样的报错。后来又想可能是环境变量问题，于是修改脚本如下:

SET GO111MODULE=off
SET CGO_ENABLED=1
set GOHOSTOS=linux
SET CGO_CFLAGS=-Wall
set CGO_LDFLAGS= -static
set CGO_CXXFLAGS=-Wall
set CGO_FFLAGS=-Wall
SET GOOS=linux
SET GOARCH=amd64
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0
go build -a -v -o cpptest.exe main.go

报错情况依然。。。在网上搜索了很多相关帖子，要么没有结贴，要么没有说清楚一个所以然。值到我看到了一篇文章《cgo is not go》，这篇文章从多个方面分析了cgo的优缺点。其中一点，就明确指出Cross compilation goes out the window（交叉编译不支持）。看到这里后，我终于放弃了挣扎！

cgo is not go

最后贴上原博文以及地址吧
欢迎访问原文，原文地址:
cgo is not go 译文
https://www.oschina.net/translate/cgo-is-not-go
cgo不是Go

借用 JWZ 的一句话

有些人，当他们面临一个问题时，认为“我知道，我会使用 cgo ”。那么现在，他们有了两个问题。

最近有人在 Gopher 的 Slack Channel 上使用 cgo，对此我感到十分担心，尤其是竟然有个组织内部打算用一个项目来展示 Go，那真是一个坏主意。对此，我曾说过很多次了，因此也许你们讨厌了我的游说，所以我想到了把它写下来并且去做。

cgo 是一个令人惊异的技术，它允许 Go 程序与 C 的类库交互操作。那是一个极其有用的特征，今天它达到了一个 Go 所无法企及的地位。cgo 是让 Go 程序在 Android 和 iOS 上运行的关键。

然而，这只是我的个人意见，我不为任何人说话，我认为 cgo 在 Go 项目中被过度使用了。我相信当面临需要重载一大段用 Go 编写的 C 代码时，程序员会更愿意选择用 cgo 去打包库而非 Go，因为他们认为那样更容易解决问题。我认为那是虚假经济。

显而易见的，cgo 也存在一些不可避免的问题，最明显的一个问题是作为一个二进制 blog，你不得不与显卡驱动或者窗口系统进行交互 。但是使用 cgo 所存在的问题，经过权衡后，大部分人认为还是比较少的。

当你在 Go 项目上建立一个 cgo 库的时候，你可能没有意识到你的这种权衡其实是不完整的。

终日乾乾
终日乾乾
翻译于 2016/01/21 17:19
顶
2

构建时间变长
当你在包中引用 import “C”，go build 就会做很多额外的工作来构建你的代码，构建就不会仅仅是向 go tool compile 传递一堆 .go 文件了，取而代之的是：

cgo 工具就会被调用，在 C 转换 Go、Go 转换C的之间生成各种文件。

你系统的 C 编译器会被调用来处理你包中所有的C文件。

所有独立的编译单元会被组合到一个 .o 文件。

生成的 .o 文件会在系统的连接器中对它的引用进行一次检查修复。

当你针对这个包编程的时候，所有上面的工作在你编译或者测试的过程中都会进行。Go 工具在可能的情况下，会并行的处理这些工作，但是这个包的编译时间会随着所有 C 代码的构建而增加。

你可以将这部分 C 代码重构出这个包来解决，但是如果你不用 cgo，自然也就不会遇到这个问题。

对了，你还必须调试 C 代码在不同平台的兼容性问题。

drkaka
drkaka
翻译于 2016/01/21 09:08
顶
0

复杂的构造
Go的目标之一是生产一种语言，它的构造过程就是它自我描述的过程；你程序的资源包含了足够的信息来使用一个工具去创建这个项目。这不是说用 Makefile 来自动化构建工程是不好的，但是在cgo被引进项目之前，你创建并且测试不需要任何东西，除了go工具。后来cgo被引入，设置所有的环境变量、跟踪那些可能被安装在奇怪地方的共享对象和头文件，现在这些你都需要做。

记住，Go支持那些不装载开箱即用的平台，所以你不得不花一些时间去提出一个Windows用户的解决方案。

还有，现在你的用户还要安装C编译器，而不是只安装Go编译器。他们同时还需要安装你项目所依赖的C库，所以你同时还要承担这些支持的成本。

终日乾乾
终日乾乾
翻译于 2016/01/26 16:47
顶
1

交叉编译不支持
Go对于交叉编译的支持是最好的。根据Go1.5交叉编译，你可以从任何支持的平台到其他任何平台，通过Go项目网站上的官方许可安装程序。

在默认情况下cgo是不允许交叉编译的。通常这不构成问题，如果你的项目是纯Go的。当你混合了C库的依赖，你或者不得不放弃交叉编译你的产品，或者不得不花时间在寻找并且维护C的交叉编译工具链来达成你的目标。

或许你所做的产品仅通过TCP与客户端通信，并且你计划让它在SaaS（软件服务化 Software as a Service）的模型上运行，那么你根本不关心交叉编译就是合理的。然而，如果你在做一个其他人会用的产品，可能会整合到他们的产品中去，或许那是一个监控解决方案，或许那是一个你SaaS服务的客户端，那么你就把他们很容易交叉编译的特性给锁死了。

Go所支持的平台在持续地增长。Go 1.5增加了64位ARM和PowerPC的支持。Go 1.6增加了64位MIPS的支持， IBM的s390体系结构则在Go 1.7. RISC-V中提供。如果你的产品依赖C库，不仅你要面临以上描述的所有交叉编译问题，你还要确保你所依赖的C代码在Go所支持的新平台上能可靠运行——你必须要做这些运用C/Go混合提供的有限的调试。这又引出了下面的问题。

终日乾乾
终日乾乾
翻译于 2016/01/27 14:42
顶
1

你失去了通向你所有工具的入口
Go有一些伟大的工具；有竞态分析、性能分析、覆盖率、模糊测试和其他源代码分析工具。这些中没有任何一个能够跨越cgo血液或是cgo大脑的屏障。

相反地，像Valgrind这样的优秀工具不理解Go的调用约定和堆栈布局。在这一点上，Ian Lance Taylor的在Go 1.6中将C的内存清理和空指针调试相结合的工作对于cgo的用户来说将会非常有益。

梳理Go的代码和C的代码结果到了两个世界的交汇处，不是结盟；C的内存安全，Go程序的可调试性。

性能永远是一个问题
C代码和Go代码生存在两个不同的宇宙中，cgo横贯了他们两个之间的分界线。这个过渡并不是自由的，它取决于它在你代码中的位置，花费可能是无足轻重的，也可能是巨额的。

终日乾乾
终日乾乾
翻译于 2016/01/29 10:19
顶
1

其它翻译版本 (1)
C 并不了解 Go 的调用协定或堆栈，所以 Go 语言调用到 C 代码时必须首先记录 Go 函数入口堆栈的所有细节，然后切换到 C 的堆栈，运行 C 代码，这部分 C 代码并不知道它如何被调用，更不知道外部的 Go 语言运行时环境。

公平地说，Go 也不知道任何关于 C 的情况。这就是为什么随着编译器和垃圾收集器在定位无用栈帧和堆方面的发展，Go 和 C 两者之间传递数据的规则变得越来越复杂。

如果在 C 的运行过程中出现一个错误，Go 至少得能做到打印错误堆栈信息，然后退出程序，而不是把核心文件都暴露出来。

管理这种双方互相调用的堆栈，再加上在信号、线程和回调，真的很是不容易的。Ian Lance Taylor 在1.6版本的 Go 语言中做了大量的工作来改进与 C 语言信号处理方面的互操作性。

这里要说的是 C 与 Go 语言之间的的互相调用是比较繁琐的，而且永远是会有性能开销的。

雪
雪落无痕xdj
翻译于 2016/01/28 21:43
顶
0