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

このコミットは、Go言語のツールチェインにおけるPlan 9環境でのビルドに関する2つの問題を修正します。具体的には、cmd/distにおけるインクルードパスの問題と、cmd/cc/bv.cにおけるlibc.hの二重インクルードの問題に対処しています。

コミット

commit fd7ddad160bfcfd861db00e5d4df01ceaf0a66e9
Author: Lucio De Re <lucio.dere@gmail.com>
Date:   Fri Sep 6 16:15:44 2013 +1000

    cmd/dist: Plan 9 build needs an additional include path
    cmd/cc: bv.c imports libc.h twice
    
    When using the Plan 9 compiler, the invocation
    
            #include <../ld/textflag.h>
    
    works for the toolchain, but not for the MACH library.
    
    Module cmd/cc/bv.c includes libc.h and "cc.h", which in
    turn also includes libc.h.  In the Plan 9 context, this
    causes a number of duplicate definitions.
    
    R=golang-dev, rsc, r
    CC=golang-dev
    https://golang.org/cl/13303047

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

https://github.com/golang/go/commit/fd7ddad160bfcfd861db00e5d4df01ceaf0a66e9

元コミット内容

cmd/dist: Plan 9 build needs an additional include path
cmd/cc: bv.c imports libc.h twice

When using the Plan 9 compiler, the invocation

        #include <../ld/textflag.h>

works for the toolchain, but not for the MACH library.

Module cmd/cc/bv.c includes libc.h and "cc.h", which in
turn also includes libc.h.  In the 9 context, this
causes a number of duplicate definitions.

変更の背景

このコミットは、Go言語のビルドシステムがPlan 9オペレーティングシステム上で正しく動作するようにするための修正です。Goは元々Googleで開発されましたが、その設計思想にはPlan 9の影響が強く見られます。特に、Goの初期のツールチェインはPlan 9のツールチェイン（8c, 8lなど）をベースにしていました。

変更の背景には、以下の2つの具体的な問題がありました。

1. textflag.hのインクルードパス問題: Plan 9のCコンパイラを使用する際、#include <../ld/textflag.h>のような相対パス指定が、Goのツールチェイン自体では機能するものの、MACHライブラリ（おそらくGoのランタイムや低レベルな部分で使用されるライブラリ）のビルド時には問題を引き起こしていました。これは、コンパイラが特定のインクルードパスを期待しているにもかかわらず、それが提供されていないために発生するビルドエラーを示唆しています。
2. libc.hの二重インクルード問題: src/cmd/cc/bv.cというファイルが、libc.hを直接インクルードしているだけでなく、cc.hという別のヘッダファイルもインクルードしており、そのcc.hもまたlibc.hをインクルードしていました。C/C++では、同じヘッダファイルが複数回インクルードされると、通常は#ifndef/#define/#endifのようなインクルードガードによって重複定義が回避されます。しかし、Plan 9のコンテキストでは、この二重インクルードが重複定義エラーを引き起こしていました。これは、Plan 9のCコンパイラや標準ライブラリのヘッダファイルの特性、あるいはGoのビルドシステムがPlan 9環境でどのようにヘッダファイルを扱っていたかに関連する問題です。

これらの問題は、GoをPlan 9環境でビルド・実行する際の互換性と安定性を確保するために修正が必要でした。

前提知識の解説

