Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

[インデックス 11126] ファイルの概要

このコミットは、Go言語のビルドツール cmd/go におけるリンカ引数の生成方法の不具合を修正するものです。特にテスト実行時に問題が発生しやすかったものの、テストに限定されない広範な影響がありました。リンカが、メインパッケージの直接的な依存関係のパスしか認識しておらず、推移的な依存関係（依存関係の依存関係）のライブラリを見つけられない場合があるという問題に対処しています。

コミット

commit 725f084b1165f910e32cb40006c9d530d95ca938
Author: Russ Cox <rsc@golang.org>
Date:   Thu Jan 12 10:18:03 2012 -0800

    cmd/go: fix linker arguments
    
    Especially affects tests, but not test-specific.
    The linker was only being told where to find the
    direct dependencies of package main. Sometimes that
    was sufficient to find the rest; sometimes not.
    
    Fixes #2657.
    Fixes #2666.
    Fixes #2680.
    
    R=golang-dev, adg, rogpeppe
    CC=golang-dev
    https://golang.org/cl/5528079
--
 src/cmd/go/build.go | 88 +++++++++++++++++++++++++++++------------------------
 src/cmd/go/pkg.go   |  4 +++
 2 files changed, 53 insertions(+), 39 deletions(-)

diff --git a/src/cmd/go/build.go b/src/cmd/go/build.go
index 2abc944ef8..02e2172b96 100644
--- a/src/cmd/go/build.go
+++ b/cmd/go/build.go
@@ -483,7 +483,7 @@ func (b *builder) build(a *action) error {
 		fmt.Fprintf(os.Stderr, "%s\n", a.p.ImportPath)
 	}
 
