关键是 lpOnRecvCardEvent 这个函数的第二个参数是个 C++ 指针。 楼主在 C# 中声明这个导出函数时，使用了并不对应的 CardEvent[] C# 数组类型。 正确的做法是： 在 C# 声明 lpOnRecvCardEvent 时，第二个参数应该是 IntPtr ，不是数组。 由于楼...
创新互联专注于下陆网站建设服务及定制，我们拥有丰富的企业做网站经验。 热诚为您提供下陆营销型网站建设，下陆网站制作、下陆网页设计、下陆网站官网定制、小程序设计服务，打造下陆网络公司原创品牌,更为您提供下陆网站排名全网营销落地服务。
直接嵌入c源代码到go代码里面
package main
/*
#include stdio.h
void myhello(int i) {
printf("Hello C: %d\n", i);
}
*/
import "C"
import "fmt"
func main() {
C.myhello(C.int(12))
fmt.Println("Hello Go");
}
需要注意的是C代码必须放在注释里面
import "C"语句和前面的C代码之间不能有空行
运行结果
$ go build main.go ./main
Hello C: 12
Hello Go
分开c代码到单独文件
嵌在一起代码结构不是很好看，很多人包括我，还是喜欢把两个分开，放在不同的文件里面，显得干净，go源文件里面是go的源代码，c源文件里面是c的源代码。
$ ls
hello.c hello.h main.go
$ cat hello.h
void hello(int);
$ cat hello.c
#include stdio.h
void hello(int i) {
printf("Hello C: %d\n", i);
}
$ cat main.go
package main
// #include "hello.h"
import "C"
import "fmt"
func main() {
C.hello(C.int(12))
fmt.Println("Hello Go");
}
编译运行
$ go build ./main
Hello C: 12
Hello Go
编译成库文件
如果c文件比较多，最好还是能够编译成一个独立的库文件，然后go来调用库。
$ find mylib main
mylib
mylib/hello.h
mylib/hello.c
main
main/main.go
编译库文件
$ cd mylib
# gcc -fPIC -shared -o libhello.so hello.c
编译go程序
$ cd main
$ cat main.go
package main
// #cgo CFLAGS: -I../mylib
// #cgo LDFLAGS: -L../mylib -lhello
// #include "hello.h"
import "C"
import "fmt"
func main() {
C.hello(C.int(12))
fmt.Println("Hello Go");
}
$ go build main.go
运行
$ export LD_LIBRARY_PATH=../mylib
$ ./main
Hello C: 12
Hello Go
在我们的例子中，库文件是编译成动态库的，main程序链接的时候也是采用的动态库
$ ldd main
linux-vdso.so.1 = (0x00007fffc7968000)
libhello.so = ../mylib/libhello.so (0x00007f513684c000)
libpthread.so.0 = /lib64/libpthread.so.0 (0x00007f5136614000)
libc.so.6 = /lib64/libc.so.6 (0x00007f5136253000)
/lib64/ld-linux-x86-64.so.2 (0x000055d819227000)
理论上讲也是可以编译成整个一静态链接的可执行程序，由于我的机器上缺少静态链接的系统库，比如libc.a，所以只能编译成动态链接。
默认是动态链接了glibc，但你也可以通过编译选项改成静态链接或者使用纯go库。
GO语言包估计能直接调用我没试
编译DLL库绝调用或者直接直接用系统命令调用编译完执行程序
由于我们的 Dockerfile 使用多阶段构建，
由于 alpine 镜像非常小，只有 5 mb 左右，但是由于客户那边强制要使用红帽的基础镜像，所以在第二阶段修改成红帽的镜像，最终打成的镜像运行的时候会提示 No such file or directory 。
这个问题的原因在于第一阶段构建的环境和第二阶段的运行的环境不一致，很多时候以为都是 Linux 环境，怎么可能不一致呢，但是由于 Linux 的各个发行版都有自己定制化的部分，就譬如 alpine 分支，他的 C 语言动态链接库使用的是 musl，而像 centos 用的都是 glibc，他们都是 c 语言的标准库，用来调用操作系统的库。
上面说的是一方面原因，但是不是这个问题的最具体的原因。
go build 打包出来的二进制文件还写一个非常重要的信息 interpreter 。
我将二进制文件从容器内 copy 出来通过 file 查看
可以看到二进制的文件上有些一个解释器的地址，这个文件地址是写死在二进制文件上的，后面我启动一个 centos 容器。
果然报了同样的一个错误。
Linux 如何启动一个二进制文件可以参考一下参考文档，就是通过这个解释器出发将程序调入内存。
工程结构如上图所示，我们需要实现的目标是在go文件中调用c文件
foo.c如下：
foo.go如下
foo.h如下：
编译过程如下：
1、先将c文件编译为.o文件，然后生成动态链接库.dylib文件
(1) clang -c foo.c
（2 clang -shared foo.o -o libfoo.dylib
2、在上述的动态链接库生成之后，在foo.go中添加动态链接命令：#cgo LDFLAGS: -L./ -lfoo
需要注意的是
中间不能有空格