CMakeでARM用にクロスコンパイルする

最近、オープンソースなどで配布されているソフトのビルドシステムがCMakeになっているのをよく見かけるようになりました。

CMakeはこれまでも何回か使ったことがありましたが、クロスコンパイルをしたいときの使い方を忘れてしまっていて、思い出すのに時間がかかったので備忘録として書いておきたいと思います。

目次

CMakeでHello World

クロスコンパイルの前にC言語のHello WorldプログラムをCMakeを使って(セルフコンパイル)ビルドしてみます。

ビルドするコード

#include <stdio.h>

int main(int argc, char **argv)
{
	printf("hello world\n");
	return 0;
}

CMakeLists.txt を書く

CMakeLists.txtを最小限の構成で手っ取り早く書くとこんな感じです。

cmake_minimum_required(VERSION 2.8)
add_executable(helloworld main.c)

cmake_minimum_required は文字通りcmakeのバージョンです。
add_executable でターゲット名とソースファイルを指定します。

ビルド

cmakeの便利な点として、ソースファイルのディレクトリとオブジェクトの出力ディレクトリを分けてビルドできる点があります。
CMakeLists.txt があるディレクトリで、

$ mkdir build
$ cd build
$ cmake ..

とすると、作成したbuildディレクトリ内にMakefileなどビルドに必要なファイルが生成されます。

実行例はこんな感じです。

-- The C compiler identification is GNU 5.4.0
-- The CXX compiler identification is GNU 5.4.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done

$ ls
CMakeCache.txt  CMakeFiles  Makefile  cmake_install.cmake

あとはこのbuildディレクトリでmakeコマンドを実行すればビルドできます。
私の環境だとコンパイラはGCCが使われたようです。

$ make
Scanning dependencies of target helloworld
[ 50%] Building C object CMakeFiles/helloworld.dir/main.c.o
[100%] Linking C executable helloworld
[100%] Built target helloworld

$ ./helloworld 
hello world

クロスコンパイルを試す

これでCMakeによるセルフコンパイルの準備はできました。
クロスコンパイルを行う場合は、更にツールチェインファイルというファイルを作成する必要があります。
といっても大げさなものではなくて、文字通りクロスコンパイル時に使用するコンパイラの指定をするだけです。

今回はRaspberrypi でも実行できるので、クロスコンパイラとして arm-linux-gnueabihf-gcc を使ってみました。
私が試したビルド環境は64bit版の Linux mint です。

$ uname -a
Linux mint 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Ubuntu系のOSであればインストールは、

$sudo apt install g++-arm-linux-gnueabihf

でインストールできると思います。

ツールチェインファイルの書き方

さて、本題のツールチェインファイルは以下のようになります。

ファイル名を arm-toolchain.cmake として、以下のような記述をします。

SET(CMAKE_SYSTEM_NAME Linux)
SET(CMAKE_C_COMPILER /usr/bin/arm-linux-gnueabihf-gcc)

ツールチェインファイルを書いたら、後はセルフコンパイルの時と同様にビルド用のディレクトリを作ってcmakeコマンドを実行します。

$ mkdir cross-build
$ cd cross-build
$ cmake .. -DCMAKE_TOOLCHAIN_FILE=../arm-toolchain.cmake

セルフコンパイルの時との違いとして、

• DCMAKE_TOOLCHAIN_FILE=../arm-toolchain.cmake

のようにツールチェインファイルのパスを指定してあげる必要があります。

-- The C compiler identification is GNU 5.4.0
-- The CXX compiler identification is GNU 5.4.0
-- Check for working C compiler: /usr/bin/arm-linux-gnueabihf-gcc
-- Check for working C compiler: /usr/bin/arm-linux-gnueabihf-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done

$ make
Scanning dependencies of target helloworld
[ 50%] Building C object CMakeFiles/helloworld.dir/main.c.o
[100%] Linking C executable helloworld
[100%] Built target helloworld

$ file helloworld
helloworld: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=9bd916148cf9880f2494f47199e8c001244a450d, not stripped

ちゃんとARM用にクロスコンパイルできました。
かなりミニマムな構成でのビルドの例なので、実際にオープンソースのプロジェクトなどをビルドする際はもう少しオプションやパスの指定などが必要になってくるかと思います。

自分の雛形用として、Githubにおいています。もし参考にされる方がいらっしゃいましたらどうぞ。

gist.github.com