• Plan 9 from Bell Labs: ベル研究所で開発された分散オペレーティングシステム。Go言語の設計思想や初期のツールチェインに大きな影響を与えました。特に、Goの初期のコンパイラやリンカはPlan 9のツールチェイン（8c, 8lなど）を基盤としていました。
• Go言語のビルドシステム (cmd/dist): GoのソースコードからGoのツールチェイン自体をビルドするためのコマンドです。make.bashやall.bashスクリプトによって内部的に呼び出され、コンパイラ、リンカ、標準ライブラリなどを構築します。異なるOSやアーキテクチャ（クロスコンパイル）に対応するためのロジックも含まれています。
• GoのCコンパイラ (cmd/cc): Goのツールチェインの一部として、Goのランタイムや一部の標準ライブラリ（特にOSとのインターフェース部分）でC言語のコードをコンパイルするために使用されるコンパイラです。これは、Goのソースコードを直接コンパイルするcmd/compileとは異なります。
• ヘッダファイル (.h): C言語において、関数宣言、マクロ定義、構造体定義などが含まれるファイルです。#includeディレクティブによってソースコードに組み込まれます。
• インクルードパス (-Iオプション): Cコンパイラにヘッダファイルを検索するディレクトリを指定するためのオプションです。コンパイラは、指定されたパスの中から#includeディレクティブで指定されたヘッダファイルを探します。
• libc.h: C言語の標準ライブラリのヘッダファイルの一つで、一般的なユーティリティ関数や型定義が含まれています。
• textflag.h: Goのリンカ（cmd/ld）に関連するヘッダファイルで、アセンブリコードや低レベルなコードで特定のシンボルにフラグを設定するために使用される定数やマクロが定義されていると考えられます。これは、Goのランタイムがアセンブリ言語で書かれた部分とC言語で書かれた部分を連携させるために重要です。
• MACHライブラリ: コミットメッセージに「MACH library」と記載されていますが、これは特定のライブラリを指すというよりは、Goのランタイムや低レベルなシステムコールを扱う部分、あるいはPlan 9のシステムコールインターフェースに関連するコード群を指している可能性があります。Goのランタイムは、OSとのインタラクションのためにC言語やアセンブリ言語で書かれた部分を含んでいます。

技術的詳細

このコミットは、GoのビルドシステムがPlan 9環境で直面していた2つの独立した問題を解決しています。

1. cmd/distにおけるインクルードパスの追加:

   • 問題点: Plan 9のCコンパイラが#include <../ld/textflag.h>のような相対パス指定を解決する際に、Goのツールチェイン自体は問題なくビルドできるものの、Goのランタイムや低レベルな部分（「MACH library」と表現されている部分）のビルド時にtextflag.hが見つからないという問題が発生していました。これは、コンパイラが期待するインクルードパスが不足していることを示唆しています。
   • 解決策: src/cmd/dist/build.c内のinstall関数（Goのビルドプロセスでコンパイルオプションを設定する部分）に、goroot/src/cmd/ldという新しいインクルードパスを追加しました。これにより、Plan 9のCコンパイラがtextflag.hを正しく見つけられるようになり、MACHライブラリのビルドが成功するようになりました。この修正は、Plan 9のCコンパイラが相対パスの解決に関して特定の挙動を持つことへのワークアラウンドとして記述されています。

2. cmd/cc/bv.cにおけるlibc.hの二重インクルードの解消:

   • 問題点: src/cmd/cc/bv.cファイルは、#include <libc.h>と#include "cc.h"の両方を含んでいました。そして、cc.hもまた内部でlibc.hをインクルードしていました。通常、C言語のヘッダファイルは、多重インクルードを防ぐためにインクルードガード（#ifndef/#define/#endif）を使用します。しかし、Plan 9のコンテキストでは、この二重インクルードが重複定義エラーを引き起こしていました。これは、Plan 9のlibc.hがインクルードガードを持っていなかったか、あるいはGoのビルドシステムがPlan 9環境でヘッダファイルを処理する方法に特有の問題があったことを示唆しています。
   • 解決策: src/cmd/cc/bv.cから直接の#include <libc.h>行を削除しました。cc.hが既にlibc.hをインクルードしているため、bv.cはcc.hを介してlibc.hの内容にアクセスできます。これにより、libc.hの二重インクルードが解消され、Plan 9環境での重複定義エラーが回避されました。

これらの修正は、GoのツールチェインがPlan 9という特定の環境で堅牢に動作するための、低レベルかつ環境依存の調整です。

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

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

