今日の一言
2009/12/06（Sun） 研究本格始動（予定） [長年日記] 編集
_ [FC][Ubuntu][Linux][プロジェクト実習][研究関係]gccを使う上でのメモその1（staticライブラリ，nm，strip，file，dynamicライブラリ）
静的（static）ライブラリの作成
こんな感じで使う。
gcc -c my_lib.c gcc -c other_lib.c ar rcs libmy_lib.a my_lib.o other_lib.o gcc -o static_call call_lib.c -L. -lmy_lib ./static_call
nmコマンド
指定されたライブラリ内に存在するシンボルのリストを表示するコマンド。
定義されているシンボルの名前、それぞれのシンボルの値、シンボルのタイプを表示できる。
また、ライブラリ内に情報が存在するならば（-lオプションを参照)、シンボルがソースコード内のどこで (ファイル名と行番号) 定義されているかも特定できる。
目的のライブラリ関数がどのライブラリに入っているかもnmで調べられる。
例えば sin 関数を探す場合、
$ nm -o /usr/lib/*.a /usr/X11R6/lib/*.a | grep sin
とすればよい。参照のみのシンボル (実体がない) であれば
U _sin
と表示されるので、
$ nm -o /usr/lib/*.a /usr/X11R6/lib/*.a | grep sin | grep -v ' U '
とすると、参照のみのシンボルを除外できる。
stripコマンド
シンボル情報を削る事が出来、容量を減らしたい場合等に用いることができる。
こちら（http://d.hatena.ne.jp/komugi_com/20071128/11962590）から詳細を引用
シンボル情報は関数などの名前を記述してあり、hogehogeのアドレスはどこか？といった情報が読み取れる。gdbやld がこれらの情報を使用する。
strip -g デバッグ情報を削除
strip -X ローカルシンボル (たいてい"L","."ではじまる)を削除
strip -x グローバルでないシンボルを削除(-Xより削除範囲が広い)
strip -s すべてのシンボルを削除(既定値)
ライブラリ(.aや.o)は -g以外を指定するとリンクできないことがある。
実行形式が strip されているかどうか (＝シンボルテーブルが付属しているかどうか) は、file コマンドで調べることができる。
fileコマンドを使うことで、ファイルの中身を表示でき、オブジェクト形式なども調べられる。
（strip されていない場合はnot strippedというメッセージが出るので、シンボルテーブルが付属していることがわかる）
共有(dynamic)ライブラリの作成
こんな感じで使う。
gcc -c -fPIC my_lib.c gcc -c -fPIC other_lib.c gcc -shared -o libmy_lib.so my_lib.o other_lib.o gcc -o dynamic_call call_lib.c -L. -lmy_lib
このままだとライブラリの場所が分からない可能性があるので、そこまでのパスを通してから実行。
$ export LD_LIBRARY_PATH=./:$LD_LIBRARY_PATH
$ ./dynamic_call
＊ldd （共有ライブラリへの依存関係を表示するコマンド）を使うことである程度の状態が分かる。（当然staticの方は表示されない）
2009/12/07（Mon） 研究本格始動 [長年日記] 編集 10:30現在晴 11℃
_ [FC][Ubuntu][Linux][プロジェクト実習][研究関係]gccを使う上でのメモその2（readelf，objdump）
ELFファイルの内容確認
lsを例にとる。
$ readelf -h /bin/ls | less
＊これの結果がどういうことを表しているかはelfのヘッダファイルを見れば分かる。が、別に見なくてもある程度分かると思う。
$ less /usr/include/elf.h
で、プログラムヘッダを見るには-lオプションを使う。
$ readelf -l /bin/ls | less
さらに、セクションヘッダを見るには-Sオプションを使う。
$ readelf -S /bin/ls | less
objdumpコマンド
オブジェクトファイルの詳細な情報を表示するコマンド。
セクションヘッダだけダンプ
$ objdump -s /bin/ls | less
特定の部分だけダンプ。
$ objdump -s -j .interp /bin/ls | less
逆アセンブル
$ objdump -d /bin/ls | less
ソースの情報（行数）を加えて逆アセンブル。
$ objdump -d -l /bin/ls | less
＊ただし、-g（デバッグ情報）を付けてコンパイルしていないと分からない。
$ gcc -g hogehoge.c
ソースの中身を加えて逆アセンブル。
$ objdump -d -s -l /bin/ls | less
＊ただし、-g（デバッグ情報）を付けてコンパイルしていないと分からない。
_ [FC][Ubuntu][Linux][プロジェクト実習][研究関係]C++でCの関数を呼ぶ（extern "C"）
Cの場合「シンボル名」はほぼ関数名と同じ。
が、c++では関数の所属する名前空間の情報や関数の引数の型情報がシンボルに含まれるようになった。
例えば、int hoge(int a) という関数がある場合、シンボル名は
c → _hoge
c++ → __Z4hogei
となる。（nmで確認できる）
その為、c++側で、xの関数を「extern "C"」を付けて宣言する必要がある。
extern "C" void function();
または
extern "C"
{
void func1();
void func2();
}
これにより、コンパイラはC++形式での名前修飾を行わなくなる。
ただし、extern "C"を使う場合、型のチェックが動かなくなるため、変な使い方をしていてもコンパイル出来てしまうという問題がある。
（実際には実行時にセグメンテーションフォルトで落ちる）
メモ：CでC++の関数を呼ぶ
基本的には出来ないが、extern "C" で宣言をしたc++ の関数ならば可能。
ただし、例外をCに渡してはならない。
_ [雑記]スーパーロボット大戦OGサーガ 無限のフロンティア
以前に買ってはいたものの、時間が無くて進めていなかったのだが、最近、会社説明会に出かける機会が増えたので、道中の電車の中でちょこちょこやっている。
で、昨日の帰りの電車の中でクリアしたのだが、結論としては予想以上に面白かった。
基本的にスパロボしかやらない自分が言うのも何だが、隠れた名作だと思う。
要所要所にスパロボテイストがあふれた小ネタが入っているのも自分としては高評価。
というか、それは使って大丈夫なのか？というようなネタも随所にちりばめられているため、スパロボを知らなくても十分楽しめる。
というか、いろいろギリギリまで頑張り過ぎている気もする。
新作（無限のフロンティアEXCEED）も出るので、やっていない人は是非。
・・・けどコレ、よくCERO審査をBで通ったな。
会話の場面では誰かが必ず一度はセクハラ発言するし。
『あぶない腹巻き』とか『愚者には見えない服』とか、そんなのが高レベル装備（最強装備一歩手前ぐらい）ってのもちょっと・・・
しかも『アミタイツ』に至っては男性キャラも装備できるし！
いろんな意味で、無限のフロンティア。
2009/12/08（Tue） その前に課題を片付けなければ！ [長年日記] 編集 4:30現在曇 9℃
_ [FC][Ubuntu][Linux][プロジェクト実習][研究関係]複数のgccを切り替えて使う（alternatives）
時に、gccのバージョンによってコンパイルできないプログラムがある。
その場合、下手に色々いじるよりは、複数のgccを入れた方が手っ取り早い。（gcc4.0系と3.4とかで意外とよく起きる問題だったりするし）
その場合、
# rm /usr/bin/gcc # ln -s /usr/bin/gcc-3.4 /usr/bin/gcc
として直接シンボリックリンク自体を張り替えてもいいのだが、ここでは「update-alternatives」を使う方法を述べる。
＊update-alternatives は、以前にJAVAの切り替えでも使った/usr/sbin/alternativesへのシンボリックリンク。
元々はDebian系のツールだったらしいが、今はRedhat系にも移植されているらしいので、意外と使える。
実はいろいろと面白い使い方が出来そうなツールだが、ここでは詳細は省き、とりあえずの使い方だけ説明する。
まず、alternativesのグループにプログラムを追加する。
指定の仕方は、
# update-alternatives --install 実行リンク グループ名 プログラムパス 優先度
優先度とかは別に好みで決めればいいと思う。ここでは、とりあえず新しいバージョンを優先するとして、
# update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-3.4 34 # update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.1 41 # update-alternatives --install /usr/bin/cpp cpp /usr/bin/cpp-3.4 34 # update-alternatives --install /usr/bin/cpp cpp /usr/bin/cpp-4.1 41
とでもしておく。
で、
# update-alternatives --config gcc
と入力すると選択画面が現れるので、変更したいgccのSelection番号を入力すれば切り替えることが出来る。（gccの場合、訳分からんことになりそうなので、一緒にcppも変更する事をおすすめする）
で、グループに追加済みのプログラムをグループから削除したい場合は、
# update-alternatives --remove グループ名 プログラムパス
てな感じで指定する。
基本的にはこれでOK。
詳しい使い方を知りたい場合は、ココ（http://blog.eni.co.jp/tech/2009/08/update-alternatives.html#about_alternatives）とかを参考にするのがいいと思われ。
2009/12/09（Wed） ものすごく面倒な宿題をクリア！ [長年日記] 編集 21:30現在晴 12℃
_ [雑記]マップス ネクストシート 第35話
ゲン＆リプミラ懐かしすぎる！
黄金の船の出現で強さのインフレが生じたかと思いきや、やっぱりこの２人の方がすごいのね。
まあ、基本スペックだけ見てるとリプミラ号は一般的な伝承族にも負けてそうだからなぁ。初期はギタニモンにもやられてたし。
スパロボで例えると、機体的にはあまり強くないけど、回避性能だけが異様に高くて、搭乗者が「底力Lv9」＆「ガッツ」持っている感じ？
＜意訳＞瀕死状態からが本番
それはそれとして。
ミュズの16倍発言から予想してたけど、やっぱりゲンが256倍出せるって設定出てきたか。
火事場の馬鹿力で4倍、伝承族の計算による真の潜在能力はそれの更に4倍、で、肉体と精神をシンクロさせた潜在能力はその16倍。すなわち、
4×4×16=256倍！
どんな計算だよ！けどこのノリが好きだ。
＊キャプテンオーマイガーの「マジックビームはレベルをひとつ上げるごとに100倍の攻撃力になる」設定とか、最高だよね！？
いまから来月が楽しみだ。
_ [FC][Ubuntu][Linux][研究関係]クロスコンパイラの作成その1（ターゲット：h8 elf、ホスト：SunOS 5.10）
とある事情でクロス環境をいくつか構築した。
せっかくなので、そのやり方を以下にまとめる。
作業スペースを確保
$ mkdir gcc4_h8elf $ cd gcc4_h8elf
ソースをDL&解凍。
$ wget ftp://sources.redhat.com/pub/newlib/newlib-1.11.0.tar.gz $ wget ftp://ftp.gnu.org/gnu/binutils/binutils-2.12.1.tar.bz2 $ wget ftp://ftp.gnu.org/gnu/gcc/gcc-3.3.2.tar.gz $ tar xvzf gcc-3.3.2.tar.gz $ tar xvzf newlib-1.11.0.tar.gz $ tar xvjf binutils-2.12.1.tar.bz2
binutilsのコンパイル
自分は展開場所を指定したが、デフォルトでいいなら--prefix=〜は不要。（これ以降も同様）
$ mkdir binutils-h8-elf $ cd binutils-h8-elf $ ../binutils-2.12.1/configure --target=h8300-elf --prefix=/home/akihiro-i/gcc4_h8elf/h8-elf $ gmake $ gmake install
コンパイルしたgccへのパスを通す＆パスの確認
$ PATH=$PATH:/home/akihiro-i/gcc4_h8elf/h8-elf/bin/ $ export PATH $ echo $PATH
解凍したnewlibへのパスを通す
（念のため。多分不要）
$ PATH=$PATH:/home/akihiro-i/gcc4arm/newlib-1.11.0/newlib/libc/include/ $ export PATH $ echo $PATH
gccのコンパイル
$ cd ~/gcc4_h8elf/ $ mkdir gcc-h8-elf $ cd gcc-h8-elf $ ../gcc-3.3.2/configure\ --target=h8300-elf\ --enable-languages=c\ --with-newlib\ --with-headers=/home/akihiro-i/gcc4_h8elf/newlib-1.11.0/newlib/libc/include\ --prefix=/home/akihiro-i/gcc4_h8elf/h8-elf $ gmake $ gmake install
newlibのコンパイル
$ cd ~/gcc4_h8elf/ $ mkdir newlib-h8-elf $ cd newlib-h8-elf $ ../newlib-1.11.0/configure --target=h8300-elf --prefix=/home/akihiro-i/gcc4_h8elf/h8-elf $ gmake $ gmake install
これで完成！・・・のはず。
テスト
とりあえず
$ h8300-elf-gcc -v
で、出来ていることを確認できたら、実際に使ってみる。
コンパイル
$ h8300-elf-gcc hoge.c
アセンブリコードの生成
$ h8300-elf-gcc -S hoge.c -o org_hoge.s
逆アセンブル
$ h8300-elf-objdump -d a.out > inv_hoge.s
セクションヘッダ情報の確認
$ h8300-elf-objdump -h a.out > section_header.txt
_ [FC][Ubuntu][Linux][研究関係]クロスコンパイラの作成その2（ターゲット：h8 hms、ホスト：SunOS 5.10）
基本的にはh8 elf用と同じ。
作業場所の確保
$ mkdir gcc4_h8hms $ cd gcc4_h8hms
ソースのDL＆解凍
$ wget ftp://sources.redhat.com/pub/newlib/newlib-1.11.0.tar.gz $ wget ftp://ftp.gnu.org/gnu/binutils/binutils-2.12.1.tar.bz2 $ wget ftp://ftp.gnu.org/gnu/gcc/gcc-3.3.2.tar.gz $ tar xvzf gcc-3.3.2.tar.gz $ tar xvzf newlib-1.11.0.tar.gz $ tar xvjf binutils-2.12.1.tar.bz2
binutilsのコンパイル
自分は展開場所を指定したが、デフォルトでいいなら--prefix=〜は不要。（これ以降も同様）
$ mkdir binutils-h8-hms $ cd binutils-h8-hms $ ../binutils-2.12.1/configure --target=h8300-hms --prefix=/home/akihiro-i/gcc4_h8hms/h8 $ gmake $ gmake install
クロスコンパイラへのパス
$ PATH=$PATH:/home/akihiro-i/gcc4_h8hms/h8/bin/ $ export PATH $ echo $PATH
解凍したnewlibへのパス
$ PATH=$PATH:/home/akihiro-i/gcc4arm/newlib-1.11.0/newlib/libc/include/ $ export PATH $ echo $PATH
gccのコンパイル
$ cd ~/gcc4_h8hms/ $ mkdir gcc-h8-hms $ cd gcc-h8-hms $ ../gcc-3.3.2/configure\ --target=h8300-hms\ --enable-languages=c\ --with-newlib\ --with-headers=/home/akihiro-i/gcc4_h8hms/newlib-1.11.0/newlib/libc/include\ --prefix=/home/akihiro-i/gcc4_h8hms/h8 $ gmake $ gmake install
newlibのコンパイル
$ cd ~/gcc4_h8hms/ $ mkdir newlib-h8-hms $ cd newlib-h8-hms $ ../newlib-1.11.0/configure --target=h8300-hms --prefix=/home/akihiro-i/gcc4_h8hms/h8 $ gmake $ gmake install
これで完成！
テスト
とりあえず
$ h8300-hms-gcc -v
実行形式の作成
$ h8300-hms-gcc hoge.c
アセンブリコードの生成
$ h8300-hms-gcc -S hoge.c -o org_hoge.s
逆アセンブル
$ h8300-hms-objdump -d a.out > inv_hoge.s
セクションヘッダ情報
$ h8300-hms-objdump -h a.out > section_header.txt
なお、今回設定したパスはログアウト等をすれば切れてしまうので、恒常的に使いたい場合には、キチンと設定すること。
_ [FC][Ubuntu][Linux][研究関係]クロスコンパイラの作成その3（ターゲット：arm-linux、ホスト：Ubuntu 9.04 (x86) ）
主にココ（http://www.belbel.or.jp/~belphegor/LinuxZaurus/process/cross.shtml）を参考に作成。
事前準備
$ export TARGET=arm-linux $ export ARCHIVE=~/gcc4arm-linux/archive $ export SOURCE=~/gcc4arm-linux/src $ export BUILD=~/gcc4arm-linux/build $ export TOOLS=~/gcc4arm-linux $ mkdir -p $ARCHIVE $SOURCE $BUILD $TOOLS/target
binutilsの作成
$ cd $ARCHIVE $ wget http://ftp.yz.yamagata-u.ac.jp/pub/GNU/binutils/binutils-2.13.2.tar.gz $ cd $SOURCE $ tar zxvf $ARCHIVE/binutils-2.13.2.tar.gz $ mkdir $BUILD/binutils $ cd $BUILD/binutils $ $SOURCE/binutils-2.13.2/configure --target=$TARGET --prefix=$TOOLS/$TARGET --enable-shared $ make $ make install $ PATH=$PATH:$TOOLS/$TARGET/bin $ export PATH
linux kernelのヘッダを準備
$ cd $ARCHIVE
$ wget http://support.ezaurus.com/developer/source/a300/20021224/linux-sla300-20021224-rom1_20.tar.bz2
$ cd $SOURCE
$ tar jxvf $ARCHIVE/linux-sla300-20021224-rom1_20.tar.bz2
$ cd linux
$ make menuconfig
("load an Alternate Configuration File" を選んで "arch/arm/def-configs/discovery-MV" と入力して OK を押す)
(あとはそのまま Exit で終了する。"Do you wish to save your new kernel configuration?" は Yes と答える)
$ mv Makefile Makefile.bak
$ sed "s/arm-linux-//g" < Makefile.bak | sed "s/SUBARCH = arm/# SUBARCH = arm/g" | sed "s/# SUBARCH :=/SUBARCH :=/g" > Makefile
$ make dep
(includeだけを用意する)
gccの作成(仮バージョン)
$ cd $ARCHIVE $ wget http://ftp.yz.yamagata-u.ac.jp/pub/GNU/gcc/gcc-2.95.3/gcc-core-2.95.3.tar.gz $ cd $SOURCE $ tar zxvf $ARCHIVE/gcc-core-2.95.3.tar.gz $ mkdir $BUILD/gcc $ cd $BUILD/gcc $ mv $SOURCE/gcc-2.95.3/gcc/config/arm/t-linux $SOURCE/gcc-2.95.3/gcc/config/arm/t-linux.bak $ sed "s/TARGET_LIBGCC2_CFLAGS = -fomit-frame-pointer -fPIC/TARGET_LIBGCC2_CFLAGS = -fomit-frame-pointer -fPIC -Dinhibit_libc -D__gthr_posix_h/g" \ < $SOURCE/gcc-2.95.3/gcc/config/arm/t-linux.bak > $SOURCE/gcc-2.95.3/gcc/config/arm/t-linux $ $SOURCE/gcc-2.95.3/configure --target=$TARGET --prefix=$TOOLS/$TARGET --enable-shared --disable-threads $ ln -sf $SOURCE/linux/include/asm-arm $SOURCE/gcc-2.95.3/include/asm $ ln -sf $SOURCE/gcc-2.95.3/include/asm/proc-armv $SOURCE/gcc-2.95.3/include/asm/proc $ ln -sf $SOURCE/gcc-2.95.3/include/asm/arch-arc $SOURCE/gcc-2.95.3/include/asm/arch $ ln -sf $SOURCE/linux/include/linux $SOURCE/gcc-2.95.3/include/linux $ make $ make install
glibcの作成
$ cd $ARCHIVE
$ wget http://ftp.gnu.org/pub/gnu/glibc/glibc-2.2.2.tar.gz
$ wget http://ftp.gnu.org/pub/gnu/glibc/glibc-linuxthreads-2.2.2.tar.gz
$ cd $SOURCE
$ tar zxvf $ARCHIVE/glibc-2.2.2.tar.gz
$ cd $SOURCE/glibc-2.2.2
$ tar zxvf $ARCHIVE/glibc-linuxthreads-2.2.2.tar.gz
# ftp://ftp.linux.org.uk/pub/armlinux/toolchain/src-3.2/build-toolchainに書かれているパッチを適用
$ perl -pi -e 's/i386/arm*)\n\tlibc_cv_gcc_unwind_find_fde=yes\n\tarch_minimum_kernel=2.0.10\n\t;;\n i386/' sysdeps/unix/sysv/linux/configure
$ perl -pi -e 's/weak_alias \(__old_sys_nerr/\/\/ $&/' sysdeps/unix/sysv/linux/arm/errlist.c
$ mkdir $BUILD/glibc
$ cd $BUILD/glibc
$ CC=$TARGET-gcc AR=$TARGET-ar RANLIB=$TARGET-ranlib $SOURCE/glibc-2.2.2/configure --host=$TARGET --with-headers=$SOURCE/linux/include --enable-add-ons --prefix=$TOOLS/target/$TARGET
makeinfo時にエラーになる部分の修正
$ mv $SOURCE/glibc-2.2.2/manual/stdio.texi $SOURCE/glibc-2.2.2/manual/stdio.texi.bak
$ sed "s/@ref{,/@ref{Top,/" < $SOURCE/glibc-2.2.2/manual/stdio.texi.bak > $SOURCE/glibc-2.2.2/manual/stdio.texi
$ make
make時にエラーが出た場合、該当個所を削除すれば一応コンパイルできる。正常に動作するかどうかは不明。
$ make install
gccの作成(本バージョン)
$ rm -fR $BUILD/gcc $ mkdir $BUILD/gcc $ cd $BUILD/gcc t-linux を元に戻す $ rm $SOURCE/gcc-2.95.3/gcc/config/arm/t-linux $ mv $SOURCE/gcc-2.95.3/gcc/config/arm/t-linux.bak $SOURCE/gcc-2.95.3/gcc/config/arm/t-linux $ $SOURCE/gcc-2.95.3/configure --target=$TARGET --prefix=$TOOLS/$TARGET --enable-shared --with-headers=$TOOLS/target/$TARGET/include --with-libs=$TOOLS/target/$TARGET/ $ make $ make install
linux kernelのヘッダをインストール
$ cd $SOURCE
$ rm -fR linux
$ tar jxvf $ARCHIVE/linux-sla300-20021224-rom1_20.tar.bz2
$ cd linux
$ make menuconfig
("load an Alternate Configuration File" を選んで "arch/arm/def-configs/discovery-MV" と入力して OK を押す)
(あとはそのまま Exit で終了する。"Do you wish to save your new kernel configuration?" は Yes と答える)
$ make dep
$ cp -R include/linux $TOOLS/$TARGET/$TARGET/sys-include
$ cp -R include/asm-arm $TOOLS/$TARGET/$TARGET/sys-include/asm
$ cp -fR $TOOLS/target/$TARGET/include/* $TOOLS/$TARGET/$TARGET/sys-include
$ rm -fR $TOOLS/target/$TARGET/include
$ ln -sf $TOOLS/$TARGET/$TARGET/sys-include $TOOLS/target/$TARGET/include
ライブラリ群の整理
$ mv $TOOLS/$TARGET/$TARGET/lib/ldscripts $TOOLS/target/$TARGET/lib rmdir $TOOLS/$TARGET/$TARGET/lib $ ln -s $TOOLS/target/$TARGET/lib $TOOLS/$TARGET/$TARGET/lib
これで完成！
環境構築後の利用方法
新しくログインし直したときなどは以下のように再度環境変数を設定しなおす必要がある。
$ export TARGET=arm-linux $ export ARCHIVE=~/gcc4arm-linux/archive $ export SOURCE=~/gcc4arm-linux/src $ export BUILD=~/gcc4arm-linux/build $ export TOOLS=~/gcc4arm-linux $ PATH=$PATH:$TOOLS/$TARGET/bin $ export PATH
_ [FC][Ubuntu][Linux][研究関係]クロスコンパイラの作成その4（ターゲット：arm-elf、ホスト：Ubuntu 9.04 (x86) ）
ホスト側のgccの切り替え
hostのgccが4.0系だとエラーを吐いたので、3.4に切り替える。
$ sudo apt-get install gcc-3.4 $ cd /usr/bin $ sudo rm gcc $ sudo ln -s gcc-3.4 gcc
これは別にalternativesを使ってもいい・・・はず。
作業場所の確保
$ mkdir gcc4_arm-elf $ cd gcc4_arm-elf
ソースのDL＆解凍
$ wget ftp://sources.redhat.com/pub/newlib/newlib-1.11.0.tar.gz $ wget ftp://ftp.gnu.org/gnu/binutils/binutils-2.12.1.tar.bz2 $ wget ftp://ftp.gnu.org/gnu/gcc/gcc-3.3.2.tar.gz $ tar xvjf binutils-2.12.1.tar.bz2 $ tar xvzf gcc-3.3.2.tar.gz $ tar xvzf newlib-1.11.0.tar.gz
binutilsのビルド＆インストール
$ cd ~/gcc4arm-elf/ $ mkdir binutils-arm-elf $ cd binutils-arm-elf/ $ ../binutils-2.12.1/configure --with-included-gettext --enable-shared --target=arm-elf-elf --prefix=/home/akihiro-i/gcc4arm-elf/arm-elf
(閑話休題) ＊共有ライブラリを使いたい場合は、configure が作成したlibtoolファイルを書き換える必要がある？（configureがうまく動いていない？）
* allow_undefined_flag の値を supported にする。 * always_export_symbols の値を yes にする。
が、自分の環境ではこれをやっても共有ライブラリの作成が出来なかった。・・・なぜだ。もしかして元々対応していないとか？
(続き)
$ make $ make install
ビルドしたbinutilsへのパスを通す
$ PATH=$PATH:/home/akihiro-i/gcc4arm-elf/arm-elf/bin/ $ export PATH $ echo $PATH
解凍したnewlibへのパスを通す
$ PATH=$PATH:/home/akihiro-i/gcc4arm-elf/newlib-1.11.0/newlib/libc/include/ $ export PATH $ echo $PATH
gccのCコンパイラだけビルド＆インストール
$ cd ~/gcc4arm-elf/ $ mkdir gcc-arm-elf $ cd gcc-arm-elf $ ../gcc-3.3.2/configure\ --enable-languages=c,c++\ --with-included-gettext\ --enable-shared\ --enable-threads\ --target=arm-elf-elf\ --with-newlib\ --with-headers=/home/akihiro-i/gcc4arm-elf/newlib-1.11.0/newlib/libc/include/\ --prefix=/home/akihiro-i/gcc4arm-elf/arm-elf $ make LANGUAGES=c all-gcc $ make LANGUAGES=c install-gcc
newlibのビルド＆インストール
$ cd ~/gcc4arm-elf/ $ mkdir newlib-arm-elf $ cd newlib-arm-elf $ ../newlib-1.11.0/configure\ --target=arm-elf-elf\ --prefix=/home/akihiro-i/gcc4arm-elf/arm-elf\ --enable-shared $ make $ make install
パスを通す
$ PATH=$PATH:/home/akihiro-i/gcc4arm-elf/arm-elf/bin $ export PATH
gccの残りをビルド＆インストール
$ cd ~/gcc4arm-elf/gcc-arm-elf $ make $ make install
これで完成！
テスト
実行形式をビルド
$ arm-elf-gcc hoge.c
確認
$ file a.out
結果
a.out: ELF 32-bit LSB executable, arm-elf, version 1, statically linked, not stripped
2009/12/10（Thu） ああああは死んでしまった！ [長年日記] 編集 0:00現在晴 11℃
_ [Ubuntu][Linux][研究関係]OpenGLでウィンドウのバーが消える場合
Ubuntu9.04で、OpenGLのウィンドウを生成したら、ウィンドウの上のバー（タイトルバー？）が表示されなかった。
＊今までは前画面表示を多用していたので気づかなかった模様。
調べたところ、どうやらCompizなるX Window System上で動作するウィンドウマネージャが悪さをしているらしい。なので、
「システム」→「設定」→「外観の設定」→「視覚効果」→「【効果なし】をチェック」
とすれば、正常にバーが表示されるようになる。
ただ、あくまで、特殊な効果を切っただけなので、根本的な解決にはなっていない。なので、それが嫌な人は止めた方がいいです。
_ [Ubuntu][Linux][研究関係]『サポートされていないアップデート』を候補に追加
十分な検証が済んでいないプログラムでも、一応apt-getで入れられる可能性がある。
まず、/etc/apt/sources.listを管理者権限で開き、
## Uncomment the following two lines to add software from the 'backports' ## repository. ## N.B. software from this repository may not have been tested as ## extensively as that contained in the main release, although it includes ## newer versions of some applications which may provide useful features. ## Also, please note that software in backports WILL NOT receive any review ## or updates from the Ubuntu security team.
の下の2行（環境によって内容は異なる）
# deb http://jp.archive.ubuntu.com/ubuntu/ jaunty-backports main restricted universe multiverse # deb-src http://jp.archive.ubuntu.com/ubuntu/ jaunty-backports main restricted universe multiverse
をコメントから出す。
ただし、書いてあるように、『サポートされていないアップデート』を候補に追加することになるため、あくまで自己責任で行うこと。
で、編集した後は
$ sudo apt-get update
で変更を適用する。（必須）
＊GUIの場合は、
「システム」→「システム管理」→「ソフトウェア・ソース」→「アップデート」→「『サポートされていないアップデート』をチェックする」
で行える。
これで『サポートされていないアップデート』が候補に含まれる様になった。
＊『サポートされていないアップデート』もほぼ同様。
_ [FC][Ubuntu][Linux]OpenVRMLをインストール
本家はココ（http://openvrml.org/）で、
$ svn co http://svn.openvrml.org/svnroot/openvrml/trunk openvrml
とすれば最新版のソースがDL出来る。
が、コンパイルは意外とめんどくさい。
なので出来ればapt-getで済ましてしまいたいのだが、自分が使っている9.04のリポジトリにはOpenVRMLは存在しない。
が、調べたところ、Ubuntu8.04（hardy）にはのリポジトリにはOpenVRMLが存在する。
直接debをDLしてインストールしてもいいのだが、ここはリポジトリを追加してapt-getで入れることにする。
まず、/etc/apt/sources.listを管理者権限で開き、
deb http://jp.archive.ubuntu.com/ubuntu hardy main universe
を追加。で、
$ sudo apt-get update
を行い変更を適用する。
後は
$ sudo apt-cache search openvrml*
で調べて出てきたものをapt-getすればいい。
$ sudo apt-get install libopenvrml5-dev
・・・けど、8.10以降で削除されているのはちょっと気になる。なぜだ！？
＊ちなみにFedoraは
$ yum install openvrml-player openvrml-mozilla-plugin
でインストールできるらしい（未確認）
一緒にVRMLビューワであるOpenVRML-lookatもインストールされる。
使い方は
$ lookat hogehoge.wrl
正直、微妙。OpenVRML使うの止めようかな・・・
2009/12/14（Mon） 簡単なはずのプログラミングが終わらない・・・ [長年日記] 編集 4:30現在晴 9℃
2009/12/15（Tue） でっていう [長年日記] 編集 0:00現在晴 8℃
_ [OpenRTM][Windows][プロジェクト実習][研究関係]OpenRTM1.0講習会の時のメモ
＊２か月ぐらい前に受講した時の内容なので、需要があるかどうかは知らぬ。
あと、本気でただのメモなので、期待されても困る。
小ネタ1
1.0からは複数のコンポーネントをmanegaer（rtcd.exe）を使って管理できるようになった。
＊設定はrtc.confに書かれる。
小ネタ2
「ウィンドウ」⇒「設定」を開き、
「RT Name Service View」や「RT System Editor」の「接続」の画面から、接続の周期を変えることができる。
1.0からの機能
「コンポジットコンポーネント」
２つのコンポーネントのスレッドを共有化する。
ダブルクリックすると構成が分かる。
また、ポート上で右クリックするとポートの公開、非公開が設定できる。
「マネージャーコンソールビュー」
managerをクリックすると「manager console view」が開く。
で、createを押すと、現在管理しているコンポーネントの中から（typeで選択）新しく同じものを開くことができる
rtc-builderの使い方
先に設定が必要。
設定を開き、RtcBuilder DataTypeにidlファイルの場所を登録する。
addを押して、場所を指定。
＊デフォルトではC:\Program Files\OpenRTM-aist\1.0\rtm\idl
で、「open new rtcbuilder editor」アイコンをクリック。
ファイル→新規新規→その他⇒その他⇒rtcbuilder
プロジェクト名を決めて終了。
「言語・環境」を選んでC++をクリック。
「基本」に戻ってRTCプロジェクトの保存先に先ほどのプロジェクトを選ぶ。
で、コード生成。
VCの場合は、プロジェクトの保存先に出来ているcopypops.batを起動して設定ファイルをコピーしてくる。
んで、VCを選んで、ModuleName_vc9.slnを開く。
後は普通にプログラミングー。
＊起動する前に、コンポーネントプログラムを起動する場所にrtc.confを設置しておくことを忘れないように！
＊これだと、出来るのはポートを持たない最低限のコンポーネント。
タブでいろいろ選んでいけばポートを増やしたりコンフィギュレーションを設定できる。
＊各タブの下のほうにでるコメントの部分はdoxygenで使える形でコードに組み込まれる。
OpenCVを動かした時のメモ
vc8のdllを要求された場合
Microsoft Visual C++ 2005 SP1 再頒布可能パッケージ (x86)
を入れればいい。
vc9を要求された場合
VC++ 2008 再頒布可能パッケージ (x86)
を入れる。
＊というか、解像度があってない場合にはそもそも映らない。
コンフィグレーションで変えてみれば治るかも。
2009/12/18（Fri） ちくしょぉぉぉぉ！ [長年日記] 編集 1:30現在曇 5℃
_ [OpenAL][Linux][Ubuntu][FC][研究関係]OpenALのサンプルコード
ずっとサンプルコードは無いものと思っていたのだが、実は本家から普通配布されてた・・・。
（http://connect.creativelabs.com/openal/OpenAL%20Wiki/Source%20Code.aspx）
ちなみに、リポジトリに保存されているファイルをローカルに取り出す（チェックアウトする）には、「svn co」コマンドを使う。
$ svn co svn://connect.creativelabs.com/OpenAL ./OpenAL
＊最後の./OpenALは吐き出す先を指定する。
・・・くそ！自力でここまでやってきたのが馬鹿みたいだっ！
・・・まあいい。これからは活用していこう。
2009/12/21（Mon） 風邪ってずっとひいてると慣れるね！ [長年日記] 編集 23:30現在晴 5℃
_ [研究関係][Windows][雑記]（参考文献用の）PDFファイルを一括管理するソフト：Mokuji
そろそろ、というか、大分前からサーベイした論文の管理が雑になってきた。
正直、見つからないからって、同じ論文を２回DLするのは無駄過ぎる。
そこで、以前先生がMacで良さげなPDF管理ソフト（有料）を使っていたので、Windowsでもそれっぽいフリーソフトがないか調べてみた。
で、見つかったのが、「Mokuji」というフリーソフト。（http://www.mokujiroku.org/）
その名の通り、「大量のPDFを、本の目次のように分かりやすく並べて管理できるソフトウェア」らしい。
使ってみたところ、自分の用途にぴったりだった。
個人的には、「mkj」というひとつのライブラリファイルとして全てのPDFを保存するのが気に入った。
必要に応じて必要なファイルだけをPDFとして取り出せるし。
よし、とりあえず今までサーベイしたのを全部コレに移そうか。
＊このソフトはgoogle検索的に、名前で損していると思う。
・・・常識的に考えて、mokujiでググってコレが出てくるわけないよねっ！？
もう少しユニークなのにすればいいのに。
_ [雑記]教えてないのに後輩っぽいのがツッコミに現れた件について
なして？
（http://robotics.naist.jp/~akihiro-i/dialy/?date=20091214#p01）
こんな名前で書きこむヤツはひとりしか心当たりねぇよ。
あと、俺は般若については触れてねーです。というか、般若とか思ってねー。
＊どうでもいいことだが、自分の中では「固定砲台」≠「なのは」≒「ライン・ヴァイスリッター」という認識だったりする。
2009/12/24（Thu） 今年もクリスマスは中止です [長年日記] 編集 23:30現在晴 9℃
_ [Windows][OpenGL][OpenCV][雑記]ARカード+ARアプリ、これってARToolKitそのものじゃ・・・？
とりあえずこれを見てくれ。
（http://headlines.yahoo.co.jp/hl?a=20091224-00000003-jct-ent）
うん、オタクって凄いね。
で、まあ、それは正直どうでもいいんだが、付属のARカードについて書いている部分
ARカードとは、ウェブカメラなどで撮影した画像に、立体画像などを合成する技術を利用したカードのこと。今回のラブプラス限定ARカードも、公式サイトからアプリをダウンロードした状態で撮影すると、3人のヒロインの立体画像を見ることができる。
うん、これってわざわざケーキを買ってカードを手に入れる必要ないよね？
カードはキーとなる模様を描いたただの紙なんだし。
どう考えても、重要なのは公式サイトからダウンロードできるアプリの方。
アプリを持っている人は、カードの模様を別の紙に印刷してやってみればいい。
なんら問題なくできるはず。
というか、にはアプリからモデルデータが抜き出してARToolKitを使えば、専用のカードすら不要な気が。
まあ、公式アプリのDLの際の規則に
第６条 【禁止事項】 １．本ソフトウェアおよび本ソフトウェアに使用されているビジュアルのすべては、書面による当社からの事前の承認なしに、無断で複製、転載、再配布などすることはできません。また、営利目的のための使用は一切禁止とさせていただきます。 ２．ユーザーは、本ソフトウェアを、修正、変更、改変、リバース・エンジニアリング、逆コンパイル、逆アセンブルなどすることはできません。
とはっきりと書いているので、たぶんやったらアウト。絶対やっちゃダメ。少なくとも自分はやらない。
まあ、そもそも既に公式アプリはDLできなくなっているのだがね！
_ 津田先生（偽） [じゃあ，リモコンを松葉杖に取り付けたら台車を押さなくても大丈夫ですね！]