问题标签 [cgo]

我见过很多不同的方法可以做到这一点，就必须使用大量包装器和回调而言，它们似乎都不理想。有没有一种简单的方法可以做到这一点？

例如，我们有这个：

现在这已被精简到最低限度，此时我想做的就是SayFive在 C 中调用该函数。

但是，不在此文件的顶部。能够做到这一点非常简单和有用，但我正在寻找这样的方法：

我在上面的例子中看到过，#include "_cgo_export.h"这是完全有道理的，但是当我这样做并尝试编译它时，它失败了。

任何人都可以解释允许我们这样做的整个过程吗？

编辑：这个问题没有实际意义。我误读了提交的日期，它包含在 Go 工具的现有版本中。谢谢，詹姆斯！

似乎即将发布的 Go (1.3) 将允许非 Go 线程调用 CGO 回调。

我想知道迄今为止人们通常会做什么来绕过这个限制。

也就是说，我有一个自己创建线程的第三方库，我想从这些线程中获取一些信息到 Go 代码中。

某种从 C 线程到代码“C”端的 Go 线程的切换机制？有什么方法可以在不调用 Go 的情况下将消息放入队列？其他想法？

我正在尝试通过 C 将 sqlite3 与 cgo 一起使用（我知道 go 有一个 sqlite3 包装器，但想尝试这种方式）。这个程序给了我一个错误信息

，我不明白为什么-有人可以帮助我了解如何打开新的数据库流吗？

}

Suppose, we've got a Go function, which is doing something with agruments, passed to them, e.g. it could fill the buffer, allocated in the C part and changing it and for example an integer argument, which is a size of read data. It works well with an integer one, but not with a "data part". Just see a code.

As a result, we've got following:

As you can see, it works well for integer pointer, but not for uint8_t.

我有以下两个文件：

桥接程序：

立方体.c：

以及一个调用的 main.go 文件，仅此cube.Init()而已。

我的问题在于调用C.render. 如果我这样做time.After，它可以正常工作并按预期显示一个蓝色窗口。如果我做 a time.Tick，它很少会显示那个蓝色窗口，但要么显示黑色窗口，要么显示段错误。这个测试用例很大程度上是从我的实际代码中总结出来的。

我有一种感觉，go 的调度程序以某种方式把事情搞砸了，但我想不出如何（或如何测试/修复它）。我很好奇是否有人有任何想法是什么导致了这种情况，或者可以想出任何进一步调查的方法。

其他可能重要的信息：

• Arch linux，3.14.4-1-ARCH.x86_64
• GLFW 3.0.4-1
• GLEW 1.10.0-2
• 英伟达 GeForce GTX 570M
• 英伟达驱动程序 337.12-1
• go1.2 linux/amd64

编辑：

这是段错误消息：

它似乎在调用时出现段错误glClearColor

有一些 C 对象，如联合、包含位域的结构和对齐方式与 Go 的 ABI 不同的结构，无法从 Go 访问。其中一些结构无法更改为可从 Go 代码访问，因为它们是现有库的 API 的一部分。

要将这些对象编组到 Go 结构中，我们因此不能真正使用 Go 代码。相反，我们必须用 C 编写编组代码。这很好用，但我还没有找到一种可行的方法来定义对 Go 代码中定义的类型进行操作的 C 函数。现在我正在定义我在 C 端编组的数据类型，并在我的 Go 代码中使用这些数据类型。

如果我想在我的 Go 代码中将编组的类型作为 API 公开，这真的很讨厌，因为我不能将 C 类型公开为我的包接口的一部分。我目前的方法是将已经编组的对象重新编组为 Go 代码中定义的类型。

有没有更优雅的方法来做我想做的事情，即将 Go 代码无法访问的 C 结构编组为 Go 代码中定义的数据类型？

根据评论部分的要求，这里是一组无法从 Go 访问的 C 对象。

