Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
16
Help us understand the problem. What is going on with this article?
@kjunichi

Dockerを使ってクロスコンパイルしてmrubyのワンバイナリを作成してみた

More than 5 years have passed since last update.

背景

普段はOSXやLinuxを好んで使っています。しかし、2,3万円台で買えるWindowsノートPCも魅力的で、実際、
奥さんに内緒で買って使ってます。ちょっと前に次男にコーンポタージュをこぼされて壊れてしまい、
今のは2台目になります。。

そんな環境なので自作のプログラムがOSX,Linux,Windowsで動いてくれると、いろいろ便利だと思っています。

ただ、特に2,3万のPCでは非力なので、出来ればどこか別のPCでビルドを行い、
微調整だけ非力なPCで行えれば、激安ノートPCやWindowsタブレットにVSやMingwを入れずに済みます。
(Cygwinはh2oを動かすために外せませんw)

それにできれば、開発環境を入れるPCは限定して、そこで一括してビル出来るような環境が嬉しいです。

Go言語ではクロスコンパイルしてワンバイナリが出来る

以下の記事が最近の事情を反映しており参考なる。自分が試したのは1.4以前であったが、gox使ってOSXでWindowsやLinux向けのバイナリが作れるのに感動した。

mrubyでもmruby-cli使えばクロスコンパイルしてワンバイナリが出来る

  • gccはLinuxやOSX、Windows、その他多くのプラットフォームで動く
  • 各OS上で自分のプラットフォーム向け以外のコードも比較的容易に吐けるのかも
  • Linux上で、WindowsやOSX向けのバイナリを吐けるクロスコンパイル可能なgccの処理系が既に存在している

ということで、DockerでLinux上のLinux以外のコードを吐けるクロスコンパイル可能なgccの処理系を詰め込むことで
これを実現している便利ツールがmruby-cliということになりそうです。

mruby-cli自体のビルドもdocker-composeを使って可能で、以下の手順で、
mruby/buildディレクトリ配下に、Linux,Windows,OSXの各種バイナリが出来ます。

git clone https://github.com/hone/mruby-cli
cd mruby-cli
docker-compose run compile

mruby-cliで参考になりそうな日本語記事

問題

外部のC/C++のライブラリを使うようなケースへの対応

以下の記事を読む限り、Goの場合、cgoを使う必要があり、クロスコンパイルするには、ターゲット向けのバイナリを吐けるgccを自前で用意するっぽい。

mrubyの場合も、mruby-cliを素の状態では難しいが、goに比べて、すでにLinux,Windows,OSXの3環境向けの
gccが入っているので、手間いらず。

mrubyに組み込みたいCライブラリとそのライブラリに依存するライブラリ全てを
Linux以外のWindows,OSXの2環境分頑張ってクロスコンパイル可能にして、lib*.aの形式でライブラリを
揃えれば出来るはず!

本題

そんな訳で、Raspberry Pi2ではなく、Raspberry Piを持っているのにクロスコンパイルしたことのない自分が
無謀にもC++ライブラリを使っているmrbgemをDockerを使って、Windows向けのmrubyに組み込んだワンバイナリを
作成することにした。

mruby-mrmagickをWindowsでうごかす

いきなり、mruby-cliに組み込むのは、mruby-cliの構造の理解も必要で大変そうだったので、
とりあえず、Dockerのコンテナ上でWindowsのバイナリを吐けるgccの処理系を動かして、自分の作っている
ImageMgaickライブラリに依存したmruby-mrmagickDockerでクロスコンパイルしてWindows向けの
バイナリを生成して、これを動かそうと試みた。

また、対象も前述の激安のWindowsが32ビットのため、32ビットのWinodwos向けに絞ってやってみることにした。

下準備

まさにこの記事を書いている時に気が付きましたが、mruby-cliで使用しているDockerイメージを使えば良かったのですが

こんなの作って、このコンテナ内で試行錯誤してました。

クロスコンパイルの基礎

./configureなコードは簡単にクロスコンパイル出来ることが多い模様。
--hostオプションでビルド対象のプラットフォームを指定すれば、よきに計らってくれることが多い感じです。
実際、ImageMagickで依存するjpegやpngのライブラリもこの指定プラスアルファ程度でビルド出来ました。

mrubyをDockerのLinux上でクロスコンパイルしてWindows向けのバイナリを作る

通常のbuild_config.rbの末尾に以下のような記述をすることで、出来ました。
この例ではWindowsの32ビット向けの設定になります。

MRuby::CrossBuild.new('i686-w64-migw') do |conf|
  toolchain :gcc  
  conf.cc do |cc|
    cc.command = "/usr/bin/i686-w64-mingw32-gcc"
  end
  conf.linker do |linker|
    linker.command = "/usr/bin/i686-w64-mingw32-gcc"
  end 

  conf.archiver do |archiver|
    archiver.command = "/usr/bin/i686-w64-mingw32-ar"
  end
  conf.gem :github => 'kjunichi/mruby-mrmagick'
  conf.gembox 'default'  
end

結果

ImageMagick本体をクロスコンパイルしてビルドする際に、いくつかコンパイルエラーが発生し、これらに対応して、
無事lib*.a形式でライブラリが作成され、convert.exe等も出来ました。

しかし、どうも自分がWindows向けのクロスコンパイルを通すために当てたパッチが原因の可能性が高そうではあるのですが。画像ファイルを読み込もうとすると落ちます。。

こんな感じで画像ファイルを開いた瞬間に落ちる。。

convert.exeなども、--help等は動くが、画像を開くと即死という状態。

失敗したが作業を通じて学べたこと

クロスコンパイルする場合にもホスト向けのmrubyが必要

