We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
今天继续关于Go开发经验的分享,这次的主题是关于Go的交叉编译和条件编译,伴随着我对自己打不过、惹不起的壕同事小张的碎碎念文字。
Go
交叉编译是用来在一个平台上生成另一个平台的可执行程序。比如我工作开发时用的Mac,系统内核是darwin,小张用的是外星人,系统内核是windows (小张明显比我有钱,我的Mac是公司是发的,人家的外星人是为打游戏自己买的)。
darwin
windows
那么假如我编写的代码依赖了系统底层平台或处理器架构特性的Go包时,比如说我上周在文章《Go服务迁到K8s后老抽风重启? 记一次完整的线上问题解决过程》里写的,为了把Go运行时的panic错误重定向到日志文件,我用了syscall.Dup2这个函数把标准错误原来的文件描述符替换成了自己指定的日志文件的描述符。syscall.Dup2是Go语言在类Unix系统,X86_64架构下才有的函数库,在Mac系统上、各种服务器环境上编译都没有问题,但是唯独在像小张这样不用办公电脑的土豪们用的Windows系统上编译不过去。
panic
syscall.Dup2
Unix
X86_64
Windows
所以在上篇文章说的那个为了追踪在Kubernetes上服务老重启的问题,用syscall.Dup2重定向标准输出的解决方案是有副作用的,我贴一下之前这个功能的代码。
Kubernetes
func RewriteStderrFile() error { if runtime.GOOS == "windows" { return nil } ...... file, err := os.OpenFile(stdErrFile, os.O_RDWR|os.O_CREATE|os.O_APPEND, 0666) if err != nil { fmt.Println(err) return err } if err = syscall.Dup2(int(file.Fd()), int(os.Stderr.Fd())); err != nil { fmt.Println(err) return err } ...... return nil }
天真的用了一个**runtime.GOOS == "windows"**的判断,我还想着能在代码里根据内核的不同执行不同的代码,但是Go的软件包是先编译成可执行文件再执行的,这个判断根本没啥用。所以在Windows系统下编译项目的时候,因为没有syscall.Dup2直接就失败了......。
我这不就是典型的动态语言的思维吗,之前还写文章跟别人讲《如何避免用动态语言的思维写Go代码》......这次打自己脸打的实在有点疼。
虽然项目这个更新已经上线了,但是土壕小张和运维我都惹不起,迫于无奈我就看了看Go官方的标准库到底是怎么兼容多平台的。
网管瞎吐槽:我真觉得像在Kubernetes收集服务的错误日志这事儿该运维想办法干......,从公司基础设施建设层面,统一化收集所有rpc服务的错误日志,这样所有服务的代码都不用改,比我自己在项目里加代码不强吗?你们觉得我说的对不对(是不是能少干活...)。
我发现在go的每个内置库里都有很多以不停系统名结尾的文件。下面是Go的os内置库源代码的部分截图:
在有些文件里还有类似下面这样的注释:
// +build aix darwin dragonfly freebsd js,wasm linux netbsd openbsd solaris package os ...
看了些资料后才知道,他们是用于Go软件包的条件编译的,条件编译的意思就是通过某种方式来指示编译器编译特定代码。
Go不支持宏,不可以像c语言那样使用#define来控制是否包含平台相关的特定代码。作为替代,Go使用构建标签(build tags)和代码文件的命名约定来支持Go软件包的条件编译。
#define
build tags
构建标签就是上面我说的源代码里的注释:
需要注意的是,构建标签必须在代码文件里位于package声明的上方,并且后跟一个空行。
package
当Go编译一个包时,它会分析包内的每个源码文件并查找构建标签。标签决定了这个源码文件是否被编译。
构建标签遵循以下三个原则:
!
// +build darwin freebsd netbsd openbsd
上面的例子,表示这个源码文件只会在支持kqueue的BSD系统中被编译。
kqueue
BSD
一个源码文件可以包含多个构建标签。构建规则是每个独立规则的逻辑与关系。如下例子表示该文件将在linux/386或darwin/386平台才会被编译 。
linux/386
darwin/386
// +build linux darwin // +build 386
用逻辑表达式表示就是:(linux OR darwin) AND 386。
第二种条件编译的方法是通过源码文件的文件名实现的。这种方案比构造标签方案更简单。
go/build包的文档有关于命名约定的描述。简单来说,如果文件名包含_$GOOS.go后缀,那么这个源码文件只会在对应的平台被编译。其他平台会忽略这个文件。另一种约定是_$GOARCH.go。这两种后缀可以组合起来,但要保证顺序,正确的格式是_$GOOS_$GOARCH.go,错误的格式是_$GOARCH_$GOOS.go。
go/build
_$GOOS.go
_$GOARCH.go
_$GOOS_$GOARCH.go
_$GOARCH_$GOOS.go
以下是文件名后缀的一些例子:
mypkg_freebsd_arm.go // 只在 freebsd/arm 系统编译 mypkg_plan9.go // 只在 plan9 编译 mypkg_darwin.go // 只在macos 系统编译
源码文件光有后缀是不行的,比如如下文件名:
_linux.go _freebsd_386.go
即使是在Linux或FreeBSD系统,这两个文件也会被忽略,原因是go/build包会忽略所有文件名以.和_开始的文件。
.
_
构建标签和文件名后缀在功能上是重叠的。比如,一个名为mypkg_linux.go的文件,再包含构建标签// +build linux会显得多余。
mypkg_linux.go
// +build linux
通常来说,当只有一个特定平台或体系需要指定时,我们选择文件名后缀的方式。比如:
mypkg_linux.go // 只在 linux 系统编译 mypkg_windows_amd64.go // 只在 windows amd 64位 平台编译
相反,如果你的文件需要指定给多个平台或体系架构使用,或者你需要排除某个特定平台时,我们选择构建标签的方式。比如:
// 在所有类unix平台编译 // +build darwin dragonfly freebsd linux netbsd openbsd // 在非Windows平台编译 // +build !windows
应用环境,我就说下是怎么解决文章开头说的问题让小张大佬平复心情的吧......。
首先我向下面这样,在包里建了两个源码文件,用来分别存放在Windows系统和非Windows系统下使用的RewriteStderrFile函数:
RewriteStderrFile
project | └───pkg1 │ │----rewrite_err_unix.go │ │----rewrite_err_windows.go
因为我们的项目在那几个大佬电脑的Windows系统上编译和运行的时候都是开发阶段,其他测试上线之类的环境都是Linux系统,所以我懒癌发作,直接写了个空函数,毕竟只要能编译运行小张就不会太难为我了。
Linux
本篇文章的实践练习详细源码点这里
//rewrite_err_windows.go package pkg1 func RewriteStdErrLog(topic string) error { return nil }
对于要在服务器上和Mac电脑上编译的源码,跟之前的差不多,只是增加了构建标签:
//+build darwin linux package pkg1 ...... func RewritePanicsToFile(topic string) error { ...... file, err := os.OpenFile(stdErrFile, os.O_RDWR|os.O_CREATE|os.O_APPEND, 0666) if err != nil { fmt.Println(err) return err } if err = syscall.Dup2(int(errFileHandler.Fd()), int(os.Stderr.Fd())); err != nil { return err } ...... return nil }
交叉编译的执行就非常简单了,在编译时给go build命令设置OS和ARCH参数即可:
OS
ARCH
比如在Mac 下编译 Windows 64位可执行程序,用:
CGO_ENABLED=0 GOOS=windows GOARCH=amd64 go build main.go
在Mac系统执行完上面的命令就会编译生成软件包在Windows系统上的可执行文件(.exe文件)
如果是Windows 下编译 Mac 64位可执行程序,用:
SET CGO_ENABLED=0 SET GOOS=darwin SET GOARCH=amd64 go build main.go
事实上,除了用于.go的Go源码文件,构建标签和文件名后缀这些条件编译规则可以作用于任何go tool可以编译的源码文件,包括.c和.s文件。Go标准库中,尤其是runtime,syscall,os,net包中包含了大量这种例子。咱们一定要去看看,多学习,尤其是身边有像小张这样又壕又凶的队友的同学们,一定把今天我说的这些都学会......。
.go
.c
.s
runtime
syscall
os
net
看到这里了,如果喜欢我的文章可以帮我点个赞,我会每周通过技术文章分享我的所学所见和第一手实践经验,感谢你的支持。微信搜索关注公众号「网管叨bi叨」第一时间获取我的文章推送。
The text was updated successfully, but these errors were encountered:
No branches or pull requests
今天继续关于
Go
开发经验的分享,这次的主题是关于Go
的交叉编译和条件编译,伴随着我对自己打不过、惹不起的壕同事小张的碎碎念文字。交叉编译
交叉编译是用来在一个平台上生成另一个平台的可执行程序。比如我工作开发时用的Mac,系统内核是
darwin
,小张用的是外星人,系统内核是windows
(小张明显比我有钱,我的Mac是公司是发的,人家的外星人是为打游戏自己买的)。那么假如我编写的代码依赖了系统底层平台或处理器架构特性的
Go
包时,比如说我上周在文章《Go服务迁到K8s后老抽风重启? 记一次完整的线上问题解决过程》里写的,为了把Go
运行时的panic
错误重定向到日志文件,我用了syscall.Dup2
这个函数把标准错误原来的文件描述符替换成了自己指定的日志文件的描述符。syscall.Dup2
是Go
语言在类Unix
系统,X86_64
架构下才有的函数库,在Mac系统上、各种服务器环境上编译都没有问题,但是唯独在像小张这样不用办公电脑的土豪们用的Windows
系统上编译不过去。所以在上篇文章说的那个为了追踪在
Kubernetes
上服务老重启的问题,用syscall.Dup2
重定向标准输出的解决方案是有副作用的,我贴一下之前这个功能的代码。天真的用了一个**runtime.GOOS == "windows"**的判断,我还想着能在代码里根据内核的不同执行不同的代码,但是
Go
的软件包是先编译成可执行文件再执行的,这个判断根本没啥用。所以在Windows
系统下编译项目的时候,因为没有syscall.Dup2
直接就失败了......。我这不就是典型的动态语言的思维吗,之前还写文章跟别人讲《如何避免用动态语言的思维写Go代码》......这次打自己脸打的实在有点疼。
虽然项目这个更新已经上线了,但是土壕小张和运维我都惹不起,迫于无奈我就看了看
Go
官方的标准库到底是怎么兼容多平台的。条件编译
我发现在go的每个内置库里都有很多以不停系统名结尾的文件。下面是
Go
的os内置库源代码的部分截图:在有些文件里还有类似下面这样的注释:
看了些资料后才知道,他们是用于
Go
软件包的条件编译的,条件编译的意思就是通过某种方式来指示编译器编译特定代码。Go
不支持宏,不可以像c语言那样使用#define
来控制是否包含平台相关的特定代码。作为替代,Go
使用构建标签(build tags
)和代码文件的命名约定来支持Go
软件包的条件编译。构建标签
构建标签就是上面我说的源代码里的注释:
需要注意的是,构建标签必须在代码文件里位于
package
声明的上方,并且后跟一个空行。当
Go
编译一个包时,它会分析包内的每个源码文件并查找构建标签。标签决定了这个源码文件是否被编译。构建标签遵循以下三个原则:
!
,则表示反义上面的例子,表示这个源码文件只会在支持
kqueue
的BSD
系统中被编译。一个源码文件可以包含多个构建标签。构建规则是每个独立规则的逻辑与关系。如下例子表示该文件将在
linux/386
或darwin/386
平台才会被编译 。用逻辑表达式表示就是:(linux OR darwin) AND 386。
文件名后缀
第二种条件编译的方法是通过源码文件的文件名实现的。这种方案比构造标签方案更简单。
go/build
包的文档有关于命名约定的描述。简单来说,如果文件名包含_$GOOS.go
后缀,那么这个源码文件只会在对应的平台被编译。其他平台会忽略这个文件。另一种约定是_$GOARCH.go
。这两种后缀可以组合起来,但要保证顺序,正确的格式是_$GOOS_$GOARCH.go
,错误的格式是_$GOARCH_$GOOS.go
。以下是文件名后缀的一些例子:
源码文件光有后缀是不行的,比如如下文件名:
即使是在Linux或FreeBSD系统,这两个文件也会被忽略,原因是
go/build
包会忽略所有文件名以.
和_
开始的文件。使用构建标签还是文件名后缀
构建标签和文件名后缀在功能上是重叠的。比如,一个名为
mypkg_linux.go
的文件,再包含构建标签// +build linux
会显得多余。通常来说,当只有一个特定平台或体系需要指定时,我们选择文件名后缀的方式。比如:
相反,如果你的文件需要指定给多个平台或体系架构使用,或者你需要排除某个特定平台时,我们选择构建标签的方式。比如:
实践应用
应用环境,我就说下是怎么解决文章开头说的问题让小张大佬平复心情的吧......。
设置条件编译
首先我向下面这样,在包里建了两个源码文件,用来分别存放在
Windows
系统和非Windows
系统下使用的RewriteStderrFile
函数:因为我们的项目在那几个大佬电脑的
Windows
系统上编译和运行的时候都是开发阶段,其他测试上线之类的环境都是Linux
系统,所以我懒癌发作,直接写了个空函数,毕竟只要能编译运行小张就不会太难为我了。本篇文章的实践练习详细源码点这里
对于要在服务器上和Mac电脑上编译的源码,跟之前的差不多,只是增加了构建标签:
执行交叉编译
交叉编译的执行就非常简单了,在编译时给go build命令设置
OS
和ARCH
参数即可:比如在Mac 下编译
Windows
64位可执行程序,用:在Mac系统执行完上面的命令就会编译生成软件包在Windows系统上的可执行文件(.exe文件)
如果是
Windows
下编译 Mac 64位可执行程序,用:总结
事实上,除了用于
.go
的Go源码文件,构建标签和文件名后缀这些条件编译规则可以作用于任何go tool可以编译的源码文件,包括.c
和.s
文件。Go
标准库中,尤其是runtime
,syscall
,os
,net
包中包含了大量这种例子。咱们一定要去看看,多学习,尤其是身边有像小张这样又壕又凶的队友的同学们,一定把今天我说的这些都学会......。前情回顾
The text was updated successfully, but these errors were encountered: