go-build

go 1.4版本的源代码中，src/cmd/gc 目录下存放的是 Go 语言的原生编译器（Go Compiler，简称 gc）的源代码。

gc 编译器基于 Plan 9 的 C 工具链开发，支持快速编译和优化，生成的代码效率较高。

Go 1.4 是最后一个大量使用 C 语言实现运行时的版本。从 Go 1.5 开始，Go 工具链通过自举（用 Go 编写 Go 编译器）逐步取代了 gc的 C 实现。

gccgo 的文档：https://go.dev/doc/install/gccgo

• The go subdirectory holds the frontend source code. This is mirrored to the gcc/go subdirectory in the GCC repository.
• Compared to gc, gccgo is slower to compile code but supports more powerful optimizations, so a CPU-bound program built by gccgo will usually run faster.
• The gc compiler supports only the most popular processors: x86 (32-bit and 64-bit) and ARM.
• Gccgo, however, supports all the processors that GCC supports.
• 如何使用上gccgo来编译go代码： go build -compiler gccgo myprog 或者 gccgo -o hello hello.go

build

1. 使用tag来实现编译不同的文件

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

// main.go
package main

import "fmt"

// HINT: You might need to move this declaration to a different file.
// const version = "dev"
func main() {
	fmt.Printf("running %s version", version)
}

///////////////////////////////////////////
// dev_config.go
// +build dev

package main

var version = "DEV"


//////////////////////////////////////////
// release_config.go
// +build release

package main

const version = "RELEASE"

上面代码的关键是// +build release这行，注意这行代码后须有一个空行隔开，而且必须在首行

接下来就可以根据-tags标签来选择不同的go文件 例如，选择dev_config.go这个文件：

1

$ go build -tags dev -o dev_version

例如，选择release_config.go这个文件：

1

$ go build -tags release -o dev_version

2. 使用-ldflags参数来传递编译参数

1
2
3
4
5
6
7
8
9

package main

import "fmt"

var version string

func main() {
	fmt.Printf("running %s version", version)
}

上面的version变量的值本来是一个空串，但是可以使用ldflags参数来给它赋值: 例如，给它赋值为dev:

1

go build -ldflags '-X main.version="dev"' -o dev_version

ldflags的其他用法(设置link参数，所有参数列表请查看 go tool link): -ldflags ‘-extldflags “-static” -s -w -X ‘main.Version=v1.1.3’

+build tools

会下载+build tools的依赖，而且go mod vendor后会存放在vendor目录下；但是在构建的时候，不会加入到二进制文件中

Build Constraints(约束)

https://ijayer.github.io/post/tech/code/golang/20180624-go_cmd_01_2_go-build-mode/

Build -tags A build constraint, also known as a build tag, is a line comment that begins

1

// +build

that lists the conditions under which a file should be included in the package. Constraints may appear in any kind of source file (not just Go), but they must appear near the top of the file, preceded(之前) only by blank lines and other line comments. These rules mean that in Go files a build constraint must appear before the package clause(条款).

To distinguish(区分) build constraints from package documentation, a series of build constraints must be followed by a blank line.

A build constraint is evaluated as the OR of space-separated options; each option evaluates as the AND of its comma-separated terms; and each term is an alphanumeric word or, preceded by !, its negation. That is, the build constraint:

1

// +build linux,386 darwin,!cgo

corresponds(对应于) to the boolean formula:

1

(linux AND 386) OR (darwin AND (NOT cgo))

A file may have multiple build constraints. The overall(总体) constraint is the AND of the individual(单独的) constraints. That is, the build constraints:

1
2

// +build linux darwin
// +build 386

During a particular build, the following words are satisfied:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

- the target operating system, as spelled by runtime.GOOS
- the target architecture, as spelled by runtime.GOARCH
- the compiler being used, either "gc" or "gccgo"
- "cgo", if ctxt.CgoEnabled is true
- "go1.1", from Go version 1.1 onward
- "go1.2", from Go version 1.2 onward
- "go1.3", from Go version 1.3 onward
- "go1.4", from Go version 1.4 onward
- "go1.5", from Go version 1.5 onward
- "go1.6", from Go version 1.6 onward
- "go1.7", from Go version 1.7 onward
- "go1.8", from Go version 1.8 onward
- "go1.9", from Go version 1.9 onward
- "go1.10", from Go version 1.10 onward(向前: 向前表示向着当前最新的版本)
- any additional words listed in ctxt.BuildTags

Note：A build tags follow these three rules

• a build tag is evaluated as the OR of space-separated options(空格分割，OR)
• each option evaluates as the AND of its comma-separated terms(逗号分隔，AND)
• each term is an alphanumeric word or, preceded by !, its negation(!, 否定)

File Suffixes

If a file’s name, after stripping(剥离) the extension(扩展名) and a possible_test suffix, matches any of the following patterns:

1
2
3

*_GOOS
*_GOARCH
*_GOOS_GOARCH

*_GOOS_GOARCH中 GOOS 和 GOARCH 的顺序不能变

(example: source_windows_amd64.go) where GOOS and GOARCH represent any known operating system and architecture values respectively(分别), then the file is considered to have an implicit(隐式的)) build constraint requiring those terms (in addition to any explicit(明确的) constraints in the file).

To keep a file from being considered for the build:

1

// +build ignore

(any other unsatisfied(不满意) word will work as well, but “ignore” is conventional(常规的). 临时让某个文件不参与编译)

To build a file only when using cgo, and only on Linux and OS X:

1

// +build linux,cgo darwin,cgo

Such a file is usually paired with another file implementing the default functionality for other systems, which in this case would carry the constraint:

1

// +build !linux,!darwin !cgo

Naming a file dns_windows.go will cause it to be included only when building the package for Windows; similarly, math_386.s will be included only when building the package for 32-bit x86.

Using GOOS=android matches build tags and files as for GOOS=linux in addition to android tags and files.(当使编译Android平台的时候，会把Linux相关的文件一起加入进行编译，优先编译了_linux.go文件，然后再到_android.go文件)

CGO_LDFLAGS="-static" 和 –ldflags ‘-extldflags “-static”‘的区别

1. cgo设置编译和连接参数：

通过import "C"前的注释语句设置：

1
2
3
4

// #cgo CFLAGS: -DPNG_DEBUG=1 -I./include
// #cgo LDFLAGS: -L/usr/local/lib -lpng
// #include <png.h>
import "C"

• 编译阶段的参数： 定义相关宏和指定头文件检索路径
• 连接阶段的参数： 指定库文件检索路径和要连接的库文件
• -D: 定义宏，PNG_DEBUG=1
• -l: 定义头文件包含的检索目录
• -L: 指定连接库文件的检索目录
• -l: 连接时需要连接的png库

2. 静态库和动态库

CGO在使用c/c++资源的时候有三种形式： 源码，静态链接库，动态链接库

源码： 直接在golang源码中写C代码或者包含C语言文件

静态库：

上一篇 « go-get 下一篇 » C程序设计语言-附录B标准库