🎬 🧘 👼🏽 Goでのクロスコンパイル 🧑🏿‍🤝‍🧑🏼 🏨 🥃

クロスプラットフォームは、ほぼすべての最新の言語およびライブラリの実質的に標準的な属性になっていますが、真のクロスプラットフォーム製品を作成することはまだ容易ではありませんでした。コンパイルされた言語と関連ライブラリーには、ビルド環境とライブラリーの複雑なインストールと構成が必要であり、インタープリター言語には、インタープリターの必要なバージョンの存在またはデプロイメントが必要でした。このプロセスを少し単純化しようとする多くのプロジェクトがありますが、多くの場合、唯一の解決策は別個のサーバーをインストールしてネイティブにコンパイルすることでした。

Goで、クロスプラットフォームは、コンパイルファーム、特別に構成された開発環境、アセンブリ用の仮想マシン、またはchroot / docker-devソリューションを初めて安全に放棄できるレベルに達しました。そして、これはもう一つの重大なゲームチェンジャーです。これについて、例を挙げて話をして、見せたい

行こう

ご存知のように、Goは動的リンクを意図的に拒否しました-その主な理由は、Goのほぼすべての側面の設計に関する通常の説明と非常によく似ています-「[動的リンク]の利点は、その欠点とアーキテクチャにもたらす複雑さよりもはるかに少ないです」さて、動的リンクの出現の主な理由は、リソースだけでなく、主にディスクスペースとメモリを節約したいという欲求でした。これは、サーバーだけでなく、組み込みデバイス（ヘリコプター、 GB RAM！）。一般に、個別のリンク方法の長所と短所をリストすると、別の投稿に移動するため、現時点ではそのまま受け入れます。Goでは、出力に常に静的バイナリがあります。

現在、Go 1.4.1の現在のバージョンでは、次のプラットフォームがサポートされています。

Linux 2.6 ¹以降-amd64、386、arm
MacOS X 10.6以降-amd64,386
Windows XP以降 -amd64、386
FreeBSD 8以降-amd64、386、arm
NetBSD -amd64、386、アーム
OpenBSD -amd64、386
DragonFly BSD -amd64、386
プラン9 -amd64、386
Google Native Client -amd64p32、386
Android-アーム

^1-カーネル2.6.23以降は公式にサポートされていますが、実際にはすべてがブランチ2.6の以前のカーネルで動作します-たとえば、多くの人が2.6.18のRHEL5 / CentOS5でGoを使用しています。

Go 1.5 は iOS をサポートする予定です。

また、最初はGoでWindowsがサポートされていなかったことも注目に値します-チームは小さく、Windowsのコード実装を手に入れる人はいませんでしたが、オープンソース開発のためにプロジェクトが開かれたおかげで、Windowsの移植はサードパーティの人々によって非常に迅速に書かれ、統合されました公式のコードベースに。

以下で説明するプロセスはすべてのプラットフォームで完全に同一ですが（Androidおよびネイティブクライアント（NaCl）は例外で、追加のジェスチャーが必要です）、この記事の残りの部分では、最も人気のある3つのデスクトップのいずれかを使用していると想定しますプラットフォーム-Linux、MacOS XまたはWindows。さらに、より簡単にするために、Cライブラリにリンクする必要がない（したがって、cgo / gccを使用する必要がない）Goコードのみを記述して使用することを意味します。別のケースもあります-cgoに関連付けられた標準ライブラリの多数の関数を使用する必要がある場合ですが、これについては最後の別の章で説明します。

ツールチェーンの準備

実行する必要がある最初のステップは、目的のプラットフォーム用のツールチェーンを構築することです。

Goソースコード（$ GOROOT / src、常にマシン上にあります）を使用してディレクトリに移動し、Windows / amd64などの目的のプラットフォーム用に再構築します。

cd $(go env GOROOT)/src sudo GOOS=windows GOARCH=amd64 CGO_ENABLED=0 ./make.bash --no-clean

