go - 必须使用 CGO_ENABLED 时会发生什么

Question

问题

请帮助理解 CGO_ENABLED 何时是必须且不可避免的，以及 go 编译过程会发生什么。

当 CGO_ENABLED 是必须的

在阅读了 引用 中的文章后，它似乎对目标平台有交叉编译原生支持， CGO_ENABLED 永远不会是必须的。它是否正确？

当 cgo 和 CGO_ENABLED 是绝对必须的情况是当 go 编译器无法为目标平台生成二进制代码时。例如，假设我正在用 Go 编写一个 Space X 控制板嵌入式程序，我必须使用 C 库和板的编译器。该板没有其他可用的库或编译器。

在这种情况下，我必须执行 CGO_ENABLED=1 并告诉 cgo 要使用的编译器和链接器以及 C 库二进制文件在我的笔记本电脑中的复制位置，并设置编译器 CFLAGS 等。也许我必须在这种情况下，使用 C 进行所有编码而不是使用 Go，但不知何故，我不得不使用 Go。这是 CGO_ENABLED=1 必须的时候。它是否正确？

否则，如果 Go 特别支持目标平台交叉编译，使用 CGO_ENABLED=1 可能是为目标平台重新使用现有 C 库的捷径。这是正确的还是需要 CGO_ENABLED 的任何其他原因？

发生什么了

我想当使用 CGO_ENABLED=1 时，基本上会有来自Go部分的二进制文件和 go build 命令创建的可执行文件中来自C库的二进制文件的组合。并且在运行时，执行在 go 和 C 两个二进制世界之间来回执行。go 二进制端不知道 C 端，因此调试器等 go 工具将不可用。

我想可执行文件是硬链接(hard link)所有库还是使用动态链接取决于目标平台编译器。

这些是正确的理解吗？

CGO_ENABLED=0 默认交叉编译的原因是因为我们应该使用目标平台交叉编译的go内置支持，没有理由不这样做。

CGO_ENABLED=1 默认情况下本地本地平台的原因是因为 cgo 编译器知道(或编译器的作者知道)本地机器架构和可用的操作系统库(或众所周知的第 3 方)，因此最佳优化可以期待吗？但我不确定这是不是真的，因为 go 编译器本身可以针对本地操作系统和架构进行最佳优化，那么为什么需要使用 cgo 呢？

请解释为什么 CGO_ENABLED=1 默认为本地本地平台。

引用

cgo is not Go

Some people, when confronted with a problem, think “I know, I’ll use cgo.” Now they have two problems.

cgo is an amazing technology which allows Go programs to interoperate with C libraries. It’s a tremendously useful feature without which Go would not be in the position it is today. cgo is key to ability to run Go programs on Android and iOS.

However, and to be clear these are my opinions, I am not speaking for anyone else, I think cgo is overused in Go projects. I believe that when faced with reimplementing a large piece of C code in Go, programmers choose instead to use cgo to wrap the library, believing that it is a more tractable problem. I believe this is a false economy.

Obviously, there are some cases where cgo is unavoidable, most notably where you have to interoperate with a graphics driver or windowing system that is only available as a binary blob. But those cases where cgo’s use justifies its trade-offs are fewer and further between than many are prepared to admit.

Go’s support for cross compilation is best in class. As of Go 1.5 you can cross compile from any supported platform to any other platform with the official installer available on the Go project website.

By default cgo is disabled when cross compiling. Normally this isn’t a problem if your project is pure Go. When you mix in dependencies on C libraries, you either have to give up the option to cross compile your product, or you have to invest time in finding and maintaining cross compilation C toolchains for all your targets.

The number of platforms that Go supports continues to grow. Go 1.5 added support for 64 bit ARM and PowerPC. Go 1.6 adds support for 64 bit MIPS, and IBM’s s390 architecture is touted for Go 1.7. RISC-V is in the pipeline. If your product relies on a C library, not only do you have the all problems of cross compilation described above, you also have to make sure the C code you depend on works reliably on the new platforms Go is supporting — and you have to do that with the limited debuggability a C/Go hybrid affords you. Which brings me to my next point.

Why does CGO_ENABLE make a such impact on virtual memory?

the compiler of the "reference" Go implementation (historically dubbed "gc"; that one, available for download from the main site) by default produces statically-linked binaries. This means, such binaries rely only on the so-called "system calls" provided by the OS kernel and do not depend on any shared libraries provided by the OS (or 3rd parties).

On Linux-based platforms, this is not completely true: in the default setting (building on Linux for Linux, i.e., not cross-compiling) the generated binary is actually linked with libc and with libpthread (indirectly, via libc).

cmd/cgo: document how CGO_ENABLED works today

The cgo tool is enabled by default for native builds on systems where it is expected to work. It is disabled by default when cross-compiling. You can control this by setting the CGO_ENABLED environment variable when running the go tool: set it to 1 to enable the use of cgo, and to 0 to disable it. The go tool will set the build constraint "cgo" if cgo is enabled.

When cross-compiling, you must specify a C cross-compiler for cgo to use. You can do this by setting the CC_FOR_TARGET environment variable when building the toolchain using make.bash, or by setting the CC environment variable any time you run the go tool. The CXX_FOR_TARGET and CXX environment variables work in a similar way for C++ code.

C? Go? Cgo!

cgo

Answer 1

许多东西只能作为 C 库使用，并且在 Go 中重新实现所有内容的成本很高。 cgo 有其缺点，但它可以是一个很好的权衡。甚至标准库也使用它(net 用于 DNS 查找，os/user 用于用户查找)，因为它不会 100% 地重新实现 Go 中的行为。

交叉编译 C 代码仍然相当困难；您将需要目标架构的 C 编译器和工具链(例如 CC=aarch64-linux-musl-gccgo build 来构建 arm64 二进制文件)。默认情况下都没有安装，因此对于大多数人来说，cgo 在交叉编译时根本无法工作；他们需要先手动进行设置。

cgo 通常不是严格要求的(例如在 net 和 os/user 包中)，因此默认禁用它似乎是最用户友好的选项。

但是在原生平台上没有这样的限制，并且预计在没有任何用户设置的情况下默认工作；那么为什么不默认启用它呢？