我正在使用Windows 10.当我尝试构建Chaincode时,它报告了此错误
# github.com/hyperledger/fabric/vendor/github.com/miekg/pkcs11
exec: "gcc": executable file not found in %PATH%
我的链码导入:
import (
"fmt"
"strconv"
"github.com/hyperledger/fabric/core/chaincode/shim"
pb "github.com/hyperledger/fabric/protos/peer"
)
它在Docker中运行良好.
所以团队中有很多东西建议你可以在go中执行此操作(尽管不在cgo文档中):
package bridge
import "fmt"
// #cgo CFLAGS: -I/Users/doug/projects/c/go-bridge/include
// #cgo LDFLAGS: /Users/doug/projects/c/go-bridge/build/libgb.a
// #include <junk.h>
import "C"
func Run() {
fmt.Printf("Invoking c library...\n")
C.x(10)
fmt.Printf("Done\n")
}
但是,它似乎不起作用:
/var/folders/.../bridge.a(bridge.cgo2.o)(__TEXT/__text): x: not defined
这似乎可以正常使用动态库,并检查生成的文件,它实际上有符号'x':
/var/folders/rg/hj4s3qlj3sz1d1b5p50ws0vc0000gn/T/go-build442792776/bridge/_obj/_cgo_.o:
0000000100001048 S _NXArgc
0000000100001050 S _NXArgv
0000000100001060 S ___progname
0000000100000dc0 T __cgo_2d7eefe3d6d4_Cfunc_x
0000000100000da0 T __cgo_allocate
0000000100000db0 T __cgo_panic
0000000100000000 T __mh_execute_header
0000000100000d90 T _crosscall2
0000000100001058 S _environ
U _exit
0000000100000d80 T _main
U _puts
0000000100001000 s _pvars
0000000100000de0 T _x <------- Exists
U dyld_stub_binder
0000000100000d40 T …(非常详细的问题报告 - tl;底部是博士!)
我真的更喜欢GLFW到Glut,并希望它的Golang绑定在Windows 64位下使用Go 1.0.1 64位.在Linux下,它的绑定完美无瑕.这在原则上是在Windows下是可行的- GitHub的用户家校会设法来做到这一点,但他是在Win32和他的提示没有解决我的问题呢.但是我确实有一个基于tdm64-gcc-4.6.1的完整而干净的Mingw64设置.
Now here's the strange thing -- getting the freeglut binding to work under 64-bit Windows, 64-bit Go 1.0.1 works -- the glfw binding fails for me. I want to figure out why, as they essentially both use the same cgo features and techniques.
Note I currently have a self-made half-baked but essentially working replacement package in place that uses LoadLibrary/GetProcAddress calls to expose glfw.dll in …
我正在尝试为Go语言编写一些C绑定,并且在Windows中设置Cgo编译时遇到了一种棘手的情况.我的代码如下所示:
// #cgo windows CFLAGS: -I C:/dev/extlibs/include/
// #cgo windows LDFLAGS: -lMyLib -L C:/dev/extlibs/lib/
// #include <mylib/mylib.h>
import "C"
这让我避免安装的DLL库和头文件直接到我的C:\ Windows目录,但是当其他开发人员使用不同的文件系统设置程序(它们都需要库是工作不允许太多的灵活性在C:/ dev/extlibs/...).
有没有办法可以从代码中引用环境变量？也许是这样的:
// #cgo windows CFLAGS: -I $EXTLIBS$/include/
还是有另一种方式让人们解决我错过的这个问题？我花了一些时间在这个主题上搜索,并没有看到很多有用的东西,所以任何信息和/或资源都可以成为真正的帮助!
我有一个指向由Go结构包装的C类型的指针,如下所示:
type Wrapper struct {
unmanaged *C.my_c_type
}
反过来,C类型具有以下功能:
my_c_type* make_c_type();
void free_c_type(my_c_type *ct);
有没有一种方法可以确保free_c_type在Wrapper实例最终确定时调用？
我想包装一个C函数,该函数char*指向非空字节缓冲区(的第一个元素).我正在尝试使用CGo将它包装在Go函数中,以便我可以传递它[]byte,但我不知道如何进行转换.C函数签名的简化版本是
void foo(char const *buf, size_t n);
我尝试将指针传递给byte切片中的第一个
C.foo(&b[0], C.size_t(n))
但是,这不会编译:
cannot use &b[0] (type *byte) as type *_Ctype_char in function argument
那么这里的正确程序是什么？在去维基仅描述了相反的情况.
这是这个问题的后续行动.我在那里假设可能不是真的,这就是我明确询问它的原因.因为我忘了询问这是否真的可行,所以我已经提交了#8114号问题.
使用cgo,Go代码可以在C类型上运行,如下所示:
package foo
//#include <sys/stat.h>
import "C"
func fileSizeFromStat(stat *C.struct_stat) int64 {
return int64(stat.st_size)
}
反过来可能吗？即编写在go类型上运行的C函数？上述问题概述了具体内容; 我想编组无法从Go代码访问的C结构,因为它们使用了联合或位域,或者因为它们的对齐使它们与Go代码不兼容.
我正在做一个测试:比较cgo和纯Go函数的执行时间各自运行1亿次.与Golang函数相比,cgo函数需要更长的时间,我对此结果感到困惑.我的测试代码是:
package main
import (
"fmt"
"time"
)
/*
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
void show() {
}
*/
// #cgo LDFLAGS: -lstdc++
import "C"
//import "fmt"
func show() {
}
func main() {
now := time.Now()
for i := 0; i < 100000000; i = i + 1 {
C.show()
}
end_time := time.Now()
var dur_time time.Duration = end_time.Sub(now)
var elapsed_min float64 = dur_time.Minutes()
var elapsed_sec float64 = dur_time.Seconds()
var elapsed_nano int64 = dur_time.Nanoseconds()
fmt.Printf("cgo show function elasped …是否可以在Go句柄中生成垃圾收集器并释放通过C代码分配的内存？我道歉,我之前没有使用过C和cgo,所以我的例子可能需要一些澄清.
假设你有一些你想要使用的C库,这个库会分配一些需要手动释放的内存.我想做的是这样的事情:
package stuff
/*
#include <stuff.h>
*/
import "C"
type Stuff C.Stuff
func NewStuff() *Stuff {
stuff := Stuff(C.NewStuff()) // Allocate memory
// define the release function for the runtime to call
// when this object has no references to it (to release memory)
// In this case it's stuff.Free()
return stuff
}
func (s Stuff) Free() {
C.Free(C.Stuff(s)) // Release memory
}
当Go运行时没有对*Stuff的引用时,垃圾收集器是否有任何方法可以调用Stuff.Free()？
我在这里有道理吗？
也许更直接的问题是:是否有可能通过编写运行时在对该对象有零引用时调用的函数,使运行时自动处理C分配内存的清理？
我试图在Go程序中使用OpenGL.我想我已经完成了所有的工作,但我仍然无法让它运行起来.
我的C编译器是mingw的64位版本.它在我的%PATH%变量中,我已经验证它使用cgo文档中的随机数示例.
我通过将bin,lib和include文件夹应用到\mingw\x86_64-w64-mingw32mingw-w64安装中的等效文件来安装64位GLEW 1.9.0 .
当我尝试运行时go get github.com/go-gl/gl,请回复以下内容:
In file included from attriblocation.go:7:0:
gl.h:5:25: error: enumerator value for '__cgo_enum__5' is not an integer constant
#define GLEW_GET_FUN(x) (*x)
^
d:\programs\mingw64\x86_64-w64-mingw32\include\gl\glew.h:1956:26: note: in expansion of macro 'GLEW_GET_FUN'
#define glVertexAttrib3f GLEW_GET_FUN(__glewVertexAttrib3f)
^
gl.h:5:25: error: enumerator value for '__cgo_enum__6' is not an integer constant
#define GLEW_GET_FUN(x) (*x)
对于值达到的值,这些错误以类似的方式继续__cgo_enum__15.我也从每个条目的Go方面得到一些匹配错误.
关于我缺少什么的想法让这个工作？
编辑:以下是来自Go方面的"匹配"日志.
attriblocation.go:42:2: error: initializer element is not constant …