このプロセスは、Macbook Air 2012では約26秒かかります。 make.bashスクリプトは、ソースからインストールする場合にGoをインストールする標準のGoビルドスクリプトです。実際には、Goと標準ライブラリ全体を収集しますが、今回のみ-windows / amd64プラットフォーム用です。

また、上記の理由により、CGOサポートを無効にしました。

GOOSおよびGOARCH値

値のテーブルGOOS（Habréで50％の幅でテーブルを作成する方法を知っている場合-教えてください）：

OS	$ GOOS
Linux	Linux
MacOS x	ダーウィン
窓	窓
Freebsd	freebsd
Netbsd	netbsd
Openbsd	openbsd
DragonFly BSD	トンボ
計画9	plan9
ネイティブクライアント	ナックル
Android	アンドロイド

そしてGOARCH：

建築	$ GOARCH
x386	386
AMD64	amd64
32個のポインターを備えたAMD64	amd64p32
腕	腕

例1. Linux for Windowsで作成およびコンパイルされたWebサーバー

コマンドラインを解析するために、いくつかの言語/ライブラリよりもGoで作成する方が簡単な単純なWebサーバーを作成します。

 package main import ( "log" "net/http" ) func Handler(w http.ResponseWriter, r *http.Request) { w.Write([]byte("Hello, world\n")) } func main() { http.HandleFunc("/", Handler) log.Println("Starting HTTP server on :1234") log.Fatal(http.ListenAndServe(":1234", nil)) }

そして、32ビット版と64ビット版のWindows用にまとめます。

 GOOS=windows GOARCH=386 go build -o http_example.exe GOOS=windows GOARCH=amd64 go build -o http_example64.exe

私たちはチェックします：

 $ file http_example*.exe http_example.exe: PE32 executable for MS Windows (console) Intel 80386 32-bit http_example64.exe: PE32+ executable for MS Windows (console) Mono/.Net assembly

両方のバイナリがターゲットWindowsシステムにコピーする準備ができており、動作するということを言う必要はないと思います。

例2. Nokia N9電話のARMでのクロスコンパイル

すぐに組み込みデバイスと密接に連携していないと言いますので、詳細はわからないかもしれません。したがって、このトピックを掘り下げないように努めますが、一般的には埋め込みオンの状況に従います。一般的に、Goは組み込みプラットフォーム用の言語として位置付けられていませんでしたが、この領域でGoを積極的に使用し始めることを妨げるものではありませんでした。おそらくその理由は、組み込み業界が飛躍を遂げたため、「組み込み」デバイスはもはや非常に少ないリソースを意味せず、Goでメモリを節約することを支持しないトレードオフは、実際にはあまり具体的ではないことが判明しましたが、実際には- Goは既にGobot （Arduino、Raspberry PI、BeagleboneからLeapMotion、Pebble、ArDroneまでのプラットフォーム全体のロボットフレームワーク）やEMBD（ホビーボードを操作するためのフレームワーク）などの多くのプロジェクトを作成しており、PayPal は数年間使用していますワイヤレスの小切手と支払いのためにビーコンデバイスに移動します。

たとえば、Nokia N9（またはラッキーなN950）を使用して、上記の例を収集します。

 GOOS=linux GOARCH=arm go build -o http_example_arm scp http_example_arm developer@192.168.2.16:/home/user/

はい、とても簡単です。

実際、ARMプラットフォームの場合、GOARMフラグを指定する必要がありますが、ここで、バージョンがデフォルトで適合しない場合、ターゲットプラットフォーム上のバイナリは次のような明確なメッセージを表示します。

 runtime: this CPU has no floating point hardware, so it cannot run this GOARM=7 binary. Recompile using GOARM=5.

プロセスを自動化する

ビルドに進む前に単一の変数を指定する方が簡単かもしれません。ただし、コードを収集して1日100回異なるプラットフォームにデプロイする必要がある場合があります。そのようなタスクには、ツールチェーンの準備プロセスを自動化し、目的のプラットフォームのコードを直接組み立てるためのプロジェクトがいくつかあります。

ゴックス

リンク： github.com/mitchellh/gox

すべての可能なツールチェーンのインストールと準備を一度に：

 go get github.com/mitchellh/gox gox -build-toolchain ...