[2017/10/2 追記]
クロス環境向けのインクルードパスとかのプレフィックスはどうするんだろう・・・ってなったので追記しておきます。

クロス開発環境のプレフィックスについて

クロス開発環境を使う際には、クロスコンパイラが使用するインクルードパス・ライブラリパスの指定が必要になってきます。

cmakeを使ってプレフィックスパスを指定する場合は、

 -DCMAKE_INSTALL_PREFIX:PATH=クロス環境のプレフィックスパス

とすればよいようです。

上記の Raspberry pi の例だと、

$ cmake .. -DCMAKE_TOOLCHAIN_FILE=../arm-toolchain.cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr/arm-linux-gnueabihf/

のような感じになります。

感想

CMakeは書き方を覚えてしまえばMakefileを直接書くよりは楽といえば楽ですね。
昔はMakeの本を読んで一生懸命Makefileを書き方を勉強したものですが、Makefileは書かないとすぐに忘れてしまいます。

GNU Make 第3版

Makefileを書きたくないものぐさな私は、

$ echo "gcc main.c hoge.c -o target" > build.sh
$ chmod +x build.sh
$ ./build.sh

みたいなことをよくしています。

小規模な実験的なコードを書く場合はこのやり方でもよいのですが、プロジェクトが育ってくるとやはりビルド管理したくなります。

Makefileさえ知らない新人のころのあるプロジェクトでは、

「ソースコード書いたらmfmkってコマンドを実行すればいいから」

と親切な先輩が教えくれた現場がありました。

あの便利な mkmf はLinux系のOSには標準では入っていないんですね。

依存関係とかを気にせずに特定のディレクトリのソースコード調べてMakefile生成するだけであれば簡単に作れそうに思います。気が向いたら作ってみたいです・・・

ウイルス性のいぼを自宅で治療した

最近、子供の足にウイルス性のイボができていたのですが、病院に行かずなんとか自力で治すことができました。

写真は治りかけの子供の患部の状態です。

削った後なのでかなりきれいになった状態ですが、(写真ではわかりづらいですが)赤いぶつぶつがまだ少し残っています。
*1

[2017-11-18 追記]
この記事ですが、割と沢山の方に読んで頂いているようですので完治後の子供の写真を載せておきたいと思います。

ウイルス性いぼによる赤い点々は完全になくなっています。
針で削ったこともあってか、皮膚は少し荒れていますが、イボ自体は完全に無くなりました。

*1:記事を書こうとは思っていなかったこともあり治療前から写真はとっていませんでした

WiFiのパケットをWireSharkでキャプチャする方法

スマホの通信(WiFi)をキャプチャする必要があり、少しネットを調べてみたのですが、あまりいい方法が見つからなかったので思いついた方法を試してみました。

試してみた結果、いい感じにスマホが送受信するパケットをWireSharkでキャプチャすることができたので記事として挙げておきたいと思います。

目次

注意

紹介する方法はWindows7でしかできない方法になります。他のOSについては別途試したときに記事を書きたいと思います。

作戦

パソコンをWiFiのAPにする

WiFiのパケットをキャプチャする場合、WiFiルータのところでキャプチャする必要がありますが、ルーターの通信をキャプチャするとなるとできなくはないのですが、環境構築とかが少し面倒です。

他に手軽にできる方法が無いか考えて、パソコンをアクセスポイントにして流れてくるパケットをキャプチャするという方法を思いつきました。

今回試した環境は、Windows7のPCです。インターネットには有線LAN経由で接続した状態にします。

準備するもの

パソコンをWiFiのAPにする場合、親機になれるUSBの無線LANドングルがあれば実現可能です。

USB無線LANドングルは１つの独立したネットワークアダプタとして認識されるのでWireSharkでキャプチャするときも便利です。

いろいろ調べてみると、バッファローのWLI-UC-GNM2SであればWindows7であればWiFiの親機のになれるとのことで購入して試してみました。

BUFFALO エアステーション 11n対応 11g/b USB2.0用 無線LAN子機 親機・子機同時モード対応 WLI-UC-GNM2S

cppcheckをビルドして使ってみる

目次

cppcheckという静的解析ツールを試してみました。
cppcheckはC/C++言語向け静的解析ツールですが、今回メモリリーク検出を目的として試してみました。

ビルド～インストールや試してみた結果について書いておきたいと思います。

背景

C言語やC++でコードを書いていると否が応でもメモリリークの危険性と戦う必要があります。

