ソースコードをBloggerで。

いままでソースコード書くのが難しくて、思いっきり逃げてたんだけど
よさそうなツール見つけたので、組み込むことにした。

で、実際に埋め込んでみた。

#include <iostream>

int main()
{
	std::cout << "hello c++ world in blogger!" << std::endl;
}

なかなか良いかもなぁ。たまにはコード乗せるのもも面白そうだ

Boost を クロスコンパイルするよ

というわけで、クロスコンパイルの方法を。
環境はLinux（Ubuntu + ターゲットの開発環境）

流れは

1. ダウンロードと展開
2. bjamの作成
3. user-config.jam の書き換え
4. bjamの実行

です。

ダウンロード

ダウンロードは、boost.org から持ってきます。
今回は、とある事情から1.43.0を使いますが、たぶんどれでも大丈夫（だとおもう）

ダウンロードしたら、展開してください

• tar zxvf boost_1_43_0.tar.gz

とかでいいと思います。

bjamの作成

展開できたフォルダに移動して、bootstrap.sh を実行します。
作業場所では、いつも話題に上がりますが、
boostrap ではなく bootstrapですｗ

• cd boost_1_43_0
• ./bootstrap.sh

といった感じ。

user-config.jam の書き換え

今回は、クロスコンパイル用の g++ を使うので、そういう感じに書き換えます。
まず、user-config.jam の場所ですが、

<展開したboost>/tools･build/v2/user-config.jam

です。

適当なテキストエディタでファイルを開いて、編集準備を。
といっても、書き方がいろいろ書いてあるので、それに沿って書いていきます。

書式は

• using msvc : [version] : [c++-compile-command] : [compiler options] ;

今回は、g++ を差し替えるだけなので、gcc のデフォルト設定を上書きする感じ？

• gcc : 4.2 : <クロスコンパイル環境のパス>g++ ;

こんな記述を追記します。
そのほかにも、いろんな環境の設定が書いてあるので、眺めるのもいいと思います。

ビルドツールのマニュアルは、ここ（Boost.Build V2 User Manual）
クロスコンパイルの設定は、このあたり

bjamの実行

最後に、bjamを実行して、モジュールを作りましょう。
今回は、組み込み環境に突っ込むので、staticライブラリにします。

bjamの設定は、

• ./bjam –help

とかで確認できます。

今回は、インストールする場所を、ターゲット環境元のファイルがあるところへ

• sudo ./bjam --prefix="<ターゲット環境>/usr/local" --without-python --without-mpi link=static runtime-link=static threading=multi install

解説ですが、

sudoはインストール先のアクセス権が無いから。
--prefix="<path>" でインストール先を指定
--without-python は、pythonを動かす予定がないのと、ターゲットにもpythonいれないし・・・
--without-mpi は指定しなくても勝手に外れますが、メッセージが気になるので。
link=static でスタティックライブラリ
runtime-link=static でC、C++関連のライブラリもスタティックリンクします
threading=multi でマルチスレッド対応に。
install をつけて、出来あがったバイナリをインストールします。

まとめ

と、これで、出来あがったデータを使って、実行ファイルまで作成できることを
確認しましたが、実機上で動くかは、明日にでも確認できるかなぁ。

自分がよくわかってないことで、ar（アーカイバ？）って、クロスコンパイルのときも
Linuxのgccのやつをそのまま使ったりしてたりするけど、
クロスコンパイルの方のツールにも、専用っぽいやつがあるんだよね。
仕組みとして、ライブラリに変換するだけで、ライブラリのフォーマットは、
Linuxなら同じだから大丈夫とか、そういう理屈なんだろうか。気持ち悪い

動かなかったらまたいろいろ疑わないといけないなぁ

gccのバージョンによって、リンクがコケル。

いやー見事にはまった。

はまった内容は、gccのバージョン と リンク順で、
シンボルの参照が出来なかっただけっていう話。

gccの4.2だと、オブジェクトを先にリンクしないといけなくて
4.4だと、オブジェクトがライブラリよりあとでも大丈夫とか。