我尝试使用 Go 1.3 在我的 darwin/amd64 MBP 上将 cgo 代码交叉编译到 linux/arm，但没有成功:(

我的环境：

go version go1.3 darwin/amd64

我的目标：

交叉编译针对 linux/arm 的 cgo 代码。

步骤1：

使用 ct-ng 构建 gcc/g++ 交叉编译器。arm-unknown-linux-gnueabi-g++构建and的路很长arm-unknown-linux-gnueabi-gcc，但我终于做到了。我用简单的 C/C++ 程序进行了测试，输出在我的 linux/arm R-Pi 机器上运行良好。

第2步：

cd /path/to/go/src

sudo CGO_ENABLED=1 CC_FOR_TARGET=/path/to/arm-unknown-linux-gnueabi-gcc CXX_FOR_TARGET=/path/to/arm-unknown-linux-gnueabi-g++ GOOS=linux GOARCH=arm ./make.bash

一切正常。

第 3 步：

编译以下简单的 cgo 代码：

对于我的主机：

go install package/of/test

失败了

arm-unknown-linux-gnueabi-gcc: error: unrecognized command line option '-m64'

对于 linux/arm：

GOOS=linux GOARCH=arm go install package/of/test

失败了

runtime.main：调用外部函数 main.main runtime.main：

未定义：main.main

任何想法？谢谢。

我正在使用本机 linux C 二进制文件，它有一个相当昂贵的初始化调用，我想在应用程序启动时执行一次。这个调用应该在内部打开一堆文件句柄供以后使用。当我从 Go 调用这个昂贵的初始化 C 函数时，它成功完成并正确打开文件，但这些句柄仅在调用 C 函数期间打开！这意味着当我从 Go 中针对同一个库调用连续的 C 函数时，文件句柄不再打开并且调用失败。我已经使用 lsof 命令验证了这一点。有趣的是，当初始化调用以及对后续行为的调用被组合成一个 C 函数时，然后从 Go 调用该函数，文件将打开并保持打开状态，从而成功完成所有所需的功能。

是否存在某种未记录的 cgo 行为，即在从 Go 多次调用 C 函数之间“清理”、关闭甚至泄漏文件句柄或其他有状态资源？如果是这样，这种行为是否可配置？我们无权访问此库的源代码。

此外，我已经验证这与线程本地存储无关。调用runtime.LockOSThread()没有效果，我们已经验证了在控制权从 C 返回到调用 Go 代码后文件已关闭。

这是我想编写的 Go 代码示例：

这是一个同时调用初始化和行为的 C 函数示例。这个“包装”函数是从 Go 调用的：

我有一个为 C++ OpenImageIO库 ( OpenImageiGO )提供绑定的 Go 库。我一直很高兴通过标准动态链接到 libOpenImageIO 来构建我的绑定，但现在我正在尝试静态链接。我遇到了一个问题，无论我尝试哪种标志组合，外部链接器都会失败并出现大量“未定义引用”错误。我似乎记得在过去看到过这个问题，说链接器看到符号的顺序存在问题。但我似乎无法再次找到此信息。

这是我最近构建尝试的一个简短示例，试图让它链接到 boost、OpenColorIO 和 OpenImageIO 的静态构建：

这里有一些精心挑选的错误，因为它是一个很长的输出：

OpenImageIO 似乎无法找到 OpenColorIO 的参考资料。而且，OpenImageIO 似乎无法找到提升的参考。似乎链接过程中发生的事情的顺序并没有使 OpenColorIO 或增强符号对 OpenImageIO 可用，所以我得到了一堆符号错误。

我希望我正在做一些简单而愚蠢的事情，可以在我的构建过程中得到纠正。但是与外部库的 cgo 静态链接似乎比默认的动态链接方法更复杂。

更新#1

@james-henstridge 给出的答案是正确的，我几乎完全建成，除了最后一个打嗝。尽管我的顺序似乎正确，但我对yaml-cpp, required by 的引用却失败了。OpenColorIO

这是我最新的环境，在那里我完成了所有必须添加的显式静态库：

更新#2

没关系更新＃1。它与问题特别相关，OpenColorIO而不是一般问题。

所以我将xxhash从使用 cgo 移植到 Go 的原生 9p C，但是我遇到了一个相当奇怪的问题。

如果作为 cgo 函数调用，哈希函数工作得非常好，但是如果我尝试使用“本机”版本，它会返回错误的哈希。

我知道足够的 C 来让它工作，但在报告问题之前，我想确保我没有做错任何事情。

要旨

xxhash.go：

xxhash_9p.c：

跑：

TL;博士：

通过 Go 的 6c 使用 AC 函数返回错误的值，通过 CGO 调用相同的 C 函数返回正确的值。

//编辑

我收到了关于这个问题的回复，它不会得到修复，而且 9p 工具链最终会消失。

来自mi...@golang.org：

C 编译器最终会消失。为此做好计划，所以不要依赖它。

请注意，Plan 9 C 编译器并不完全符合 ANSI，我们不会修复其中的错误（因为我们控制编译器及其输入，所以我们只会解决它的错误）。