今、「go build」の代わりに、「gox」を書きます。

 $ gox Number of parallel builds: 4 --> darwin/386: github.com/mitchellh/gox --> darwin/amd64: github.com/mitchellh/gox --> linux/386: github.com/mitchellh/gox --> linux/amd64: github.com/mitchellh/gox --> linux/arm: github.com/mitchellh/gox --> freebsd/386: github.com/mitchellh/gox --> freebsd/amd64: github.com/mitchellh/gox --> openbsd/386: github.com/mitchellh/gox --> openbsd/amd64: github.com/mitchellh/gox --> windows/386: github.com/mitchellh/gox --> windows/amd64: github.com/mitchellh/gox --> freebsd/arm: github.com/mitchellh/gox --> netbsd/386: github.com/mitchellh/gox --> netbsd/amd64: github.com/mitchellh/gox --> netbsd/arm: github.com/mitchellh/gox --> plan9/386: github.com/mitchellh/gox

特定のパッケージまたは特定のプラットフォームを指定できます。

 gox -os="linux" gox -osarch="linux/amd64" gox github.com/divan/gorilla-xmlrpc/xml

残りのコマンドライン引数は、go buildと同じです。直観的です。

Gocx

GoCXは、クロスコンパイル機能の最も有名なラッパーの1つですが、パッケージ化（.debを実行することもできます）および自動アセンブリ用のさまざまなバンに重点を置いています。私は自分で使用しなかったので、興味がある人はサイトとドキュメントをご覧ください。

github.com/laher/goxc

CGOを理解する

デンバーで開催されたGopherCon 2014カンファレンスのビデオを見た人は、おそらくAlan Shreveの「Goで開発ツールを構築する」という話を覚えているでしょう。 -コンパイル、ネイティブにコンパイルします。 " 次は説明です-理由はCgoです。 cgoを使用する必要がない場合は、すべて問題ありません。実際、特定のGoコードのごく一部にサードパーティのCライブラリが必要です。問題は何ですか？

問題は、標準ライブラリの一部の機能がcgoに依存していることです。つまり、GoをCGO_ENABLED = 0で収集すると、それらは単に使用できなくなり、コンパイル段階でエラーが発生します。非常に便利で美しい回避策があるという事実にもかかわらず、標準ライブラリの内容がcgoにどのように依存しているかを見てみましょう。

幸いなことに、これは簡単です。

 # cd $(go env GOROOT)/src/ # grep -re "^// +build.*[^\!]cgo" * crypto/x509/root_cgo_darwin.go:// +build cgo net/cgo_android.go:// +build cgo,!netgo net/cgo_linux.go:// +build !android,cgo,!netgo net/cgo_netbsd.go:// +build cgo,!netgo net/cgo_openbsd.go:// +build cgo,!netgo net/cgo_unix_test.go:// +build cgo,!netgo os/user/lookup_unix.go:// +build cgo runtime/crash_cgo_test.go:// +build cgo

これらのファイルについて簡単に説明します。

crypto / x509 / root_cgo_darwin.go -MacOS XでルートX.509証明書を取得するための1つの関数を実装します。この機能を明示的に使用しない場合-cgoがなくても問題はありません。
net / cgo_android / linux / netbsd / openbsd / cgo_unix_test.go-異なるUNIXでネイティブDNSリゾルバーを使用するために必要なコード。以下の詳細。
os / user / lookup_unix.go -os / userパッケージの関数-現在のユーザーに関する情報（uid、gid、username）を取得します。 passwdエントリを読み取るためにgetpwuid_r （）によって使用されます
runtime / crash_cgo_test.go-フックを処理するためのテストを含むファイル、関連性なし

次に、DNSリゾルバについて詳しく説明します。

そのリストの各ファイル（// +ビルドタグのおかげでプラットフォーム用にのみコンパイルされます）には、単一の関数cgoAddrInfoFlags（）の実装が含まれています。これは、次にdnsclient_unix.goで使用されるcgoLookupIP（）で使用されますgoLookupIP（）関数を見つけます。これは、cgo対応コードがない場合のフォールバックオプションとして機能し、説明を見つけます。

