cgoでGolangとC++ライブラリをリンクするとき、何が起きているのか

マングリング is 何という人のために簡単に説明します。分かってる人は読み飛ばしてオッケーです。簡単のために、クラスのメンバ関数じゃなくて普通のグローバルな関数で void Hoge(int, const char*) という関数を考えます。

<code class="cpp">#include &lt;cstdio&gt;

void Hoge(int i, const char* str) {
    std::printf("i is %d, str is %s", i, str);
}
</code>```

これを `gcc -c test.cpp -o test.o` でコンパイルして中間ファイルを生成して、中のシンボルをみる `nm` コマンドで調べてみます。

$ nm test.o 0000000000000000 T _Z4HogeiPKc U printf```

Hoge 関数が _Z4HogeiPKc というシンボル名で格納されています。これが、C++のマングリング(名前修飾)です。なぜこうなるかというと、C++は名前同じで引数が違う関数を許容するので名前がシンボル名になってるとリンクする関数を解決できないからですね。このよくわからん _Z4HogeiPKc という文字列は、デマングルすることで可読性のある文字列に戻すことができます。それが c++filt コマンドです。

$ nm test.o | c++filt
0000000000000000 T Hoge(int, char const*)
                 U printf```

こんな感じで読めるようになりました。ドヤッ!

で、別言語から呼ぶには_Z4HogeiPKcという関数名で呼べばいいんですが、さすがにマングリング規則を覚えてマングリングした関数名をすぐ書ける人はほとんどいないはずです。そこで使うのが `extern "C"` というリンケージ方法の変更です。さっきのソースコードをこう変更します。

#include <cstdio>

}```

これをもう一度コンパイルしてnmコマンドにかけると、シンボル名が変わります。

$ nm test.o
0000000000000000 T Hoge
                 U printf```

この状態なら、他の言語から `Hoge` という関数名で呼び出しが可能です。

</div>
さてやっと本題です。そんな感じでC++のライブラリをCでラップしたのを書いたのですが、これをGoから呼び出すところで1日ほどハマりました。golangでC/C++のライブラリを使うときには[cgo](http://golang.org/cmd/cgo/)という仕組みでライブラリをリンクします。

このとき、Goのソースコードで `import "C"` する前にコメントでCヘッダと `#cgo` ディレクティブを書くわけですが、これを書くと絶対失敗するので書いてはいけないオプションというのがあるのでそれのご紹介、というのが今日の本題です。

それは何かというと、**リンクするライブラリがC++だからといって、 `#cgo CFLAGS` で `-x c++` を指定してはいけない**という点です。

逆にこれを指定するとどういう悲劇が起こるかを知るには、cgo(gc)のビルドプロセスを知る必要があります。今回は最新のgo 1.3.3と、gcc 4.9.1を使っています(なお、go 1.2.2, gcc 4.4.7を使っても同じです)。

Goのビルドプロセスは `go [build|run]` に `-x` オプションをつけて実行すると実際に実行しているコマンドが見えます。長いのでここに掲載するのは省略しますが、その処理の中身を見ていくと、こんな感じです(x86-64環境なので6c/6lを使います)。

1.  `import "C"` しているgoのソースにcgoコマンドを実行して_objディレクトリにGoとCの間の呼び出しをブリッジするCソースコードを生成
1. 6c, 6gコマンドで、cgoが生成したソースをコンパイルして.6ファイルを生成
1. gccコマンドで、cgoが生成したソースをコンパイルして.oファイルを生成
1. go tool packで.6ファイルと.oファイルを連結してgo形式の静的リンクファイル( `command-line-arguments.a` )を生成
1. go形式の静的リンクファイルを6lコマンドにかけてネイティブ実行ファイルを生成

で、問題はCコンパイラ向けのCFLAGSに `-x c++` を指定したときに何が起こるかという話です。

こんな感じのGoとCヘッダをを書きます。前提として、別途Makefileでgccを使ってコンパイルする `bridge.cpp` が別にあって、そこから `bridge.a` を生成しています。で、それを静的ファイルとしてGoが吐き出すバイナリに静的リンクするように `#cgo LDFLAGS` で指定しています。