リークをなくすためには、

1. 動的メモリ確保を行わない
2. メモリリークがないかしっかり試験する

の２つのアプローチがあります。

私が普段仕事をしている組み込みソフトの開発では１の「動的メモリ確保を行わない」というアプローチは一般的です。

そもそも組み込み開発の場合、OSがない＝メモリ管理の機構(malloc,free)が存在しないというのは一般的です。
リアルタイムOSのitronを使う場合、固定長メモリプールや可変長メモリプールのAPIは利用できますが、メモリリークを嫌って使わないことも多いです。

最近では組み込みソフトの開発にLinuxを使われることが多く、さすがにその場合は「動的メモリ確保を行わない」というアプローチを取らなかったりします。
メモリリークというリスクを考慮すると、使わないで済むのであれば使わないに越したことはないと思いますが、Linuxを使うくらいですから扱うデータの規模もそれなりに大きかったりするので、スタックで確保するには大きすぎたり、静的変数で確保には使用効率が悪かったりします。

動的メモリ確保(malloc～free, new, delete)を使うとなると２の「メモリリークがないかしっかり試験する」が重要になってくるのですが、人手で試験をするのは手間も時間をかかりますので現実的とは言えません。

できる限り自動化したいところです。

メモリリークの検出にはいろいろなツールがあり、私も過去にvalgrindというツールを試してみたことがあります。

mcommit.hatenadiary.com

valgrindは非常に便利なツールなのですが、ビルド済みのバイナリ(デバッグビルド)を使ってメモリリークのチェックが行われるため、実は組み込み開発の実機では気軽に使えない(valgrind自体のクロスコンパイルが必要)という事情があります。
※組み込みLinuxの場合は開発中はセルフコンパイルで動作を確認したりするので、valgrindを使うメリットは十分享受できるのですが。

cppcheckを試してみる

いろいろ調べているとcppcheckという静的解析ツールでメモリリークも検知できるということを知り、今回ビルド・インストールして試してみました。

ビルド

こちらのサイトからソース一式をダウンロードします。

cppcheck.sourceforge.net

$ wget https://github.com/danmar/cppcheck/archive/1.80.zip

$ unzip  unzip 1.80.zip

$ cd cppcheck-1.80

ビルド方法については readme.txt に簡単に説明があります。
※cppcheckはいろいろな環境に対応しており、Windows環境であればVisualStudioでビルドできるほか、cmakeを使ったビルドもできるそうです。

私の場合、手元のLinux(Mint)で試しました。恐らくUbuntuでも同じようにビルドできると思います。

$ uname -a                                                                                                                                                                  

Linux mint 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

ビルド時の注意点

ビルド時の注意点が１点あります。
cppcheckは静的解析ツールなので、チェックするルールを.cfgというファイルで指定できるのですが、このファイルの配置場所をビルド時に指定しておく必要があります。
指定方法は

ちなみに指定しないでmake;make install してcppcheckを動かすと、

cppcheck: Failed to load library configuration file 'std.cfg'. File not found

(information) Failed to load std.cfg. Your Cppcheck installation is broken, please re-install. The Cppcheck binary was compiled without CFGDIR set. Either the std.cfg should be available in cfg or the CFGDIR should be configured.

というメッセージが表示されてソースコードのチェックが正しくできません。

正しく解析するためには、makeする際に、 CFGDIR=cfgファイルのパス としてcfgの配置ディレクトリを指定する必要があります。

なので、makeの実行は以下のようなコマンドを実行しました。

$ make CFGDIR=/usr/local/cppcheck/cfg HAVE_RULES=yes

※readme.txt を読んでもHAVE_RULESの説明は詳しく書かれていませんでしたがとりあえずつけてみました。
ちなみにHAVE_RULES=yesを指定する場合は、依存するライブラリとしてpcreが必要になるため、インストールが必要です。

$ sudo apt install libpcre3-dev       

cfgファイルは解凍したフォルダ内のcfgディレクトリ以下にいろいろなcfgファイルが入っています。
デフォルトでは、std.cfgが解析に使用されるようです。

インストール時に指定した/usr/local/cppcheck/cfg というディレクトリを作成し、これらのファイルをコピーします。

ビルドから、上記手順までのコマンドは、

$ make CFGDIR=/usr/local/cppcheck/cfg HAVE_RULES=yes

$ sudo make install;

$ sudo mkdir -p /usr/local/cppcheck/cfg