// goLookupIPはLookupIPのネイティブGo実装です。

// cgoLookupIPがリクエストの処理を拒否する場合にのみ使用

//（つまり、cgoLookupIPがcgo_stub.goのスタブである場合のみ）。

//通常、cgoにCライブラリリゾルバを使用させます

//ルックアップコードに応じて、GoとCが同じになるようにします

//答えます。

goLookupIPは、実際にはHostsファイルとDNSプロトコルでのみ解決します。これはほとんどのシステムで約です。ただし、システムで名前を解決する非標準の方法が使用されている場合、問題が発生する可能性があります。 99％のケースでは、ホストとDNSで十分すぎると思います。

一番下の行は-コードがC / C ++を使用しない場合-Cgoを介したライブラリであり、次の2つのことを使用しません。

MacOS Xで動作するx.509証明書の検証
現在のユーザーに関するシステム情報の受信が保証されています

そうすれば 、Cgoのトラブルをすべて記録できます 。

最初の部分（X.509から）は実際にはそれほど珍しくありません。私が正しく理解している場合-プログラムが標準のnet / http.StartAndListenTLS（）を使用している場合、このコードが必要です-そして実際に検証する必要がある実際の証明書を使用します。

したがって、このトピックに関する簡単な回避策について簡単に説明します-gonativeと呼ばれ、1つの簡単なこと-目的のプラットフォームのgolangの公式バージョンのバイナリバージョンをダウンロードします。そこには、すべての標準パッケージのコンパイル済みバイナリが既に存在し、実際には「ツールチェーンの構築」プロセスを完了しますcgoコードで。」

必要なのは、それをインストールして（github.com/inconshreveable/gonativeを取得）、1つの簡単なコマンドを実行することだけです：

 gonative

さらに、以前と同様に、ハンドルを使用するかgox / gocxを使用して、標準のクロスコンパイル手順を使用します。

gonativeについて詳しくは、inconshreveable.com / 04-30-2014 / cross-compiling-golang-programs-with-native-librariesをご覧ください。

実用化

ここで主なことについて-それを実践する。これまでに本番環境で使用したスキームは、「darwin / amd64でビルド-> linux / 386にデプロイ」、「linux / amd64-> linux / 386」、「linux / amd64-> windows / amd64」の3つだけです。これらは、1年以上完全に機能している製品です。 3番目のケース（Windowsでの展開）は、一般的に驚いた。Linuxで正常に実行されているサーバーがあり、その後突然Windowsで実行する必要が生じた。さらに、「緊急に必要」。クロスでの眠れない夜の経験を覚えています-はい、Windowsでの展開のためのQtコンパイルだけで何がありますか-60秒間のプロセス「これを行う方法→ツールチェーンを構築→プロジェクトを再コンパイル→Windowsに展開」-ショックでした私は自分の目を信じられませんでした。

しかし、ここで次の瞬間が発生します-クロスコンパイルと展開が非常に簡単かつ高速になるため、構成ファイル、証明書、その他のファイルに依存してバイナリに埋め込むインセンティブがあります。ただし、これはio.Readerインターフェイスとgo-bindataパッケージの効率的な使用のおかげで、サードパーティのライブラリでもかなり簡単なタスクですが、これは別の記事のトピックです。

主なものを見逃していないことを願っています。

しかし、全体的に、これは実際には以前のすべてのクロスビルドの経験と非常に大きな違いです。正直に言うと、私はまだこの変更に慣れていません。開発環境が構成された仮想マシンは不要になり、アセンブリにドッカーイメージは不要になりました。一般的に、開発環境はそのままでは消えません。これはゲームチェンジャーとしてはあまりにも鋭すぎてすぐに慣れることができません。

参照資料

dave.cheney.net/2012/09/08/an-introduction-to-cross-compilation-with-go

blog.hashbangbash.com/2014/04/linking-golang-statically

www.limitlessfx.com/cross-compile-golang-app-for-windows-from-linux.html

Goでのクロスコンパイル