$ cat bridge.h extern “C” {

}```

$ cat main.go
<code class="golang">package main
/*
#cgo CFLAGS: -x c++ -fpermissive
#cgo LDFLAGS: -lrt -lstdc++ bridge.a
#include "bridge.h"
*/
import "C"
func main() {
    app := C.CreateApp()   // create C++ app object
    C.Run(app)             // enter main loop
}
</code>```

するとcgoはこんな感じのグルーコードを生成します。このコードは `go build -x` で出てきたコマンドを1個ずつ手で実行しないとお目にかかれません。

$ cat main.cgo2.c #line 2 “(…)/src/main.go”

void _cgo_32105cabc2a6_Cfunc_Run(void *v) { struct { App p0; } attribute((packed, gcc_struct)) *a = v; Run(a->p0); } ```

で、この生成された main.cgo2.c をgccでコンパイルするときのオプションは #cgo CFLAGS で指定したものも使われるので、ここで -x c++ を指定してしまうと、このCファイルがC++としてコンパイルされてしまい、リンケージがC++になってしまうわけです。ついでにいうと、C++的にはよくないキャストが含まれているので、-fpermissiveを指定しないとコンパイルが通りません。

ということで、これを実行するとこんな感じになります。

$ go run main.go
# command-line-arguments
./echo_client.go: In function ‘void _cgo_32105cabc2a6_Cfunc_CreateApp(void*)’:
./echo_client.go:36:53: warning: invalid conversion from ‘void*’ to ‘_cgo_32105cabc2a6_Cfunc_PrepareApp(void*)::<anonymous struct>*’ [-fpermissive]

                                                     ^
./echo_client.go: In function ‘void _cgo_32105cabc2a6_Cfunc_Run(void*)’:
./echo_client.go:46:53: warning: invalid conversion from ‘void*’ to ‘_cgo_32105cabc2a6_Cfunc_Run(void*)::<anonymous struct>*’ [-fpermissive]

                                                     ^
# command-line-arguments
/var/tmp/go-link-sVLoaz/go.o: In function `main._Cfunc_Run':
(.text+0x39a): undefined reference to `_cgo_32105cabc2a6_Cfunc_Run'
collect2: error: ld returned 1 exit status
/usr/local/go/pkg/tool/linux_amd64/6l: running gcc failed: unsuccessful exit status 0x100

いやいや、ちゃんと自動生成したCソースに _cgo_32105cabc2a6_Cfunc_Run あるしそれエラーになるわけないじゃない…と昨日1日ずーっと悩みました。で今朝電車でゆらゆらしながらずーっと考えてたんですが、よく考えたらcgoのCFLAGS指定はすべてのgcc呼び出しに付加されているので、自動生成したソースコードをC++としてコンパイルさせてしまっていたのでした。そりゃリンケージがC++になるからメソッド見つからなくなるわ! という話ですね。

では、最初になぜ -x c++ -fpermissive をつけてドツボにハマリにいってしまったかというと、ヘッダにcgoのヘッダ部分に extern "C" を書いてその状態でコンパイルが通る様にするためだったんですね。Cコンパイラは extern "C" を解釈できません。ということは、CじゃなくてC++としてコンパイルしないとダメなんだなーということでcgoディレクティブを追加したのですが、そもそもcgoの吐くソースはCとしてコンパイルしないとダメなので、これは筋が悪かったというところです。

ではどうすればよかったというと、 bridge.h で extern "C" するのをちゃんと #ifdef __cplusplus のときだけに絞るという、当たり前のことを当たり前のようにやればよい、ということでした。

$ cat bridge.h
<code class="cpp">#ifdef __cplusplus
extern "C" {
#endif

typedef void* App;
App CreateApp();
void Run(App);

#ifdef __cplusplus
}
#endif
</code>```

ということで、今日はGoがcgoを使ってネイティブコンパイルするときの流れと、指定すると絶対失敗するのでやめたほうがよい `CFLAGS` のオプションについてご紹介しました。ここ2日くらいこれが解決する気配なくて本当につらかった…。