mrbcで.rbファイルをコンパイルしてバイトコードを生成して、
これをターゲット先のmrubyに組み込む為、ホスト上で動くmrubyが必要な
ようです。

ただし、当然、ホストで動かすmrubyの構成は最小構成で良いので、
クロスコンパイル先で使いたいmrbgemsの指定はクロスコンパイルのセクション内に
書くだけで良いようです。

gcc(mingw32-w64)で明示的に静的リンクを指定するには

まぁ、クロスコンパイルやろうとする方なら何を今更といった感もありますが、
前述の通りのヘタレな自分は今回の作業で初めて知りました。

-Wl,-dn,-lhoge

これで、Windowsマシンで作成されたバイナリをもっていって
hode-N.dllが見つかりませんいった自体を避けられました。

nmコマンドもクロスコンパイル用のものが用意されていた

特こ今回の様に静的リンクを行うと、エラーが出やすい気がする、シンボル参照エラーの
調査にクロスコンパイル用のi686-w64-mingw32-nmコマンドもあり、助けられている。

lddコマンドはobjdump -p

lddコマンドは検索するとクロスコンパイル環境でも環境によって存在しているようだが、
今回のmingw32-w64環境下では無かった。代わりに、i686-w64-mingw32-objdumpコマンドを-pオプション付で
実行することで、同様の情報が得られた。

OpenMPを使った場合、静的リンクはできなくなりつつある模様

詳しくは以下

ImageMagickがダメならOpenCVは?

OpenCVつかってmrubyでwebcam動かせるモジュール作成して、
これを試そう!

OpenCVは実績あり

実は、OpenCVは以下の記事にあるようにクロスコンパイルしてWindowsで動いた実績があるのです。
この実績に気を良くしてしまい、今回のアドカレでmruby-mrmagcik取り上げたのでした。

mruby-webcamをDockerをつかってWindowsで動くワンバイナリにする

まずは通常のmrbgemをつくった

Dockerでmruby-webcamを組み込んだWindows向けのmruby.exeを作る

動かす

docker exec container_id cat /root/src/mruby/build/i686-mingw32-w64/bin/mruby.exe > mruby.exe

として、dockerのホスト上のファイルを落として、あとは何らかの方法でWindows機に転送して
動かします。

cam = Webcam.new

# スペースキーを押すとここで登録したブロックが呼ばれます。
cam.capture {|img|
puts img.length # <- imgにJPEG形式でバイナリデータが入ってきます。
}

# Webcamの画像を表示する
cam.start

# 表示されたウィンドウでESCを押すと終了
mruby hello_webcam.rb

積み残し(ややステマw)

現状では、バイナリのWindows機への転送を

docker exec container_id cat /root/a.exe > ~/Dropbox/work/a.exe

などという、スマートとは程遠い運用をしてDropbox経由で激安Windows10 2-WayタブレットPC(Acer 2in1 タブレット ノートパソコン Aspire Switch 10E SW3-013-N12P/W /10.1インチ)にバイナリを
持ち込んでいるので、作成されたバイナリをLet's Encryptで証明書の問題もクリア出来つつある現状踏まえると、 mrubyのhttp2サーバーで配布するところあたりまで、
記事にしたかったです。

ちなみにmrubyで動くHttp2サーバーは以下があります。

まとめ

  • mruby自体が組み込み用途向けに作られていることもあり、本体のクロスコンパイルはスムーズにおこなえる
  • 既存のC/C++のライブラリのクロスコンパイルは割と手軽に出来ることもある
    • SVGライブラリのlibrsvgをクロスコンパイル試みたが、依存ライブラリ大量だし、それぞれ癖があり、断念した
  • すべてのライブラリを静的リンクするにはいろいろ壁があるのかも
  • いろんなライブラリをクロスコンパイルしたDockerイメージを作るともっとmrubyが面白くなるかも
    • 現状まだ、前述のオレオレコンテナの/usr/i686-w64-mingw32/lib配下しか出来てないが。。
  • Dockerのコンテナ内なので、クロスコンパイル向けのヘッダ等を誤って/usr配下のホストが参照するような場所にばら撒いても、コンテナが駄目になるだけで被害を最小限にとどめられる。
  • 実は最近mruby-cliがビルド出来ない状態だったのをIssue挙げて微力ながら問題解決に協力で来た

一見、CRubyに比べて、動的にgemを組み込めないmrubyが不便と考える向きもありますが、
Docker上のコンテナで全部入りのバイナリを作って配布することで、依存ライブラリが更新されてある日動かなくなる
といったこともなく便利に使えるかもしれません。

これは、子供たちにプログラム教える際にも有効かもしれません、皆がそれぞれ持参したPCにmrubyやmruby.exeを入れて、あとは
rubyスクリプトを書くだけで同じ環境でプログラムを動かせ、環境構築に時間がかかり、本来の学習に時間を取られることも
避けられると思います。

となんとなく、最後にTwitterのプロフに書いていることにこじつけ、今回の記事を終えます。

16
Help us understand the problem. What is going on with this article?
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
kjunichi
WebRubyがきっかけで、mrubyで実装されたhttp2サーバーのtrusterdに絡んだ事をやってみたり、ElectronのIssue眺めたり、手元で動かしたり、node.js関連。WASMも少々。投稿する記事の内容は個人の意見であり、所属する企業の見解を代表するものではありません。
japan-systems
「2019年に50周年を迎えたIT企業です。最先端の技術により全国の企業、官公庁、自治体に多くの実績があります。」

Comments

No comments
Sign up for free and join this conversation.
Sign Up
If you already have a Qiita account Login
16
Help us understand the problem. What is going on with this article?