1. src/cmd/cc/bv.c:

   --- a/src/cmd/cc/bv.c
   +++ b/src/cmd/cc/bv.c
   @@ -3,7 +3,6 @@
    // license that can be found in the LICENSE file.
    
    #include <u.h>
   -#include <libc.h>
    #include "cc.h"
    
    enum {
   

   この変更では、#include <libc.h>の行が削除されています。

2. src/cmd/dist/build.c:

   --- a/src/cmd/dist/build.c
   +++ b/src/cmd/dist/build.c
   @@ -932,6 +932,8 @@ install(char *dir)
    			vadd(&compile, "-Bp+");
    			vadd(&compile, bpathf(&b, "-I%s/include/plan9", goroot));
    			vadd(&compile, bpathf(&b, "-I%s/include/plan9/%s", goroot, gohostarch));
   +			// Work around Plan 9 C compiler's handling of #include with .. path.
   +			vadd(&compile, bpathf(&b, "-I%s/src/cmd/ld", goroot));
    		} else {
    			vcopy(&compile, gccargs.p, gccargs.len);
    			vadd(&compile, "-c");
   

   この変更では、vadd(&compile, bpathf(&b, "-I%s/src/cmd/ld", goroot));という行が追加されています。これは、Plan 9のCコンパイラが..パスを含む#includeを処理する方法を回避するためのコメントが付されています。

コアとなるコードの解説

1. src/cmd/cc/bv.cの変更:

   • #include <libc.h>の削除は、bv.cがlibc.hを直接インクルードする必要がないことを意味します。これは、bv.cが既にインクルードしている"cc.h"が、内部的にlibc.hをインクルードしているためです。この修正により、Plan 9環境で発生していたlibc.hの重複定義エラーが解消されます。これは、C言語のヘッダファイルの依存関係を整理し、冗長なインクルードを排除する一般的なプラクティスに沿っています。

2. src/cmd/dist/build.cの変更:

   • vadd(&compile, bpathf(&b, "-I%s/src/cmd/ld", goroot));の追加は、GoのビルドシステムがPlan 9のCコンパイラを呼び出す際に、-Iオプションを使って$GOROOT/src/cmd/ldディレクトリをインクルードパスに追加することを意味します。
   • bpathf(&b, ...)は、パスを構築するためのヘルパー関数です。
   • gorootはGoのインストールディレクトリのルートパスです。
   • この追加により、#include <../ld/textflag.h>のような相対パス指定が、Plan 9のCコンパイラによって正しく解決されるようになります。特に、textflag.hが$GOROOT/src/cmd/ldディレクトリ内に存在する場合、このインクルードパスの追加によってコンパイラがファイルを見つけられるようになります。コメントにある「Work around Plan 9 C compiler's handling of #include with .. path.」は、Plan 9のCコンパイラが相対パス（特に..を含むもの）の解決において、他のコンパイラとは異なる、あるいはより厳密な挙動を示すことへの対処であることを示唆しています。

これらの変更は、GoのツールチェインがPlan 9という特定の環境で、C言語のコンパイルとヘッダファイルの解決に関する問題を克服し、安定したビルドを可能にするために不可欠でした。

関連リンク

• Go言語の公式ウェブサイト: https://golang.org/
• Go言語のソースコードリポジトリ (GitHub): https://github.com/golang/go
• Goのコードレビューシステム (Gerrit): https://go-review.googlesource.com/
• Plan 9 from Bell Labs: https://9p.io/plan9/

参考にした情報源リンク

• Go言語のソースコード (特にsrc/cmd/distとsrc/cmd/ccディレクトリ)
• C言語のインクルードパスとヘッダファイルの概念に関する一般的な知識
• Plan 9オペレーティングシステムに関する一般的な情報
• Goのビルドプロセスに関するドキュメントや議論 (GoのメーリングリストやIssueトラッカーなど)
• git diffコマンドの出力
• google_web_searchツールによる「Plan 9 C compiler include path issues」や「Go Plan 9 build problems」などの検索クエリ。

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

このコミットは、Go言語のツールチェインにおけるPlan 9環境でのビルドに関する2つの問題を修正します。具体的には、cmd/distにおけるインクルードパスの問題と、cmd/cc/bv.cにおけるlibc.hの二重インクルードの問題に対処しています。

コミット

commit fd7ddad160bfcfd861db00e5d4df01ceaf0a66e9
Author: Lucio De Re <lucio.dere@gmail.com>
Date:   Fri Sep 6 16:15:44 2013 +1000

    cmd/dist: Plan 9 build needs an additional include path
    cmd/cc: bv.c imports libc.h twice
    
    When using the Plan 9 compiler, the invocation
    
            #include <../ld/textflag.h>
    
    works for the toolchain, but not for the MACH library.
    
    Module cmd/cc/bv.c includes libc.h and "cc.h", which in
    turn also includes libc.h.  In the Plan 9 context, this
    causes a number of duplicate definitions.
    
    R=golang-dev, rsc, r
    CC=golang-dev
    https://golang.org/cl/13303047

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

https://github.com/golang/go/commit/fd7ddad160bfcfd861db00e5d4df01ceaf0a66e9

元コミット内容

cmd/dist: Plan 9 build needs an additional include path
cmd/cc: bv.c imports libc.h twice

When using the Plan 9 compiler, the invocation

        #include <../ld/textflag.h>

works for the toolchain, but not for the MACH library.

Module cmd/cc/bv.c includes libc.h and "cc.h", which in
turn also includes libc.h.  In the 9 context, this
causes a number of duplicate definitions.

変更の背景

このコミットは、Go言語のビルドシステムがPlan 9オペレーティングシステム上で正しく動作するようにするための修正です。Goは元々Googleで開発されましたが、その設計思想にはPlan 9の影響が強く見られます。特に、Goの初期のツールチェインはPlan 9のツールチェイン（8c, 8lなど）をベースにしていました。

変更の背景には、以下の2つの具体的な問題がありました。

1. textflag.hのインクルードパス問題: Plan 9のCコンパイラを使用する際、#include <../ld/textflag.h>のような相対パス指定が、Goのツールチェイン自体では機能するものの、MACHライブラリ（おそらくGoのランタイムや低レベルな部分で使用されるライブラリ）のビルド時には問題を引き起こしていました。これは、コンパイラが特定のインクルードパスを期待しているにもかかわらず、それが提供されていないために発生するビルドエラーを示唆しています。
2. libc.hの二重インクルード問題: src/cmd/cc/bv.cというファイルが、libc.hを直接インクルードしているだけでなく、cc.hという別のヘッダファイルもインクルードしており、そのcc.hもまたlibc.hをインクルードしていました。C/C++では、同じヘッダファイルが複数回インクルードされると、通常は#ifndef/#define/#endifのようなインクルードガードによって重複定義が回避されます。しかし、Plan 9のコンテキストでは、この二重インクルードが重複定義エラーを引き起こしていました。これは、Plan 9のCコンパイラや標準ライブラリのヘッダファイルの特性、あるいはGoのビルドシステムがPlan 9環境でどのようにヘッダファイルを扱っていたかに関連する問題です。

これらの問題は、GoをPlan 9環境でビルド・実行する際の互換性と安定性を確保するために修正が必要でした。

前提知識の解説

• Plan 9 from Bell Labs: ベル研究所で開発された分散オペレーティングシステム。Go言語の設計思想や初期のツールチェインに大きな影響を与えました。特に、Goの初期のコンパイラやリンカはPlan 9のツールチェイン（8c, 8lなど）を基盤としていました。
• Go言語のビルドシステム (cmd/dist): GoのソースコードからGoのツールチェイン自体をビルドするためのコマンドです。make.bashやall.bashスクリプトによって内部的に呼び出され、コンパイラ、リンカ、標準ライブラリなどを構築します。異なるOSやアーキテクチャ（クロスコンパイル）に対応するためのロジックも含まれています。
• GoのCコンパイラ (cmd/cc): Goのツールチェインの一部として、Goのランタイムや一部の標準ライブラリ（特にOSとのインターフェース部分）でC言語のコードをコンパイルするために使用されるコンパイラです。これは、Goのソースコードを直接コンパイルするcmd/compileとは異なります。
• ヘッダファイル (.h): C言語において、関数宣言、マクロ定義、構造体定義などが含まれるファイルです。#includeディレクティブによってソースコードに組み込まれます。
• インクルードパス (-Iオプション): Cコンパイラにヘッダファイルを検索するディレクトリを指定するためのオプションです。コンパイラは、指定されたパスの中から#includeディレクティブで指定されたヘッダファイルを探します。
• libc.h: C言語の標準ライブラリのヘッダファイルの一つで、一般的なユーティリティ関数や型定義が含まれています。
• textflag.h: Goのリンカ（cmd/ld）に関連するヘッダファイルで、アセンブリコードや低レベルなコードで特定のシンボルにフラグを設定するために使用される定数やマクロが定義されていると考えられます。これは、Goのランタイムがアセンブリ言語で書かれた部分とC言語で書かれた部分を連携させるために重要です。
• MACHライブラリ: コミットメッセージに「MACH library」と記載されていますが、これは特定のライブラリを指すというよりは、Goのランタイムや低レベルなシステムコールを扱う部分、あるいはPlan 9のシステムコールインターフェースに関連するコード群を指している可能性があります。Goのランタイムは、OSとのインタラクションのためにC言語やアセンブリ言語で書かれた部分を含んでいます。

技術的詳細

このコミットは、GoのビルドシステムがPlan 9環境で直面していた2つの独立した問題を解決しています。

1. cmd/distにおけるインクルードパスの追加:

   • 問題点: Plan 9のCコンパイラが#include <../ld/textflag.h>のような相対パス指定を解決する際に、Goのツールチェイン自体は問題なくビルドできるものの、Goのランタイムや低レベルな部分（「MACH library」と表現されている部分）のビルド時にtextflag.hが見つからないという問題が発生していました。これは、コンパイラが期待するインクルードパスが不足していることを示唆しています。
   • 解決策: src/cmd/dist/build.c内のinstall関数（Goのビルドプロセスでコンパイルオプションを設定する部分）に、goroot/src/cmd/ldという新しいインクルードパスを追加しました。これにより、Plan 9のCコンパイラがtextflag.hを正しく見つけられるようになり、MACHライブラリのビルドが成功するようになりました。この修正は、Plan 9のCコンパイラが相対パスの解決に関して特定の挙動を持つことへのワークアラウンドとして記述されています。

2. cmd/cc/bv.cにおけるlibc.hの二重インクルードの解消:

   • 問題点: src/cmd/cc/bv.cファイルは、#include <libc.h>と#include "cc.h"の両方を含んでいました。そして、cc.hもまた内部でlibc.hをインクルードしていました。通常、C言語のヘッダファイルは、多重インクルードを防ぐためにインクルードガード（#ifndef/#define/#endif）を使用します。しかし、Plan 9のコンテキストでは、この二重インクルードが重複定義エラーを引き起こしていました。これは、Plan 9のlibc.hがインクルードガードを持っていなかったか、あるいはGoのビルドシステムがPlan 9環境でヘッダファイルを処理する方法に特有の問題があったことを示唆しています。
   • 解決策: src/cmd/cc/bv.cから直接の#include <libc.h>行を削除しました。cc.hが既にlibc.hをインクルードしているため、bv.cはcc.hを介してlibc.hの内容にアクセスできます。これにより、libc.hの二重インクルードが解消され、Plan 9環境での重複定義エラーが回避されました。

これらの修正は、GoのツールチェインがPlan 9という特定の環境で堅牢に動作するための、低レベルかつ環境依存の調整です。

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

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

1. src/cmd/cc/bv.c:

   --- a/src/cmd/cc/bv.c
   +++ b/src/cmd/cc/bv.c
   @@ -3,7 +3,6 @@
    // license that can be found in the LICENSE file.
    
    #include <u.h>
   -#include <libc.h>
    #include "cc.h"
    
    enum {
   

   この変更では、#include <libc.h>の行が削除されています。

2. src/cmd/dist/build.c:

   --- a/src/cmd/dist/build.c
   +++ b/src/cmd/dist/build.c
   @@ -932,6 +932,8 @@ install(char *dir)
    			vadd(&compile, "-Bp+");
    			vadd(&compile, bpathf(&b, "-I%s/include/plan9", goroot));
    			vadd(&compile, bpathf(&b, "-I%s/include/plan9/%s", goroot, gohostarch));
   +			// Work around Plan 9 C compiler's handling of #include with .. path.
   +			vadd(&compile, bpathf(&b, "-I%s/src/cmd/ld", goroot));
    		} else {
    			vcopy(&compile, gccargs.p, gccargs.len);
    			vadd(&compile, "-c");
   

   この変更では、vadd(&compile, bpathf(&b, "-I%s/src/cmd/ld", goroot));という行が追加されています。これは、Plan 9のCコンパイラが..パスを含む#includeを処理する方法を回避するためのコメントが付されています。

コアとなるコードの解説

1. src/cmd/cc/bv.cの変更:

   • #include <libc.h>の削除は、bv.cがlibc.hを直接インクルードする必要がないことを意味します。これは、bv.cが既にインクルードしている"cc.h"が、内部的にlibc.hをインクルードしているためです。この修正により、Plan 9環境で発生していたlibc.hの重複定義エラーが解消されます。これは、C言語のヘッダファイルの依存関係を整理し、冗長なインクルードを排除する一般的なプラクティスに沿っています。

2. src/cmd/dist/build.cの変更:

   • vadd(&compile, bpathf(&b, "-I%s/src/cmd/ld", goroot));の追加は、GoのビルドシステムがPlan 9のCコンパイラを呼び出す際に、-Iオプションを使って$GOROOT/src/cmd/ldディレクトリをインクルードパスに追加することを意味します。
   • bpathf(&b, ...)は、パスを構築するためのヘルパー関数です。
   • gorootはGoのインストールディレクトリのルートパスです。
   • この追加により、#include <../ld/textflag.h>のような相対パス指定が、Plan 9のCコンパイラによって正しく解決されるようになります。特に、textflag.hが$GOROOT/src/cmd/ldディレクトリ内に存在する場合、このインクルードパスの追加によってコンパイラがファイルを見つけられるようになります。コメントにある「Work around Plan 9 C compiler's handling of #include with .. path.」は、Plan 9のCコンパイラが相対パス（特に..を含むもの）の解決において、他のコンパイラとは異なる、あるいはより厳密な挙動を示すことへの対処であることを示唆しています。

これらの変更は、GoのツールチェインがPlan 9という特定の環境で、C言語のコンパイルとヘッダファイルの解決に関する問題を克服し、安定したビルドを可能にするために不可欠でした。

関連リンク

• Go言語の公式ウェブサイト: https://golang.org/
• Go言語のソースコードリポジトリ (GitHub): https://github.com/golang/go
• Goのコードレビューシステム (Gerrit): https://go-review.googlesource.com/
• Plan 9 from Bell Labs: https://9p.io/plan9/

参考にした情報源リンク

• Go言語のソースコード (特にsrc/cmd/distとsrc/cmd/ccディレクトリ)
• C言語のインクルードパスとヘッダファイルの概念に関する一般的な知識
• Plan 9オペレーティングシステムに関する一般的な情報
• Goのビルドプロセスに関するドキュメントや議論 (GoのメーリングリストやIssueトラッカーなど)
• git diffコマンドの出力
• google_web_searchツールによる「Plan 9 C compiler include path issues」や「Go Plan 9 build problems」などの検索クエリ。