$ sudo cp ./cfg/* /usr/local/cppcheck/cfg

のような感じになります。

これでcppcheckを使う準備が整いました。
この時点で、cppcheck自体は /usr/bin にインストールされています。

cppcheckを動かしてみる

早速メモリリークの検出を試してみます。

今回、以下のようなコードでどんな感じにメモリリークが検出されるか試してみました。

#include <stdio.h>
#include <stdlib.h>

// =============================================================================
// define 定義
// =============================================================================
#define TEST_BUF_SIZE_MAX	(16)

// =============================================================================
// プロトタイプ宣言
// =============================================================================
void test_stack_overflow(void);													// スタックオーバーフロー(直値・ループ)
void test_stack_overflow_with_idx(int idx);										// スタックオーバーフロー(変数アクセス)
void test_heap_access(void);													// メモリリーク(free漏れ)
void test_mem_double_free(void);												// メモリ２重解放
void test_buf_over_run(unsigned char *buf, int len);							// バッファオーバーラン


// =============================================================================
// static 変数
// =============================================================================
unsigned char s_test_buf[TEST_BUF_SIZE_MAX] = { 0 };

int main(int argc, char **argv) {

	// =====================================================
	// スタックオーバーフロー
	// =====================================================
	test_stack_overflow();
	test_stack_overflow_with_idx(0);
	test_stack_overflow_with_idx(16);

	// =====================================================
	// バッファオーバーラン
	// =====================================================
	test_buf_over_run(s_test_buf, 4);
	test_buf_over_run(s_test_buf, 256);

	// =====================================================
	// メモリリーク
	// =====================================================
	test_heap_access();

	// =====================================================
	// ２重解放
	// =====================================================
	test_mem_double_free();

	return 0;
}

// 直接・ローカル変数によるループ中での配列アクセス
void test_stack_overflow(void)
{
	unsigned char buf[TEST_BUF_SIZE_MAX];
	int i;

	// インデックスアクセス:直値
	buf[0] = 0x00;
	buf[15] = 0x00;
	buf[16] = 0x00;
	buf[-1] = 0x00;

	// ループ変数アクセス
	for (i = 0; i < 17; i++) {
		buf[i] = 0x00;
	}

	return;
}

// 変数による配列へのアクセス
// 検出するとしたら呼び出し元で検出されるはず
void test_stack_overflow_with_idx(int idx) {
	unsigned char buf[TEST_BUF_SIZE_MAX];

	buf[idx] = 0x00;
	return;
}

// free漏れテスト
void test_heap_access(void) {
	char *p;

	// 確保して解放しない
	p = malloc(1024);

	return;
}

// freeによる２重解放テスト
void test_mem_double_free(void) {
	char *p;

	p = malloc(1024);

	// ２重解放
	free(p);
	free(p);

	return;
}

// バッファオーバーラン
void test_buf_over_run(unsigned char *buf, int len)
{
	int i;

	// 引数で指定されたサイズ分だけループする
	// →呼び出し側でlenを間違えた場合ここではなく呼び出し側でエラーがでる？
	for (i = 0; i < len; i++) {
		buf[i] = i;
	}

	// 引数で指定されたサイズ分だけループする
	// →呼び出し側でlenを間違えた場合ここではなく呼び出し側でエラーがでる？
	for (i = 0; i < len; i++) {
		buf[i] = i;
	}
	return;
}

cppcheckのシンプルな使い方として、引数にフォルダパスをしてするとそのパス内のファイルの解析をしてくれるようです。
今回は上記のコードを main.c として保存して試してみました。

$cppcheck .

出力は以下のような感じになります。

Checking main.c ...

[main.c:61]: (error) Array 'buf[16]' accessed at index 16, which is out of bounds.

[main.c:66]: (error) Array 'buf[16]' accessed at index 16, which is out of bounds.

[main.c:77]: (error) Array 'buf[16]' accessed at index 16, which is out of bounds.

[main.c:62]: (error) Array index -1 is out of bounds.

[main.c:88]: (error) Memory leak: p

[main.c:99]: (error) Memory pointed to by 'p' is freed twice.

[main.c:99]: (error) Deallocating a deallocated pointer: p

検出できたリークパターン

上記のコードはぱっと思いつくメモリリークのパターンをいくつか起してみたコードになりますがいい感じに検出してくれています。

検出内容として、

1. 配列の添え字がおかしい場合(直値の場合)
2. 配列の添え字がおかしい場合(マイナスの直値の場合)
3. 配列の添え字がおかしい場合(ループ変数の場合)
4. 配列の添え字がおかしい場合(引数の場合)
5. mallocのfree忘れ
6. ２重解放(freeしすぎ)

の6パターン検出しています。
なかなか優秀ですね。

検出できなかったリークパターン

上記のコードで検出できていないのは、 test_buf_over_run 関数の呼び出し、

    test_buf_over_run(s_test_buf, 256);

のケースです。
16byteで確保しているバッファに対し、256byte分の書き込みを行うというリークですが、さすがにこのパターンは検出できていません。

manualを読んでみた。

cppcheckには簡単なマニュアルがついています。

http://cppcheck.sourceforge.net/manual.pdf

一通り読んでみましたが思っていたより高機能のようで驚きました。

面白いと思ったのは、ソースコードではなくライブラリとして提供される関数のチェックをしたい場合、チェックしたい関数について設定ファイルに情報を書いて置くことでその関数も設定に従ってチェック対象になるそうです。そういった面では、拡張性を意識して作ってあるようですね。

感想

マクロの解析を含む構文解析、簡単な意味解析は行っていそうですが、関数をまたいだリークの検出までは行っていなさそうです。
なので、cppcheckによって100%メモリリークがなくなるとは言えない気がしますがソフトの品質を高めるのには有効なツールのような気がします。

今回はLinuxのコマンドライン環境で試してみましたが、VisualStduioやEclipseのプラグインもあるそうなのでGUIの開発環境からも連携して使えるようです。

普段の仕事でもうまく活用できないかもうすこしいろいろ試してみたいと思います。

Let's encript Failed authorization procedure ではまった

Let's encryptを使ったSSL証明書取得に挑戦してみたのですが、ハマりました。

3日ほど、色々ためした挙句、無事証明書を取得できたので、注意点など書いておきたいと思います。

参考にさせて頂いたサイト・記事

こちらのサイトの参考にさせて頂きました。ありがとうございます。

tsuchikazu.net

qiita.com

やりたかったこと

CentOS6.7上のNginxでWebサービスを立てているのですが、これまで使っていたStartSSLの証明書の期限が切れるので
Let's encryptに移行しようと思い上記サイトを参考にコマンドをたたいてみましたが正常に証明書が取得できませんでした。

実行コマンド

 sudo ./letsencrypt-auto certonly --webroot --webroot-path ドキュメントルートのパス -d ドメイン名

何度コマンドを実行しても、

Failed authorization procedure

のエラーメッセージが出てきます。

認証の流れ

証明書取得のコマンドである、
./letsencrypt-auto

はPythonのスクリプトですが、指定されたドキュメントルートに認証用のページデータを作成し、そのページに外部からアクセスできれば認証OKと判断しているようです。

どうもうまく動かないので、エラーメッセージでググったりした後、Nginxのアクセスログを見ながらコマンドを実行してみると、そもそもそれらしいアクセスが見当たりませんでした。

...

...

...

...

...

はい。

数秒考えて、原因分かりました。

そうです。火の壁が原因でした。

Let's encrypt ははInternet Security Research Group (ISRG)という海外の団体が運営しているそうです。

letsencrypt.org

不正アクセス対策のため、アメリカからのアクセスを含む海外からのアクセスはシャットアウトしていたのをすっかり忘れていました。

mcommit.hatenadiary.com

というわけで、一時的にファイアウォールを無効化し、再度コマンドを実行してみるとあっさりと証明書が取得できました。
証明書取得後はWebサーバの設定ファイル内で証明書・秘密鍵のパスを記載してあげるだけで更新作業は完了です。

はまったといっても、自分で作った落とし穴に自分で落ちたような感じでした。

失敗しすぎ注意!

ちなみに短時間の間に何度もコマンドの実行に失敗すると、認証やりすぎってことで注意されます。

There were too many requests of a given type :: Error creating new authz :: Too many invalid authorizations recently.

Please see the logfiles in /var/log/letsencrypt for more details.

感想

Let's encrptは証明書が楽に取得・更新できてとても便利ですが、海外からのアクセスに対しファイアウォールの設定をされている環境では注意する必要がありますね。

サーバの管理って、ちょっとしたことでもやったことが無かったり、久しぶりに触ったりすると結構な確率ではまる気がします。

nginx実践入門 (WEB+DB PRESS plus)