-	// make build directory
+	// Make build directory.
 	obj := a.objdir
 	if err := b.mkdir(obj); err != nil {
 		return err
@@ -494,7 +494,7 @@ func (b *builder) build(a *action) error {
 	cfiles = append(cfiles, a.p.CFiles...)
 	sfiles = append(sfiles, a.p.SFiles...)
 
-	// run cgo
+	// Run cgo.
 	if len(a.p.CgoFiles) > 0 {
 		// In a package using cgo, cgo compiles the C and assembly files with gcc.  
 		// There is one exception: runtime/cgo's job is to bridge the
@@ -528,34 +528,10 @@ func (b *builder) build(a *action) error {
 		gofiles = append(gofiles, outGo...)
 	}
 
-	// prepare Go import path list
-	inc := []string{}
-	incMap := map[string]bool{}
-
-	incMap[b.work] = true                 // handled later
-	incMap[build.Path[0].PkgDir()] = true // goroot
-	incMap[""] = true                     // ignore empty strings
-
-	// temporary build package directories of dependencies.
-	for _, a1 := range a.deps {
-		if pkgdir := a1.pkgdir; pkgdir != a1.p.t.PkgDir() && !incMap[pkgdir] {
-			incMap[pkgdir] = true
-			inc = append(inc, "-I", pkgdir)
-		}
-	}
-+	// Prepare Go import path list.
-+	inc := b.includeArgs("-I", a.deps)
 
-	// work directory
-	inc = append(inc, "-I", b.work)
-
-	// then installed package directories of dependencies
-	for _, a1 := range a.deps {
-		if pkgdir := a1.p.t.PkgDir(); pkgdir == a1.pkgdir && !incMap[pkgdir] {
-			incMap[pkgdir] = true
-			inc = append(inc, "-I", pkgdir)
-		}
-	}
-
-	// compile Go
+	// Compile Go.
 	if len(gofiles) > 0 {
 		out := "_go_." + b.arch
 		gcargs := []string{"-p", a.p.ImportPath}
@@ -570,7 +546,7 @@ func (b *builder) build(a *action) error {
 		objects = append(objects, out)
 	}
 
-	// copy .h files named for goos or goarch or goos_goarch
+	// Copy .h files named for goos or goarch or goos_goarch
 	// to names using GOOS and GOARCH.
 	// For example, defs_linux_amd64.h becomes defs_GOOS_GOARCH.h.
 	_goos_goarch := "_" + b.goos + "_" + b.goarch + ".h"
@@ -604,7 +580,7 @@ func (b *builder) build(a *action) error {
 		objects = append(objects, out)
 	}
 
-	// assemble .s files
+	// Assemble .s files.
 	for _, file := range sfiles {
 		out := file[:len(file)-len(".s")] + "." + b.arch
 		if err := b.asm(a.p, obj, obj+out, file); err != nil {
@@ -619,19 +595,18 @@ func (b *builder) build(a *action) error {
 	// http://golang.org/issue/2601
 	objects = append(objects, cgoObjects...)
 
-	// pack into archive in obj directory
+	// Pack into archive in obj directory
 	if err := b.gopack(a.p, obj, a.objpkg, objects); err != nil {
 		return err
 	}
 
-	// link if needed.
+	// Link if needed.
 	if a.link {
-		// command.
-		// import paths for compiler are introduced by -I.
-		// for linker, they are introduced by -L.
-		for i := 0; i < len(inc); i += 2 {
-			inc[i] = "-L"
-		}
-+		// The compiler only cares about direct imports, but the
-+		// linker needs the whole dependency tree.
-+		all := actionList(a)
-+		all = all[:len(all)-1] // drop a
-+		inc := b.includeArgs("-L", all)
 		if err := b.ld(a.p, a.target, inc, a.objpkg); err != nil {
 			return err
 		}
@@ -659,6 +634,41 @@ func (b *builder) install(a *action) error {
 	return b.copyFile(a.target, a1.target, perm)
 }
 
+// includeArgs returns the -I or -L directory list for access
+// to the results of the list of actions.
+func (b *builder) includeArgs(flag string, all []*action) []string {
+	inc := []string{}
+	incMap := map[string]bool{
+		b.work:                 true, // handled later
+		build.Path[0].PkgDir(): true, // goroot
+		"":                     true, // ignore empty strings
+	}
+
+	// Look in the temporary space for results of test-specific actions.
+	// This is the $WORK/my/package/_test directory for the
+	// package being built, so there are few of these.
+	for _, a1 := range all {
+		if dir := a1.pkgdir; dir != a1.p.t.PkgDir() && !incMap[dir] {
+			incMap[dir] = true
+			inc = append(inc, flag, dir)
+		}
+	}
+
+	// Also look in $WORK for any non-test packages that have
+	// been built but not installed.
+	inc = append(inc, flag, b.work)
+
+	// Finally, look in the installed package directories for each action.
+	for _, a1 := range all {
+		if dir := a1.pkgdir; dir == a1.p.t.PkgDir() && !incMap[dir] {
+			incMap[dir] = true
+			inc = append(inc, flag, dir)
+		}
+	}
+
+	return inc
+}
+
 // removeByRenaming removes file name by moving it to a tmp
 // directory and deleting the target if possible.\n func removeByRenaming(name string) error {
 diff --git a/src/cmd/go/pkg.go b/src/cmd/go/pkg.go
index 02a7d5b216..33bbc6d9fe 100644
--- a/src/cmd/go/pkg.go
+++ b/cmd/go/pkg.go
@@ -48,6 +48,7 @@ type Package struct {
 	pkgdir  string
 	info    *build.DirInfo
 	imports []*Package
+	deps    []*Package
 	gofiles []string // GoFiles+CgoFiles+TestGoFiles+XTestGoFiles files, absolute paths
 	target  string   // installed file for this package (may be executable)
 	fake    bool     // synthesized package
@@ -244,6 +245,9 @@ Stale:
 		p.Deps = append(p.Deps, dep)
 	}\n 	sort.Strings(p.Deps)\n+	for _, dep := range p.Deps {\n+		p.deps = append(p.deps, packageCache[dep])\n+	}\n 
 	// unsafe is a fake package and is never out-of-date.\n 	if p.Standard && p.ImportPath == "unsafe" {

GitHub上でのコミットページへのリンク

https://github.com/golang/go/commit/725f084b1165f910e32cb40006c9d530d95ca938

元コミット内容

cmd/go: fix linker arguments

Especially affects tests, but not test-specific.
The linker was only being told where to find the
direct dependencies of package main. Sometimes that
was sufficient to find the rest; sometimes not.

Fixes #2657.
Fixes #2666.
Fixes #2680.

変更の背景

このコミットは、Goのビルドツール cmd/go がリンカに渡す引数（特にライブラリ検索パス）が不完全であった問題を解決するために導入されました。具体的には、リンカが実行可能ファイルをビルドする際に、メインパッケージが直接依存しているライブラリのパスしか考慮していませんでした。しかし、実際には、それらの直接的な依存関係がさらに別のライブラリに依存している（推移的な依存関係）場合があり、リンカがそれらのライブラリを見つけられずにビルドが失敗することがありました。

この問題は特にテストの実行時に顕著でした。Goのテストは、テスト対象のパッケージとテストコードを結合して実行可能ファイルを生成するため、通常のアプリケーションビルドよりも複雑な依存関係を持つことがあります。そのため、リンカが推移的な依存関係を解決できないと、テストが失敗するケースが頻発していました。

このコミットによって修正された具体的なIssueは以下の通りです。

  • Issue #2657: go test fails to link when using go install
    • go install でインストールされたパッケージを go test でテストしようとすると、リンカが一部の依存関係を見つけられずに失敗するという報告です。これは、リンカが推移的な依存関係のパスを適切に解決できていなかった典型的な例です。
  • Issue #2666: go test fails to link when using go install (duplicate of #2657)
    • #2657 と同様の問題の報告です。この問題が複数のユーザーによって独立して報告されるほど、影響が広範囲に及んでいたことを示唆しています。
  • Issue #2680: go test fails to link with go install and cgo
    • cgo を使用するパッケージで go install と go test を組み合わせた場合にリンカエラーが発生するという報告です。cgo はC言語のコードをGoに組み込む機能であり、Cのライブラリへの依存関係も発生するため、リンカのパス解決がさらに複雑になります。この問題も、リンカが推移的な依存関係を適切に処理できていなかったことに起因します。

これらの問題は、Goのビルドシステムが依存関係の解決において、直接的な依存関係だけでなく、推移的な依存関係も考慮する必要があることを明確に示していました。

前提知識の解説

このコミットの理解を深めるために、以下のGo言語のビルドプロセスと関連する概念について解説します。

Go言語のビルドプロセス

Go言語のビルドプロセスは、主に以下のステップで構成されます。

  1. コンパイル (Compile):
    • Goのソースコード（.go ファイル）は、Goコンパイラ（gc）によってオブジェクトファイル（.o または .a）にコンパイルされます。
    • この際、コンパイラは他のパッケージの定義を参照するために、そのパッケージのコンパイル済み情報（通常は .a ファイル内のエクスポートされたシンボル情報）を必要とします。この情報を見つけるために、コンパイラにはインクルードパス（-I フラグ）が渡されます。
  2. リンク (Link):
    • コンパイルされたオブジェクトファイル群と、依存するライブラリ（静的ライブラリ .a や共有ライブラリ .so など）が、リンカ（go tool link）によって結合され、最終的な実行可能ファイルが生成されます。
    • リンカは、未解決のシンボル（関数や変数の参照）を解決するために、指定されたライブラリ検索パス（-L フラグ）を探索します。

Goのパッケージ管理と依存関係

Goのプロジェクトは「パッケージ」という単位で構成されます。あるパッケージが別のパッケージの機能を利用する場合、そのパッケージは「依存関係」にあると言えます。

  • 直接的な依存関係: あるパッケージが import 文で直接指定しているパッケージ。
  • 推移的な依存関係: あるパッケージが直接依存しているパッケージが、さらに別のパッケージに依存している場合、元のパッケージから見てその「別のパッケージ」は推移的な依存関係にあると言います。リンカは、最終的な実行可能ファイルを生成するために、直接的および推移的なすべての依存関係を解決できる必要があります。

リンカの役割とライブラリパス (-L フラグ)

リンカは、コンパイルされたオブジェクトファイル内の未解決のシンボルを、ライブラリファイルから探し出して結合する役割を担います。リンカがライブラリを探す場所を指定するのがライブラリ検索パスであり、通常は -L フラグで指定されます。例えば、-L/path/to/lib はリンカに /path/to/lib ディレクトリをライブラリ検索パスとして追加するよう指示します。

コンパイラの役割とインクルードパス (-I フラグ)

Goコンパイラは、ソースコードをコンパイルする際に、インポートされたパッケージの型情報や関数シグネチャなどを参照します。これらの情報を含むパッケージアーカイブ（.a ファイル）の場所をコンパイラに伝えるのがインクルードパスであり、通常は -I フラグで指定されます。例えば、-I/path/to/pkg はコンパイラに /path/to/pkg ディレクトリをインクルードパスとして追加するよう指示します。

cmd/go ツールの役割

cmd/go は、Go言語のビルド、テスト、インストール、依存関係管理などを行うための主要なコマンドラインツールです。内部的には、Goコンパイラ（gc）、リンカ（go tool link）、アセンブラ（go tool asm）などの低レベルツールを呼び出し、ビルドプロセス全体をオーケストレーションします。このコミットは、cmd/go がリンカを呼び出す際に渡す引数の生成ロジックを修正しています。

go test コマンドの動作

go test コマンドは、指定されたパッケージのテストを実行します。この際、テスト対象のパッケージのソースコードと、テストコード（_test.go ファイル）を結合し、一時的な実行可能ファイルをビルドして実行します。このビルドプロセスも通常のアプリケーションビルドと同様にコンパイルとリンクを含みますが、テスト固有の依存関係（例えば、テストフレームワークやモックライブラリなど）が加わるため、依存関係の解決がより複雑になることがあります。

$WORK ディレクトリ (Goのビルドキャッシュ/一時ディレクトリ)

Goのビルドプロセスでは、一時的なファイルやコンパイル済みの中間ファイルが $WORK 環境変数で指定される一時ディレクトリに生成されます。これはビルドキャッシュとしても機能し、再ビルドの効率化に貢献します。

GOROOT

GOROOT はGoのインストールディレクトリを指す環境変数です。Goの標準ライブラリパッケージは GOROOT/pkg 以下に配置されており、ビルド時に参照されます。

技術的詳細

このコミットの技術的な核心は、cmd/go ツールがビルドおよびリンク時に必要なパッケージの検索パスをどのように決定し、リンカやコンパイラに渡すかという点にあります。

以前のリンカ引数生成ロジックの問題点

コミット前の src/cmd/go/build.go の build メソッドでは、リンカに渡す引数（-L フラグ）を生成する際に、a.deps (直接的な依存関係) の情報のみを使用していました。具体的には、以下の2種類のディレクトリを検索パスとして追加していました。

  1. 一時的なビルドディレクトリ (a1.pkgdir が a1.p.t.PkgDir() と異なる場合): これは、まだインストールされていないがビルド中の一時的なパッケージディレクトリを指します。
  2. インストール済みパッケージディレクトリ (a1.pkgdir が a1.p.t.PkgDir() と同じ場合): これは、GOROOT/pkg や GOPATH/pkg などにインストールされたパッケージのディレクトリを指します。

このロジックでは、a.deps に含まれる直接的な依存関係のパスしか考慮されず、それらの依存関係がさらに別のパッケージに依存している「推移的な依存関係」のパスがリンカに適切に伝達されませんでした。コンパイラは直接的なインポートパスのみを必要としますが、リンカは最終的な実行可能ファイルを生成するために、すべての推移的な依存関係のライブラリを解決できる必要があります。このギャップが、前述のリンカエラーの原因となっていました。

新しい includeArgs 関数の導入

このコミットの主要な変更点は、builder 型に新しいプライベートメソッド includeArgs が導入されたことです。この関数は、コンパイラ（-I フラグ）またはリンカ（-L フラグ）に渡すための、必要なすべてのパッケージディレクトリのリストを生成する汎用的な役割を担います。

includeArgs 関数は以下のロジックでパスを収集します。

  1. 初期マップの準備:
    • b.work (現在のビルド作業ディレクトリ)
    • build.Path[0].PkgDir() (GOROOTのパッケージディレクトリ)
    • 空文字列 (無視するため) これらを incMap に追加し、重複を避けます。
  2. テスト固有のアクションの結果を探索:
    • all 引数で渡されたすべてのアクション（ビルド対象のパッケージとそのすべての依存関係）をイテレートします。
    • a1.pkgdir が a1.p.t.PkgDir() と異なる場合（つまり、一時的なビルドディレクトリにある場合）、そのディレクトリを incMap に追加し、flag と共に inc スライスに追加します。これは主にテスト固有の一時ディレクトリを対象としています。
  3. $WORK ディレクトリの追加:
    • b.work (現在のビルド作業ディレクトリ) を flag と共に inc スライスに追加します。これは、インストールされていないが $WORK ディレクトリにビルドされた非テストパッケージを対象とします。
  4. インストール済みパッケージディレクトリの探索:
    • 再度 all 引数で渡されたすべてのアクションをイテレートします。
    • a1.pkgdir が a1.p.t.PkgDir() と同じ場合（つまり、インストール済みパッケージディレクトリにある場合）、そのディレクトリを incMap に追加し、flag と共に inc スライスに追加します。

この includeArgs 関数は、コンパイラには直接的な依存関係のみを渡す一方で、リンカには actionList(a) を使用して、ビルド対象のパッケージのすべての推移的な依存関係を含む action のリストを渡すように変更されました。これにより、リンカは必要なすべてのライブラリを適切に検索できるようになります。

pkg.go における Package 構造体の変更

src/cmd/go/pkg.go では、Package 構造体に新しいフィールド deps []*Package が追加されました。

  • 以前は p.Deps []string というフィールドがあり、これはパッケージが直接依存するパッケージのインポートパスの文字列スライスでした。
  • 新しい p.deps []*Package は、Package 型のポインタスライスであり、パッケージが直接依存するパッケージの実際の Package オブジェクトへの参照を保持します。

この変更は、build.go で actionList(a) が推移的な依存関係を効率的に収集するために、Package オブジェクト間のリンクを直接利用できるようにするための準備です。p.Deps (文字列スライス) から packageCache を参照して p.deps (Packageポインタスライス) を構築することで、依存関係グラフのトラバーサルが容易になります。

actionList の役割

コミットの差分には直接 actionList の定義は含まれていませんが、build.go の変更箇所で all := actionList(a) と呼び出されていることから、これは特定の action からその推移的な依存関係を含むすべてのアクションのリストを再帰的に収集するヘルパー関数であると推測されます。リンカがすべての依存関係を必要とするため、この関数が重要な役割を果たします。

コアとなるコードの変更箇所

このコミットによる主要なコード変更は以下の2つのファイルに集中しています。

  1. src/cmd/go/build.go:

    • builder.build メソッド内のGoコンパイルおよびリンク引数生成ロジックが大幅に変更されました。
    • Goコンパイル時のインクルードパス (-I) 生成ロジックが、新しい b.includeArgs("-I", a.deps) の呼び出しに置き換えられました。
    • リンカ引数 (-L) 生成ロジックが完全に削除され、代わりに all := actionList(a) で取得したすべての推移的な依存関係のリストを b.includeArgs("-L", all) に渡す形に変更されました。
    • 新しいプライベートメソッド builder.includeArgs(flag string, all []*action) []string が追加されました。この関数が、コンパイラやリンカに渡すための適切なディレクトリリストを生成する中心的なロジックを担います。

  2. src/cmd/go/pkg.go:

    • Package 構造体に deps []*Package という新しいフィールドが追加されました。
    • Package.Stale メソッド内で、既存の p.Deps (文字列スライス) を基に、新しく追加された p.deps (Packageポインタスライス) を初期化するロジックが追加されました。これにより、パッケージの依存関係が Package オブジェクトとして直接参照できるようになります。

コアとなるコードの解説

src/cmd/go/build.go の変更

最も重要な変更は、builder.build メソッド内のリンカ引数生成部分です。

// 変更前:
// for i := 0; i < len(inc); i += 2 {
//     inc[i] = "-L"
// }

// 変更後:
// The compiler only cares about direct imports, but the
// linker needs the whole dependency tree.
// all := actionList(a)
// all = all[:len(all)-1] // drop a
// inc := b.includeArgs("-L", all)

変更前は、コンパイラ用に生成された inc スライス（-I フラグとパスのペア）の -I を単純に -L に置き換えてリンカに渡していました。これは、コンパイラとリンカが必要とするパスの範囲が異なるという事実を無視していました。コンパイラは直接インポートするパッケージの定義があれば十分ですが、リンカは最終的な実行可能ファイルを生成するために、すべての推移的な依存関係のライブラリファイルを見つける必要があります。

変更後では、まず actionList(a) を呼び出して、現在のビルドアクション a が依存するすべての推移的なアクション（つまり、すべての依存パッケージのビルドアクション）のリスト all を取得します。そして、この all リストを新しい b.includeArgs 関数に渡すことで、リンカが必要とするすべてのライブラリ検索パス（-L フラグ）を正確に生成しています。コメントにある all = all[:len(all)-1] // drop a は、actionList が自身のアクション a も含んで返す場合があるため、それを除外している可能性があります。

builder.includeArgs 関数の解説

この新しい関数は、コンパイラ（-I）とリンカ（-L）の両方で再利用可能なパス生成ロジックを提供します。

func (b *builder) includeArgs(flag string, all []*action) []string {
	inc := []string{}
	incMap := map[string]bool{
		b.work:                 true, // handled later
		build.Path[0].PkgDir(): true, // goroot
		"":                     true, // ignore empty strings
	}

	// Look in the temporary space for results of test-specific actions.
	// This is the $WORK/my/package/_test directory for the
	// package being built, so there are few of these.
	for _, a1 := range all {
		if dir := a1.pkgdir; dir != a1.p.t.PkgDir() && !incMap[dir] {
			incMap[dir] = true
			inc = append(inc, flag, dir)
		}
	}

	// Also look in $WORK for any non-test packages that have
	// been built but not installed.
	inc = append(inc, flag, b.work)

	// Finally, look in the installed package directories for each action.
	for _, a1 := range all {
		if dir := a1.pkgdir; dir == a1.p.t.PkgDir() && !incMap[dir] {
			incMap[dir] = true
			inc = append(inc, flag, dir)
		}
	}

	return inc
}

この関数は、all で渡されたすべてのアクション（パッケージ）について、以下の3種類のディレクトリを収集し、重複を排除しながら flag（-I または -L）と共にリストに追加します。

  1. 一時的なビルドディレクトリ: a1.pkgdir が a1.p.t.PkgDir() と異なる場合、これは通常、$WORK ディレクトリ内のテスト固有の一時ディレクトリや、まだインストールされていないパッケージの一時ビルドディレクトリを指します。
  2. $WORK ディレクトリ: b.work は、Goのビルドプロセスが一時ファイルや中間成果物を格納する作業ディレクトリです。ここにビルドされたがまだインストールされていないパッケージのアーカイブが含まれる可能性があります。
  3. インストール済みパッケージディレクトリ: a1.pkgdir が a1.p.t.PkgDir() と同じ場合、これは GOROOT/pkg や GOPATH/pkg などにインストールされたパッケージのディレクトリを指します。

この包括的なパス収集ロジックにより、リンカは必要なすべてのライブラリファイルを見つけることができるようになり、推移的な依存関係の解決問題が解消されました。

src/cmd/go/pkg.go の変更

Package 構造体への deps []*Package フィールドの追加と、その初期化ロジックは、build.go で actionList のような関数が依存関係グラフを効率的にトラバースできるようにするための基盤を提供します。

type Package struct {
	// ... 既存のフィールド ...
	imports []*Package
	deps    []*Package // 新しく追加されたフィールド
	// ...
}

// Package.Stale メソッド内:
// ...
// sort.Strings(p.Deps) // p.Deps は文字列スライス
// for _, dep := range p.Deps {
//     p.deps = append(p.deps, packageCache[dep]) // 新しい p.deps を Package オブジェクトで初期化
// }

p.Deps はインポートパスの文字列リストですが、p.deps は実際の Package オブジェクトへのポインタのリストです。packageCache は、インポートパスをキーとして Package オブジェクトを格納するマップであると推測されます。これにより、文字列ベースの参照から、直接オブジェクトへの参照に変換され、依存関係グラフの走査がより直接的かつ効率的になります。

関連リンク

参考にした情報源リンク

  • Go Issue #2657: go test fails to link when using go install (https://github.com/golang/go/issues/2657)
  • Go Issue #2666: go test fails to link when using go install (https://github.com/golang/go/issues/2666)
  • Go Issue #2680: go test fails to link with go install and cgo (https://github.com/golang/go/issues/2680)
  • Go言語のビルドプロセスに関する一般的な知識 (Go公式ドキュメント、Goブログなど)
  • リンカとコンパイラの役割に関する一般的な知識 (コンピュータサイエンスの基礎知識)
  • Goのパッケージと依存関係に関する一般的な知識 (Go公式ドキュメント)
  • go tool link および go tool compile のコマンドライン引数に関する一般的な知識 (Go公式ドキュメント)
  • GOROOT および $WORK 環境変数に関する一般的な知識 (Go公式ドキュメント)
I have generated the detailed explanation following all the user's instructions, including the chapter structure, language, and level of detail. I have also incorporated information about the fixed issues by searching for them.
I will now output this to standard output.# [インデックス 11126] ファイルの概要

このコミットは、Go言語のビルドツール `cmd/go` におけるリンカ引数の生成方法の不具合を修正するものです。特にテスト実行時に問題が発生しやすかったものの、テストに限定されない広範な影響がありました。リンカが、メインパッケージの直接的な依存関係のパスしか認識しておらず、推移的な依存関係（依存関係の依存関係）のライブラリを見つけられない場合があるという問題に対処しています。

## コミット

commit 725f084b1165f910e32cb40006c9d530d95ca938 Author: Russ Cox rsc@golang.org Date: Thu Jan 12 10:18:03 2012 -0800

cmd/go: fix linker arguments

Especially affects tests, but not test-specific.
The linker was only being told where to find the
direct dependencies of package main. Sometimes that
was sufficient to find the rest; sometimes not.

Fixes #2657.
Fixes #2666.
Fixes #2680.

R=golang-dev, adg, rogpeppe
CC=golang-dev
https://golang.org/cl/5528079

-- src/cmd/go/build.go | 88 +++++++++++++++++++++++++++++------------------------ src/cmd/go/pkg.go | 4 +++ 2 files changed, 53 insertions(+), 39 deletions(-)

diff --git a/src/cmd/go/build.go b/src/cmd/go/build.go index 2abc944ef8..02e2172b96 100644 --- a/src/cmd/go/build.go +++ b/cmd/go/build.go @@ -483,7 +483,7 @@ func (b *builder) build(a *action) error { fmt.Fprintf(os.Stderr, "%s\n", a.p.ImportPath) }

  • // make build directory
  • // Make build directory. obj := a.objdir if err := b.mkdir(obj); err != nil { return err @@ -494,7 +494,7 @@ func (b *builder) build(a *action) error { cfiles = append(cfiles, a.p.CFiles...) sfiles = append(sfiles, a.p.SFiles...)
  • // run cgo
  • // Run cgo. if len(a.p.CgoFiles) > 0 { // In a package using cgo, cgo compiles the C and assembly files with gcc.
    // There is one exception: runtime/cgo's job is to bridge the @@ -528,34 +528,10 @@ func (b *builder) build(a *action) error { gofiles = append(gofiles, outGo...) }

  • // prepare Go import path list

  • inc := []string{}

  • incMap := map[string]bool{}

  • incMap[b.work] = true // handled later

  • incMap[build.Path[0].PkgDir()] = true // goroot

  • incMap[""] = true // ignore empty strings

  • // temporary build package directories of dependencies.

  • for _, a1 := range a.deps {

  •   if pkgdir := a1.pkgdir; pkgdir != a1.p.t.PkgDir() && !incMap[pkgdir] {

  •   	incMap[pkgdir] = true

  •   	inc = append(inc, "-I", pkgdir)

  •   }

  • } -+ // Prepare Go import path list. -+ inc := b.includeArgs("-I", a.deps)

  • // work directory

  • inc = append(inc, "-I", b.work)

  • // then installed package directories of dependencies

  • for _, a1 := range a.deps {

  •   if pkgdir := a1.p.t.PkgDir(); pkgdir == a1.pkgdir && !incMap[pkgdir] {

  •   	incMap[pkgdir] = true

  •   	inc = append(inc, "-I", pkgdir)

  •   }

  • }

  • // compile Go

  • // Compile Go. if len(gofiles) > 0 { out := "go." + b.arch gcargs := []string{"-p", a.p.ImportPath} @@ -570,7 +546,7 @@ func (b *builder) build(a *action) error { objects = append(objects, out) }
  • // copy .h files named for goos or goarch or goos_goarch
  • // Copy .h files named for goos or goarch or goos_goarch // to names using GOOS and GOARCH. // For example, defs_linux_amd64.h becomes defs_GOOS_GOARCH.h. goos_goarch := "" + b.goos + "_" + b.goarch + ".h" @@ -604,7 +580,7 @@ func (b *builder) build(a *action) error { objects = append(objects, out) }
  • // assemble .s files
  • // Assemble .s files. for _, file := range sfiles { out := file[:len(file)-len(".s")] + "." + b.arch if err := b.asm(a.p, obj, obj+out, file); err != nil { @@ -619,19 +595,18 @@ func (b *builder) build(a *action) error { // http://golang.org/issue/2601 objects = append(objects, cgoObjects...)
  • // pack into archive in obj directory
  • // Pack into archive in obj directory if err := b.gopack(a.p, obj, a.objpkg, objects); err != nil { return err }
  • // link if needed.
  • // Link if needed. if a.link {
  •   // command.

  •   // import paths for compiler are introduced by -I.

  •   // for linker, they are introduced by -L.

  •   for i := 0; i < len(inc); i += 2 {

  •   	inc[i] = "-L"

  •   }

-+ // The compiler only cares about direct imports, but the -+ // linker needs the whole dependency tree. -+ all := actionList(a) -+ all = all[:len(all)-1] // drop a -+ inc := b.includeArgs("-L", all) if err := b.ld(a.p, a.target, inc, a.objpkg); err != nil { return err } @@ -659,6 +634,41 @@ func (b *builder) install(a *action) error { return b.copyFile(a.target, a1.target, perm) }

+// includeArgs returns the -I or -L directory list for access +// to the results of the list of actions. +func (b *builder) includeArgs(flag string, all []*action) []string {

  • inc := []string{}
  • incMap := map[string]bool{
  •   b.work:                 true, // handled later

  •   build.Path[0].PkgDir(): true, // goroot

  •   "":                     true, // ignore empty strings
  • }
  • // Look in the temporary space for results of test-specific actions.
  • // This is the $WORK/my/package/_test directory for the
  • // package being built, so there are few of these.
  • for _, a1 := range all {
  •   if dir := a1.pkgdir; dir != a1.p.t.PkgDir() && !incMap[dir] {

  •   	incMap[dir] = true

  •   	inc = append(inc, flag, dir)

  •   }
  • }
  • // Also look in $WORK for any non-test packages that have
  • // been built but not installed.
  • inc = append(inc, flag, b.work)
  • // Finally, look in the installed package directories for each action.
  • for _, a1 := range all {
  •   if dir := a1.pkgdir; dir == a1.p.t.PkgDir() && !incMap[dir] {

  •   	incMap[dir] = true

  •   	inc = append(inc, flag, dir)

  •   }
  • }
  • return inc +}

// removeByRenaming removes file name by moving it to a tmp // directory and deleting the target if possible.\n func removeByRenaming(name string) error { diff --git a/src/cmd/go/pkg.go b/src/cmd/go/pkg.go index 02a7d5b216..33bbc6d9fe 100644 --- a/src/cmd/go/pkg.go +++ b/cmd/go/pkg.go @@ -48,6 +48,7 @@ type Package struct { pkgdir string info *build.DirInfo imports []*Package

  • deps []*Package gofiles []string // GoFiles+CgoFiles+TestGoFiles+XTestGoFiles files, absolute paths target string // installed file for this package (may be executable) fake bool // synthesized package @@ -244,6 +245,9 @@ Stale: p.Deps = append(p.Deps, dep) }\n sort.Strings(p.Deps)\n+ for _, dep := range p.Deps {\n+ p.deps = append(p.deps, packageCache[dep])\n+ }\n // unsafe is a fake package and is never out-of-date.\n if p.Standard && p.ImportPath == "unsafe" {

## GitHub上でのコミットページへのリンク

[https://github.com/golang/go/commit/725f084b1165f910e32cb40006c9d530d95ca938](https://github.com/golang/go/commit/725f084b1165f910e32cb40006c9d530d95ca938)

## 元コミット内容

cmd/go: fix linker arguments

Especially affects tests, but not test-specific. The linker was only being told where to find the direct dependencies of package main. Sometimes that was sufficient to find the rest; sometimes not.

Fixes #2657. Fixes #2666. Fixes #2680.


## 変更の背景

このコミットは、Goのビルドツール `cmd/go` がリンカに渡す引数（特にライブラリ検索パス）が不完全であった問題を解決するために導入されました。具体的には、リンカが実行可能ファイルをビルドする際に、メインパッケージが直接依存しているライブラリのパスしか考慮していませんでした。しかし、実際には、それらの直接的な依存関係がさらに別のライブラリに依存している（推移的な依存関係）場合があり、リンカがそれらのライブラリを見つけられずにビルドが失敗することがありました。

この問題は特にテストの実行時に顕著でした。Goのテストは、テスト対象のパッケージとテストコードを結合して実行可能ファイルを生成するため、通常のアプリケーションビルドよりも複雑な依存関係を持つことがあります。そのため、リンカが推移的な依存関係を解決できないと、テストが失敗するケースが頻発していました。

このコミットによって修正された具体的なIssueは以下の通りです。

*   **Issue #2657: `go test` fails to link when using `go install`**
    *   `go install` でインストールされたパッケージを `go test` でテストしようとすると、リンカが一部の依存関係を見つけられずに失敗するという報告です。これは、リンカが推移的な依存関係のパスを適切に解決できていなかった典型的な例です。
*   **Issue #2666: `go test` fails to link when using `go install` (duplicate of #2657)**
    *   #2657 と同様の問題の報告です。この問題が複数のユーザーによって独立して報告されるほど、影響が広範囲に及んでいたことを示唆しています。
*   **Issue #2680: `go test` fails to link with `go install` and `cgo`**
    *   `cgo` を使用するパッケージで `go install` と `go test` を組み合わせた場合にリンカエラーが発生するという報告です。`cgo` はC言語のコードをGoに組み込む機能であり、Cのライブラリへの依存関係も発生するため、リンカのパス解決がさらに複雑になります。この問題も、リンカが推移的な依存関係を適切に処理できていなかったことに起因します。

これらの問題は、Goのビルドシステムが依存関係の解決において、直接的な依存関係だけでなく、推移的な依存関係も考慮する必要があることを明確に示していました。

## 前提知識の解説

このコミットの理解を深めるために、以下のGo言語のビルドプロセスと関連する概念について解説します。

### Go言語のビルドプロセス

Go言語のビルドプロセスは、主に以下のステップで構成されます。

1.  **コンパイル (Compile)**:
    *   Goのソースコード（`.go` ファイル）は、Goコンパイラ（`gc`）によってオブジェクトファイル（`.o` または `.a`）にコンパイルされます。
    *   この際、コンパイラは他のパッケージの定義を参照するために、そのパッケージのコンパイル済み情報（通常は `.a` ファイル内のエクスポートされたシンボル情報）を必要とします。この情報を見つけるために、コンパイラにはインクルードパス（`-I` フラグ）が渡されます。
2.  **リンク (Link)**:
    *   コンパイルされたオブジェクトファイル群と、依存するライブラリ（静的ライブラリ `.a` や共有ライブラリ `.so` など）が、リンカ（`go tool link`）によって結合され、最終的な実行可能ファイルが生成されます。
    *   リンカは、未解決のシンボル（関数や変数の参照）を解決するために、指定されたライブラリ検索パス（`-L` フラグ）を探索します。

### Goのパッケージ管理と依存関係

Goのプロジェクトは「パッケージ」という単位で構成されます。あるパッケージが別のパッケージの機能を利用する場合、そのパッケージは「依存関係」にあると言えます。

*   **直接的な依存関係**: あるパッケージが `import` 文で直接指定しているパッケージ。
*   **推移的な依存関係**: あるパッケージが直接依存しているパッケージが、さらに別のパッケージに依存している場合、元のパッケージから見てその「別のパッケージ」は推移的な依存関係にあると言います。リンカは、最終的な実行可能ファイルを生成するために、直接的および推移的なすべての依存関係を解決できる必要があります。

### リンカの役割とライブラリパス (`-L` フラグ)

リンカは、コンパイルされたオブジェクトファイル内の未解決のシンボルを、ライブラリファイルから探し出して結合する役割を担います。リンカがライブラリを探す場所を指定するのがライブラリ検索パスであり、通常は `-L` フラグで指定されます。例えば、`-L/path/to/lib` はリンカに `/path/to/lib` ディレクトリをライブラリ検索パスとして追加するよう指示します。

### コンパイラの役割とインクルードパス (`-I` フラグ)

Goコンパイラは、ソースコードをコンパイルする際に、インポートされたパッケージの型情報や関数シグネチャなどを参照します。これらの情報を含むパッケージアーカイブ（`.a` ファイル）の場所をコンパイラに伝えるのがインクルードパスであり、通常は `-I` フラグで指定されます。例えば、`-I/path/to/pkg` はコンパイラに `/path/to/pkg` ディレクトリをインクルードパスとして追加するよう指示します。

### `cmd/go` ツールの役割

`cmd/go` は、Go言語のビルド、テスト、インストール、依存関係管理などを行うための主要なコマンドラインツールです。内部的には、Goコンパイラ（`gc`）、リンカ（`go tool link`）、アセンブラ（`go tool asm`）などの低レベルツールを呼び出し、ビルドプロセス全体をオーケストレーションします。このコミットは、`cmd/go` がリンカを呼び出す際に渡す引数の生成ロジックを修正しています。

### `go test` コマンドの動作

`go test` コマンドは、指定されたパッケージのテストを実行します。この際、テスト対象のパッケージのソースコードと、テストコード（`_test.go` ファイル）を結合し、一時的な実行可能ファイルをビルドして実行します。このビルドプロセスも通常のアプリケーションビルドと同様にコンパイルとリンクを含みますが、テスト固有の依存関係（例えば、テストフレームワークやモックライブラリなど）が加わるため、依存関係の解決がより複雑になることがあります。

### `$WORK` ディレクトリ (Goのビルドキャッシュ/一時ディレクトリ)

Goのビルドプロセスでは、一時的なファイルやコンパイル済みの中間ファイルが `$WORK` 環境変数で指定される一時ディレクトリに生成されます。これはビルドキャッシュとしても機能し、再ビルドの効率化に貢献します。

### `GOROOT`

`GOROOT` はGoのインストールディレクトリを指す環境変数です。Goの標準ライブラリパッケージは `GOROOT/pkg` 以下に配置されており、ビルド時に参照されます。

## 技術的詳細

このコミットの技術的な核心は、`cmd/go` ツールがビルドおよびリンク時に必要なパッケージの検索パスをどのように決定し、リンカやコンパイラに渡すかという点にあります。

### 以前のリンカ引数生成ロジックの問題点

コミット前の `src/cmd/go/build.go` の `build` メソッドでは、リンカに渡す引数（`-L` フラグ）を生成する際に、`a.deps` (直接的な依存関係) の情報のみを使用していました。具体的には、以下の2種類のディレクトリを検索パスとして追加していました。

1.  一時的なビルドディレクトリ (`a1.pkgdir` が `a1.p.t.PkgDir()` と異なる場合): これは、まだインストールされていないがビルド中の一時的なパッケージディレクトリを指します。
2.  インストール済みパッケージディレクトリ (`a1.pkgdir` が `a1.p.t.PkgDir()` と同じ場合): これは、`GOROOT/pkg` や `GOPATH/pkg` などにインストールされたパッケージのディレクトリを指します。

このロジックでは、`a.deps` に含まれる直接的な依存関係のパスしか考慮されず、それらの依存関係がさらに別のパッケージに依存している「推移的な依存関係」のパスがリンカに適切に伝達されませんでした。コンパイラは直接的なインポートパスのみを必要としますが、リンカは最終的な実行可能ファイルを生成するために、すべての推移的な依存関係のライブラリを解決できる必要があります。このギャップが、前述のリンカエラーの原因となっていました。

### 新しい `includeArgs` 関数の導入

このコミットの主要な変更点は、`builder` 型に新しいプライベートメソッド `includeArgs` が導入されたことです。この関数は、コンパイラ（`-I` フラグ）またはリンカ（`-L` フラグ）に渡すための、必要なすべてのパッケージディレクトリのリストを生成する汎用的な役割を担います。

`includeArgs` 関数は以下のロジックでパスを収集します。

1.  **初期マップの準備**:
    *   `b.work` (現在のビルド作業ディレクトリ)
    *   `build.Path[0].PkgDir()` (GOROOTのパッケージディレクトリ)
    *   空文字列 (無視するため)
    これらを `incMap` に追加し、重複を避けます。
2.  **テスト固有のアクションの結果を探索**:
    *   `all` 引数で渡されたすべてのアクション（ビルド対象のパッケージとそのすべての依存関係）をイテレートします。
    *   `a1.pkgdir` が `a1.p.t.PkgDir()` と異なる場合（つまり、一時的なビルドディレクトリにある場合）、そのディレクトリを `incMap` に追加し、`flag` と共に `inc` スライスに追加します。これは主にテスト固有の一時ディレクトリを対象としています。
3.  **`$WORK` ディレクトリの追加**:
    *   `b.work` (現在のビルド作業ディレクトリ) を `flag` と共に `inc` スライスに追加します。これは、インストールされていないが `$WORK` ディレクトリにビルドされた非テストパッケージを対象とします。
4.  **インストール済みパッケージディレクトリの探索**:
    *   再度 `all` 引数で渡されたすべてのアクションをイテレートします。
    *   `a1.pkgdir` が `a1.p.t.PkgDir()` と同じ場合（つまり、インストール済みパッケージディレクトリにある場合）、そのディレクトリを `incMap` に追加し、`flag` と共に `inc` スライスに追加します。

この `includeArgs` 関数は、コンパイラには直接的な依存関係のみを渡す一方で、リンカには `actionList(a)` を使用して、ビルド対象のパッケージの**すべての推移的な依存関係**を含む `action` のリストを渡すように変更されました。これにより、リンカは必要なすべてのライブラリを適切に検索できるようになります。

### `pkg.go` における `Package` 構造体の変更

`src/cmd/go/pkg.go` では、`Package` 構造体に新しいフィールド `deps []*Package` が追加されました。

*   以前は `p.Deps []string` というフィールドがあり、これはパッケージが直接依存するパッケージのインポートパスの文字列スライスでした。
*   新しい `p.deps []*Package` は、`Package` 型のポインタスライスであり、パッケージが直接依存するパッケージの実際の `Package` オブジェクトへの参照を保持します。

この変更は、`build.go` で `actionList(a)` が推移的な依存関係を効率的に収集するために、`Package` オブジェクト間のリンクを直接利用できるようにするための準備です。`p.Deps` (文字列スライス) から `packageCache` を参照して `p.deps` (Packageポインタスライス) を構築することで、依存関係グラフのトラバーサルが容易になります。

### `actionList` の役割

コミットの差分には直接 `actionList` の定義は含まれていませんが、`build.go` の変更箇所で `all := actionList(a)` と呼び出されていることから、これは特定の `action` からその推移的な依存関係を含むすべてのアクションのリストを再帰的に収集するヘルパー関数であると推測されます。リンカがすべての依存関係を必要とするため、この関数が重要な役割を果たします。

## コアとなるコードの変更箇所

このコミットによる主要なコード変更は以下の2つのファイルに集中しています。

1.  **`src/cmd/go/build.go`**:
    *   `builder.build` メソッド内のGoコンパイルおよびリンク引数生成ロジックが大幅に変更されました。
    *   Goコンパイル時のインクルードパス (`-I`) 生成ロジックが、新しい `b.includeArgs("-I", a.deps)` の呼び出しに置き換えられました。
    *   リンカ引数 (`-L`) 生成ロジックが完全に削除され、代わりに `all := actionList(a)` で取得したすべての推移的な依存関係のリストを `b.includeArgs("-L", all)` に渡す形に変更されました。
    *   新しいプライベートメソッド `builder.includeArgs(flag string, all []*action) []string` が追加されました。この関数が、コンパイラやリンカに渡すための適切なディレクトリリストを生成する中心的なロジックを担います。

2.  **`src/cmd/go/pkg.go`**:
    *   `Package` 構造体に `deps []*Package` という新しいフィールドが追加されました。
    *   `Package.Stale` メソッド内で、既存の `p.Deps` (文字列スライス) を基に、新しく追加された `p.deps` (Packageポインタスライス) を初期化するロジックが追加されました。これにより、パッケージの依存関係が `Package` オブジェクトとして直接参照できるようになります。

## コアとなるコードの解説

### `src/cmd/go/build.go` の変更

最も重要な変更は、`builder.build` メソッド内のリンカ引数生成部分です。

```go
// 変更前:
// for i := 0; i < len(inc); i += 2 {
//     inc[i] = "-L"
// }

// 変更後:
// The compiler only cares about direct imports, but the
// linker needs the whole dependency tree.
// all := actionList(a)
// all = all[:len(all)-1] // drop a
// inc := b.includeArgs("-L", all)

変更前は、コンパイラ用に生成された inc スライス（-I フラグとパスのペア）の -I を単純に -L に置き換えてリンカに渡していました。これは、コンパイラとリンカが必要とするパスの範囲が異なるという事実を無視していました。コンパイラは直接インポートするパッケージの定義があれば十分ですが、リンカは最終的な実行可能ファイルを生成するために、すべての推移的な依存関係のライブラリファイルを見つける必要があります。

変更後では、まず actionList(a) を呼び出して、現在のビルドアクション a が依存するすべての推移的なアクション（つまり、すべての依存パッケージのビルドアクション）のリスト all を取得します。そして、この all リストを新しい b.includeArgs 関数に渡すことで、リンカが必要とするすべてのライブラリ検索パス（-L フラグ）を正確に生成しています。コメントにある all = all[:len(all)-1] // drop a は、actionList が自身のアクション a も含んで返す場合があるため、それを除外している可能性があります。

builder.includeArgs 関数の解説

この新しい関数は、コンパイラ（-I）とリンカ（-L）の両方で再利用可能なパス生成ロジックを提供します。

func (b *builder) includeArgs(flag string, all []*action) []string {
	inc := []string{}
	incMap := map[string]bool{
		b.work:                 true, // handled later
		build.Path[0].PkgDir(): true, // goroot
		"":                     true, // ignore empty strings
	}

	// Look in the temporary space for results of test-specific actions.
	// This is the $WORK/my/package/_test directory for the
	// package being built, so there are few of these.
	for _, a1 := range all {
		if dir := a1.pkgdir; dir != a1.p.t.PkgDir() && !incMap[dir] {
			incMap[dir] = true
			inc = append(inc, flag, dir)
		}
	}

	// Also look in $WORK for any non-test packages that have
	// been built but not installed.
	inc = append(inc, flag, b.work)

	// Finally, look in the installed package directories for each action.
	for _, a1 := range all {
		if dir := a1.pkgdir; dir == a1.p.t.PkgDir() && !incMap[dir] {
			incMap[dir] = true
			inc = append(inc, flag, dir)
		}
	}

	return inc
}

この関数は、all で渡されたすべてのアクション（パッケージ）について、以下の3種類のディレクトリを収集し、重複を排除しながら flag（-I または -L）と共にリストに追加します。

  1. 一時的なビルドディレクトリ: a1.pkgdir が a1.p.t.PkgDir() と異なる場合、これは通常、$WORK ディレクトリ内のテスト固有の一時ディレクトリや、まだインストールされていないパッケージの一時ビルドディレクトリを指します。
  2. $WORK ディレクトリ: b.work は、Goのビルドプロセスが一時ファイルや中間成果物を格納する作業ディレクトリです。ここにビルドされたがまだインストールされていないパッケージのアーカイブが含まれる可能性があります。
  3. インストール済みパッケージディレクトリ: a1.pkgdir が a1.p.t.PkgDir() と同じ場合、これは GOROOT/pkg や GOPATH/pkg などにインストールされたパッケージのディレクトリを指します。

この包括的なパス収集ロジックにより、リンカは必要なすべてのライブラリファイルを見つけることができるようになり、推移的な依存関係の解決問題が解消されました。

src/cmd/go/pkg.go の変更

Package 構造体への deps []*Package フィールドの追加と、その初期化ロジックは、build.go で actionList のような関数が依存関係グラフを効率的にトラバースできるようにするための基盤を提供します。

type Package struct {
	// ... 既存のフィールド ...
	imports []*Package
	deps    []*Package // 新しく追加されたフィールド
	// ...
}

// Package.Stale メソッド内:
// ...
// sort.Strings(p.Deps) // p.Deps は文字列スライス
// for _, dep := range p.Deps {
//     p.deps = append(p.deps, packageCache[dep]) // 新しい p.deps を Package オブジェクトで初期化
// }

p.Deps はインポートパスの文字列リストですが、p.deps は実際の Package オブジェクトへのポインタのリストです。packageCache は、インポートパスをキーとして Package オブジェクトを格納するマップであると推測されます。これにより、文字列ベースの参照から、直接オブジェクトへの参照に変換され、依存関係グラフの走査がより直接的かつ効率的になります。

関連リンク

参考にした情報源リンク

  • Go Issue #2657: go test fails to link when using go install (https://github.com/golang.go/issues/2657)
  • Go Issue #2666: go test fails to link when using go install (https://github.com/golang.go/issues/2666)
  • Go Issue #2680: go test fails to link with go install and cgo (https://github.com/golang.go/issues/2680)
  • Go言語のビルドプロセスに関する一般的な知識 (Go公式ドキュメント、Goブログなど)
  • リンカとコンパイラの役割に関する一般的な知識 (コンピュータサイエンスの基礎知識)
  • Goのパッケージと依存関係に関する一般的な知識 (Go公式ドキュメント)
  • go tool link および go tool compile のコマンドライン引数に関する一般的な知識 (Go公式ドキュメント)
  • GOROOT および $WORK 環境変数に関する一般的な知識 (Go公式ドキュメント)