Rustでクロスコンパイル
x86_64-unknown-linux-gnuのホスト環境上で、CHIP向けのバイナリをRustでクロスコンパイルすることを目的とする。
概要
rustup target add ${target_triple}でターゲットのツールチェインを追加- ターゲットのリンカをインストール
- Cargoのconfigファイルにターゲット用のリンカ設定を記述
cargo build --target ${target_triple}でクロスコンパイル実行
※Rustのツールチェイン管理を行ってくれるツールのrustupはこちらを参考にインストール済みとする。
環境
ホストのシステム情報。
$ uname -a Linux hostname 4.13.7-1-ARCH #1 SMP PREEMPT Sat Oct 14 20:13:26 CEST 2017 x86_64 GNU/Linux $ rustup show Default host: x86_64-unknown-linux-gnu 1.21.0-x86_64-unknown-linux-gnu (default) rustc 1.21.0 (3b72af97e 2017-10-09)
ターゲットであるCHIPのシステム情報。
chip@chip:~$ uname -a Linux chip 4.4.13-ntc-mlc #1 SMP Thu Nov 3 01:28:54 UTC 2016 armv7l GNU/Linux
ターゲットのツールチェインを追加
rustup target listで、Rustがサポートするターゲットのリストを確認する。
$ rustup target list | pr -w 90 --columns=2 aarch64-apple-ios mips-unknown-linux-gnu aarch64-linux-android mips-unknown-linux-musl aarch64-unknown-fuchsia mips64-unknown-linux-gnuabi64 aarch64-unknown-linux-gnu mips64el-unknown-linux-gnuabi64 arm-linux-androideabi mipsel-unknown-linux-gnu arm-unknown-linux-gnueabi mipsel-unknown-linux-musl arm-unknown-linux-gnueabihf powerpc-unknown-linux-gnu arm-unknown-linux-musleabi powerpc64-unknown-linux-gnu arm-unknown-linux-musleabihf powerpc64le-unknown-linux-gnu armv7-apple-ios s390x-unknown-linux-gnu armv7-linux-androideabi sparc64-unknown-linux-gnu armv7-unknown-linux-gnueabihf wasm32-unknown-emscripten armv7-unknown-linux-musleabihf x86_64-apple-darwin armv7s-apple-ios x86_64-apple-ios asmjs-unknown-emscripten x86_64-linux-android i386-apple-ios x86_64-pc-windows-gnu i586-pc-windows-msvc x86_64-pc-windows-msvc i586-unknown-linux-gnu x86_64-rumprun-netbsd i686-apple-darwin x86_64-unknown-freebsd i686-linux-android x86_64-unknown-fuchsia i686-pc-windows-gnu x86_64-unknown-linux-gnu (default) i686-pc-windows-msvc x86_64-unknown-linux-musl i686-unknown-freebsd x86_64-unknown-netbsd i686-unknown-linux-gnu x86_64-unknown-redox i686-unknown-linux-musl
armv7-unknown-linux-gnueabihfが見つかり、RustはCHIPのターゲットをサポートしていることを確認できたため、以下のコマンドでCHIP用のツールチェインを追加する。
$ rustup target add armv7-unknown-linux-gnueabihf
rustup target add後にrustup showやrustup target listを実行してRustのツールチェインの状態を確認すると、armv7-unknown-linux-gnueabihfが(installed)になっているのがわかる。
$ rustup show Default host: x86_64-unknown-linux-gnu installed targets for active toolchain -------------------------------------- armv7-unknown-linux-gnueabihf x86_64-unknown-linux-gnu active toolchain ---------------- 1.21.0-x86_64-unknown-linux-gnu (default) rustc 1.21.0 (3b72af97e 2017-10-09) $ rustup target list | pr -w 90 --columns=2 aarch64-apple-ios i686-unknown-linux-musl aarch64-linux-android mips-unknown-linux-gnu aarch64-unknown-fuchsia mips-unknown-linux-musl aarch64-unknown-linux-gnu mips64-unknown-linux-gnuabi64 arm-linux-androideabi mips64el-unknown-linux-gnuabi64 arm-unknown-linux-gnueabi mipsel-unknown-linux-gnu arm-unknown-linux-gnueabihf mipsel-unknown-linux-musl arm-unknown-linux-musleabi powerpc-unknown-linux-gnu arm-unknown-linux-musleabihf powerpc64-unknown-linux-gnu armv7-apple-ios powerpc64le-unknown-linux-gnu armv7-linux-androideabi s390x-unknown-linux-gnu armv7-unknown-linux-gnueabihf (installed) sparc64-unknown-linux-gnu armv7-unknown-linux-musleabihf wasm32-unknown-emscripten armv7s-apple-ios x86_64-apple-darwin asmjs-unknown-emscripten x86_64-apple-ios i386-apple-ios x86_64-linux-android i586-pc-windows-msvc x86_64-pc-windows-gnu i586-unknown-linux-gnu x86_64-pc-windows-msvc i686-apple-darwin x86_64-rumprun-netbsd i686-linux-android x86_64-unknown-freebsd i686-pc-windows-gnu x86_64-unknown-fuchsia i686-pc-windows-msvc x86_64-unknown-linux-gnu (default) i686-unknown-freebsd x86_64-unknown-linux-musl i686-unknown-linux-gnu x86_64-unknown-netbsd
ターゲットのリンカをインストール
Rustのツールチェインではターゲットのリンカはサポートしていないため、別途用意する。
$ apt-get install gcc-arm-linux-gnueabihf
Cargoのconfigにターゲットのリンカ設定を記述
クロスコンパイルする対象とするプロジェクトを生成する。
$ cargo new --bin hello
Cargoが生成したスケルトンコードのままで実行すると、Hello, world!が標準出力に出力される。
$ cargo run
Compiling hello v0.1.0 (file:///host_shared/hello)
Finished dev [unoptimized + debuginfo] target(s) in 0.44 secs
Running `target/debug/hello`
Hello, world!
これをそのままターゲット(CHIP)上で動作するようにするために、プロジェクトのconfigファイルを作成し、ターゲットのリンカの設定を記述する。
$ mkdir .cargo $ cat > .cargo/config << EOF > [target.armv7-unknown-linux-gnueabihf] > linker = "arm-linux-gnueabihf-gcc" > EOF
クロスコンパイル実行
$ cargo build --target armv7-unknown-linux-gnueabihf
ビルドされたバイナリの情報を確認すると、ターゲット(CHIP)向けのバイナリになっていることがわかる。
$ file target/armv7-unknown-linux-gnueabihf/debug/hello target/armv7-unknown-linux-gnueabihf/debug/hello: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=70dfb01aa67d797fc64005ac8cff1dba94a48a34, not stripped $ readelf -A target/armv7-unknown-linux-gnueabihf/debug/hello Attribute Section: aeabi File Attributes Tag_CPU_name: "7-A" Tag_CPU_arch: v7 Tag_CPU_arch_profile: Application Tag_ARM_ISA_use: Yes Tag_THUMB_ISA_use: Thumb-2 Tag_FP_arch: VFPv3-D16 Tag_ABI_PCS_GOT_use: GOT-indirect Tag_ABI_PCS_wchar_t: 4 Tag_ABI_FP_rounding: Needed Tag_ABI_FP_denormal: Needed Tag_ABI_FP_exceptions: Needed Tag_ABI_FP_number_model: IEEE 754 Tag_ABI_align_needed: 8-byte Tag_ABI_enum_size: int Tag_ABI_VFP_args: VFP registers Tag_CPU_unaligned_access: v6 Tag_ABI_FP_16bit_format: IEEE 754
クロスコンパイルしたバイナリをターゲット上で実行
chip@chip:~$ ./hello Hello, world!
ターゲット(CHIP)上で実行できることが確認できた。
参考
Rustでのクロスコンパイルに必要な情報が、以下のページに非常にわかりやすく説明されている。
japaric/rust-cross: Everything you need to know about cross compiling Rust programs!
環境構築の検証用にDockerを使う
Rustのクロスコンパイル環境構築の検証にDockerを使い始めた。
開発環境を構築する際、最初は試行錯誤しながら行なうため、さぁ環境が構築ができた、となった時に行なってきた手順のどれが最低限必要なものだったのかがわからなくなることが多い。 必要だと思ってインストールしたものが実は必要なかったり、必要ないと思ったものに実は依存していたりするため、手順に再現性があるのかどうかを検証したくなる。
このようなケースにおいて、いつでもクリーンな環境から手順の確認ができるDockerが非常に便利だったので、以下にRustの開発環境をDockerで立ち上げるまでにやったことをメモとして残しておく。
$ docker --version Docker version 17.10.0-ce, build f4ffd2511c
Docker HubでRustがインストールされたDockerイメージが公開されているのでpullする。
$ docker pull rust
Rustのイメージが取得できたことを確認する。
$ docker images REPOSITORY TAG IMAGE ID CREATED SIZE rust latest 9578919665db 7 days ago 1.33GB
RustのDockerイメージからコンテナを起動する。
$ docker run -i -t -v ${host_dir_path}:${container_dir_path} --rm rust
docker runのオプションの意味は以下を参照。
-i: 標準入力を有効にする-t: 疑似ターミナルを割り当てる-v ${host_dir_path}:${container_dir_path}: ホストとコンテナの共有ディレクトリを指定する--rm: コンテナからExitした時に自動的にコンテナを削除する
共有ディレクトリを指定しているのは、ホストで書いたコードをコンテナ内でビルドし、コンテナでビルドしたファイルをホストから参照するのを容易にするため。
Target Triple
Rustのコンパイラのソースコードの中で使用されていた"Triple"という言葉の意味がわからなかったので調べた。
Target Triplets describe a platform on which code runs and are a core concept in the GNU build system. They contain three fields: the name of the CPU family/model, the vendor, and the operating system name.
サポートするターゲットを表す表現方法を Target Triple と呼んでいる。
ターゲットの指定が以下の3つのフィールドから成っていることが、Tripleと呼ぶ理由らしい。
- CPU family/model
- Vendor
- OS
具体例としては、以下のようなターゲット指定が挙げられる。（よく見るやつ）
なお、clangのドキュメントでは以下のようにフィールド指定が定義されている。
Cross-compilation using Clang
The triple has the general format
<arch><sub>-<vendor>-<sys>-<abi>, where:
Arch Linux上にRe:VIEWをインストールする
書籍執筆支援システムRe:VIEWの環境構築のメモ。
依存パッケージのインストール
Re:VIEWを使うために必要なパッケージをインストールする。
$ sudo pacman -S ruby ruby-rubyzip texlive-most texlive-langjapanese poppler-data
dvipdfmxのフォントのエラー対策
Re:VIEWからpdfを生成する際(後述のreview-pdfmaker実行時)にデータに日本語を含んでいると、以下のエラーが出る場合がある。
kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 2+180/600 --dpi 1380 uphgothr-h mktexpk: don't know how to create bitmap font for uphgothr-h. mktexpk: perhaps uphgothr-h is missing from the map file. kpathsea: Appending font creation commands to missfont.log. dvipdfmx:warning: Could not locate a virtual/physical font for TFM "uphgothr-h". dvipdfmx:warning: >> There are no valid font mapping entry for this font. dvipdfmx:warning: >> Font file name "uphgothr-h" was assumed but failed to locate that font. dvipdfmx:fatal: Cannot proceed without .vf or "physical" font for PDF output...
対策として、/etc/texmf/dvipdfmx/dvipdfmx.cfgを編集する。
%% Put additional fontmap files here (usually for Type0 fonts) f cid-x.map
上記変更を反映するために以下を実行する。
$ sudo updmap-sys $ sudo texconfig rehash $ updmap $ texconfig rehash
Re:VIEWのインストール
AURにあるRe:VIEWパッケージは若干古いようなので、gitからインストールする。
$ git clone https://github.com/kmuto/review.git
clone後、展開されたreview/bin/にPATHを通す。
始め方
$ review-init ${document_name}
${document_name}/以下に${document_name}.reが生成されているので、これを編集する。
各フォーマットで出力する
- PDF出力
$ review-pdfmaker config.yml - EPUB出力
$ review-epubmaker config.yml - HTML出力
$ review-epubmaker config.yml
参考
vim-plug: プラグインがインストール済みかどうかを判定する
追記: 以下の記事にfunction! s:plug.is_installed(name)としてプラグインの存在確認方法が載っていました。
おい、NeoBundle もいいけど vim-plug 使えよ by @b4b4r07 on @Qiita
例として、プラグインの存在確認をするための関数を定義してみます。vim-plug ではプラグインのリストがグローバル変数 g:plugs に辞書として格納されているので、これをうまく利用します。
vim-plugはVimのプラグインマネージャー。
今回、NeoBundleからvim-plugへ乗り換えたので、その時にしたことをメモ。
vim-plugにはNeoBundleのneobundle#is_installed({bundle-name})に相当する関数がないため、プラグイン依存の設定をvimrcに書きたいときに少し不便。
そこで、以下のような関数is_plugged({plugin-name})を書いて、プラグインがインストール済みかどうかを判定する。
" check the specified plugin is installed
function s:is_plugged(name)
if exists('g:plugs') && has_key(g:plugs, a:name) && isdirectory(g:plugs[a:name].dir)
return 1
else
return 0
endif
endfunction
以下のように、neobundle#is_installed({bundle-name})と同じように使用できる。
" w3m plugin setting
if s:is_plugged("w3m.vim")
let g:w3m#external_browser = 'open'
let g:w3m#download_ext = [ 'zip', 'lzh', 'cab', 'tar', 'gz', 'z', 'exe' ]
let g:w3m#search_engine = 'http://www.google.co.jp/search?ie=' . &encoding . '&q=%s'
nmap <Space>w :W3m
endif
" vim-go plugin setting
if s:is_plugged("vim-go")
let g:go_bin_path = expand("~/.vim-go")
endif