イメージだと

この書き方だと 4.2 、4.4 ともにOK
g++ <オブジェクト>.o -lboost_<name> -o output.out

この書き方だと、4.2はダメ 4.4だと通る。
g++ -lboost_<name> <オブジェクト>.o -o output.out

実際、クロスコンパイルしてて、クロスコンパイル用のgccが4.2
Linux上で使ってるのが4.4で違いが出たんだけど、
こういうのって、当たり前のことなんだろうか。
今度、リンク時の参照でこけたら、いろいろ順番入れ替えてみないといけないな。

[読書] 情熱プログラマー

読みましたよー

プログラマなら読んでおけって、@tosikawaさんとか@kaorun55さんに
薦められて、そりゃあ、読むしかないだろって。

読むのがこんなにへたくそなのに、一週間で読了とか、珍しい。
本当に面白いから、読むといいとおもう。

ちなみに、新人だと難しいとか、少し仕事をしてみてから とか
そんな意見をいくつか聞いたけど（誰もいってなかったりして）
実際に僕は読んでみて、誰が読んでもいいと思う。
ただ、「やってみよう」のところは読み飛ばすことになるのかなぁ
ちょっと残念。といっても僕もほとんど実践できてないので
気にしないけど（いいのかそれで）

僕にとっては、「共感」とか「すみません（さーせんｗ？）」が、
すごく多い本だったと思う。
でも同時に、「そうかそうするのか」って、もっと前向きに進む後押しをしてくれた本
実際、自分のやってる活動なんて、小さすぎて見えないようなことばかりだけど
それでも、そこからはじめるんだって言ってもらえれば、
そりゃあやる気になるってもんですよ。

ちなみに、別に、自分がいままでやってきたとが、片っ端から
全部間違ってるわけでもないし、実際、本の中でかかれていることを、
どんどんやってきた気がする。
ただ、それがぶっちゃけ人の真似だったり、あの人がああやってたから～とか
そんなことばっかりだったことを、解説してみました みたいな
上手く伝わらないけど・・・

だからこそ、いまこうやって本を読んでみて、それ、やったやった とか
あのとき、あんなこと言ってたけど、それってただの口実（いいわけ？）
だったのか とか。

余談だけど、
むかし、ただただテキストサイトにあこがれて、HTMLをテキストで書いてみて、
画面に文字が出たときは、片っ端から、すげーって自慢してた気がするし
そういうのがモチベーションだったり、周りの人が「おお、すごい」って
ちょっと驚いてくれるだけで、次のやる気につながってたのを思いだした。

それがこれから自分がプログラマっていう創作的な活動をする上で
すっごく大事なんだなって事を再認識した。

好きだからこの仕事してます という。

Linux Ubuntu ユーザー配下のディレクトリを英語名に。

この間教わったのに、また忘れたので書いておく。

シェルから
LANG=C xdg-user-dirs-gtk-update

です。

シェルとかで自分のディレクトリを移動するときに、日本語入力に変更したりするのとか
そもそも、日本語コード自体、あまり良くないし。

とりあえず、インストールしたらこれ打っておこう。

Powered by ScribeFire.

Trac と Python2.6 を一緒に入れたら、なんか変だ

ちょっとはまったので、備忘録です。

というかぜんぜん解決してないんだけど

発生した問題は、TracLightning と Python の開発環境を
同一PC内に入れようとしたら、開発環境側の環境パスが
へんちくりんになっちゃたというもの。

どっちを先に入れたかは忘れましたが、たぶんTracLightningが先かな。

何が問題だったかは、PILをインストールしようとして、インストールまでは
うまくいくのに、「import Image」が一切うまくいかないという。

実際に、モジュールをロードしようとするパスをダンプ（sys.pathのダンプ）
してみると、Python 2.6 のコンソールで出力してるのに、全体的に
TracLightning側のパスをさしていている模様。

実際、自分の環境で解決するために、TracLightningをアンインストールしたけど
もっといい解決方法があったのかなって、ちょっと後悔。