すｚのAspireOne研究: 開発環境の整備(1)

<< Jz4755を使った装置 | TOP | Android端末を選ぶ基準 >>

2011年08月30日

開発環境の整備(1)

新たにマシンを組んで開発環境を整備することにした。

なにの開発環境かというと、当然ながら Jz47xx の開発環境だ。OS は、64bit の Linux で RHEL 6.1 clone 。

さて、64bit Linux を使う思惑の説明をしておこう。

こういう思惑で進めていて、うまくいけば RHEL 6.1 相当の mipsel 環境ができあがる。ただ、失敗するかも知れない。なかなか難しいのだ。

... とまぁ遠大な計画。まだ (3) の途中だし挫折するかも知れない。すくなくとも時間はかかる。時間がかかると、途中で別のことがしたくなって中断するかも。

前に redhat-7 の環境をどうのということを書いたが、よくよく見たらビルド環境がなかったのでパス。もっともそれがあったとしても RHEL 6 レベルに到達するのはかなり難しい。今回は、RHEL 6 どうして arch の乗り換えという方針。これなら成功すれば一気に最新の環境が出来上がる。うまくいけば ppc も作りたい。arm までは手を出さない。(RPM ベースでは arm の実績はないようだ、ppc や mips は　64bit 版がある)

追記１ -- 気がついたことを追記していこうと思う

glibc は、RHEL のビルド途中のもの (すなわち正規のパッチを当てたもの) のビルドがなんとかできた。(ただし gcc,g++ までで addon も rtkaio は失敗)
```
ftp://ftp.ingenic.cn/3sw/01linux/00toolchain/
jz-crosstools-src.tar.bz2 	67863 KB 	2009/04/03 	0:00:00
```
ビルドするにあたり、これに含まれているビルドスクリプトが大変参考になった。

ちなみに、正規の glibc は mips に対応していない。ビルドするには、glibc-ports を glibc のディレクトリに置いて addon のリストに top ディレクトリを加えるそうだ。
ただ、gcc はあくまでクロス用のものしか作れていない。なにが不便かというとライブラリを /cross/mipsel-linux/lib に置かないといけないということ。/lib , /usr/lib を使うようなものにしたかったのだが、挫折。

だが、よくよく考えてみれば、本当にクロス... というか native で動かしたいのは、cc1 と cc1plus のみ。 rpmbuild で mipsel 用の gcc のパッケージが作れればそれを当ててから cc1 と cc1plus を置き換えれば良い。当面は rpmbuild でビルドしていくこと　をやっていこう。

binutils は、cc1 と cc1plus ほどは CPU を消費しない。mipsel のパッケージを作ってエミュレーションで動かしても良いかも知れない。
rpmbuild についてだが、--target=mipsel を付けるだけでビルドできるものがあった。/usr/lib/rpm/macros を編集しないといけないと思っていたのだが、単純なものはそれすら必要ない。

ただ、作ったものは rpm でインストールできない。結局は /usr/lib/rpm/macros を編集しないといけない。
rpmbuild では、mipsel だけの依存関係は見てくれない。x86_64 の rpm があれば通ってしまい、必要なものがないのにビルドしようとする。

これは、困るので一旦 devel パッケージ群をアンインストールすることにした。

ビルドが通ったら、x86_64 の devel をインストールして、mipsel の共有ライブラリを /cross にコピーしていく作戦。

実は、言うはやすし、なのだ。devel パッケージは 200-300 個ぐらいある。やってられないので、早めに gcc の rpm を作って rpm コマンドが使えるようにしたい。
rpm で、システムの arch を見ている。/bin/arch や /bin/uname 経由なら割と簡単にごまかして mips に見せかけられそうだが、システムコールで見ているとちょっとやっかい。これは調べておかないと。

ちなみに mipsel のバイナリになってしまえば qemu が "mips" を返すようになる。"mipsel" でなくて構わないのか？という気がするがカーネルがどうなっているか調べて必要ならそれに合わせようと思う。

追記２ -- いくつか失敗したのでメモ

gcc や binutils は、本来 rpm を作成する予定のソースコードを使い、機能に関するオプションも同じにしておく。

gcc のパッケージのビルドは、作成した gcc を使ってライブラリを作成する。作成した gcc とは、mips だから cc1/cc1plus を含め qemu で動作する。そうなると時間がかかってしょうがないのだ。

正規のパッケージを作成するときは止むをえない。(セルフ環境が出来ていたら、そちらを使った方が良い)。だが、とりあえず、バイナリが使いたいだけなので、ビルドを一旦止め x86_64 の cc1 に置き換えるとかした方が良い。

最終的なクロス環境でも x86_64 の cc1/cc1plus 置き換える予定だから、同じオブジェクトが出るようにしておいた方が良いという理由もある。

binutis は、シビアではないと思うが、些細な差異が問題が出るといやなので同じにしておく。

ちなみに --target は、mipsel-linux で良いと思う。
x86_64 で動かすクロス用の環境がビルドできたら、mipsel に見せかけるように環境を変える。/usr/bin の gcc とか as,ld などは、mips のものに置き換える。

あと /usr/include や /lib /usr/lib も置き換え。/cross/mipsel-linux 以下にあるものをコピー。
(簡単なプログラムがちゃんとコンパイルできて、動作するかも確認しておく)

/usr/lib/rpm/macros は、x86_64 を mipsel に置き換える。あと %mips mipsel を追加。

/bin/uname , /bin/arch も mips を返すようにすべきだが、まだやっていない。

追記３ binutils/gcc/glibc の変更

http://fedoraproject.org/wiki/Architectures/MIPS

ここを見ると、fedora 13 は、mips64el への移植プロジェクトがあって、バイナリとソース RPM をリリースしている。

で、オリジナルの fedora 13 のパッケージと spec ファイルを比べると、どこに変更が必要かわかる。binutils でさえパッチが追加になっていて、一筋縄ではいかないような感じ。RHEL6 をベースにして target だけ変更すれば良いような甘いものではなかったらしい。
- gcc のビルドにすごく時間がかかるのだが、ほとんどは、fixed-point の生成。(さらにエミュレータ環境ではこれのための時間が飛躍的に増える) 使いもしないのに、やってられないので、disable することは重要。
- glibc に mips を対応させるには、 glibc-ports が必要。
- -march=mips3 -mabi=n32 これはどうすべきなのだろう？
- redhat 系の mips では、64bit が標準で 32bit は lib32 を使うものらしい。-- これは気に入らない。x86_64 のように lib と lib64 を使うようにして欲しかった。まぁ好き勝手に作るので、32bit 専用で lib を使うようにしたい。
- 上でも書いたが soft-float にはしない。Jz4760 は FP を持っているし、次に出る Jz4770 も持っている。その前のものは FP がないが、別にカーネルでのエミュレーションで問題ないはず。soft-float にすると FP を持っている CPU がそれを生かせない。-- こっちのデメリットの方が大きい。
さて、この fedora 13 (MIPS) の binutils/gcc/glibc をビルドして、x86_64 の環境も入れ替えることをまずやろうと思う。

... これはなんとかなった。いろいろ問題があるもののパッケージも作れた。

次は、cross 用のもののビルド。

binutils は簡単だ。
```
 --define "binutils_target mipsel-linux" --without testsuite 
```
このオプションを追加するだけで良いらしい。

問題なのは、gcc 。
```
../configure --prefix=/usr --target=mipsel-linux --enable-shared \
--enable-threads=posix --enable-__cxa_atexit --disable-libunwind-exceptions \
--enable-gnu-unique-object --enable-languages=c,c++ --disable-libgcj \
--disable-multilib --disable-fixed-point --without-ppl --without-cloog \
--disable-checking --disable-werror --disable-libgomp
```
クロスの環境は、これでなんとか。ただし、include ファイル一式と glibc を用意しないといけなかった。(さらに mipsel の gmp-devel, mpfr-devel libz-devel 相当も用意した)

実をいうと、この bootstrap となる環境をどう作ったのか良くわかっていない。最終目的のモノが出来てしまえばそれを使うようにすれば良いから気にしないことにする。
さて、これを元に glibc

インストールした gcc/g++ は、prefix なしの as/ld を使うようなので、binutils のコマンドを /cross/mipsel-linux/bin とかに prefix なしでコピーしておく。

で、build 用ディレクトリは、x86_64 用に rpmbuild で作った上で、glibc-ports , を ports に rename して入れ、glibc-2.12-2-gc4ccff1-fedora-mips.patch を当てる。
```
export PATH=/cross/mipsel-linux/bin:$PATH
../configure \
CC="mipsel-linux-gcc" \
CXX="mipsel-linux-g++" \
CFLAGS="-fexceptions -DNDEBUG -g -O3" \
--prefix=/usr --enable-add-ons=ports,nptl,c_stubs,libidn --without-cvs --enable-kernel=2.6.18 --with-headers=/usr/mipsel-linux/include \
--enable-bind-now --with-tls --with-__thread \
--enable-multi-arch --disable-profile --enable-experimental-malloc --disable-nss-crypt \
--build=mipsel-linux
```

追記: 2011/10/04

追記: とりあえず今の状況とビルドメモ

http://nmj.sumomo.ne.jp/my-rhel6/


# rpmbuild --define "binutils_target arm-linux-gnu" \ 
     --define "binutils_target mipsel-linux" \
     --rebuild binutils-xxxx.src.prm


 # ../configure --prefix=/usr --target=mipsel-linux \
      --build=x86_64-redhat-linux --host=x86_64-redhat-linux \
      --disable-threads --disable-checking --with-system-zlib \
      --enable-__cxa_atexit --disable-libunwind-exceptions \
      --enable-gnu-unique-object --enable-languages=c,c++ --disable-libgcj \
      --disable-libmudflap --disable-libgomp --disable-libssp  \
      --disable-shared  --disable-libstdc__-v3


 # ../configure CC=mipsel-linux-gcc CXX=mipsel-linux-g++ \
    AR=mipsel-linux-ar RANLIB=mipsel-linux-ranlib --prefix=/usr \
    --enable-add-ons=nptl,c_stubs,libidn,ports --without-cvs \
    --enable-kernel=2.6.18 --enable-bind-now --with-tls --with-__thread \
    --disable-multi-arch --disable-profile --enable-experimental-malloc \
    --disable-nss-crypt \
    --host=mipsel-linux --build=x86_64-redhat-linux \
    --with-headers=/usr/mipsel-linux/include


 # make install_root=/tmp/new-glibc install

いくつかの .so は ../lib のもののリンクになっている。これを /lib になるように張り替える。
libc.so などは、テキストで、/usr/lib を指しているところがある。これを /usr/mipsel-linux/lib になるように編集する。


 (1回目)    --disable-shared  --disable-libstdc__-v3 
 (2回目)    --enable-shared

ここまでがクロスの環境。

さて、ここからは、qemu-mipsel を使った擬似セルフ環境に移る。

(前に戻れなくなると困るので、以上の chroot 環境を fork する。)


  rpmbuild --target mipsel ....

調査(1)

__mipsel__ を定義したいのだが、誰がどこで定義するのが正しい？

gcc を見たら、__x86_64__ などは、gcc/config/i386 の配下で見つかった。答えは gcc 。gcc は、cpp/gcc/cc1 のパーツに別れているのだが、関係あるのは (おそらく) cpp 。

で、定義するのは、gcc/config/mips/linux.h (の TARGET_CPU_CPP_BUILTINS() ) が普通らしい。この定義の中で TARGET_64BIT, TARGET_BIG_ENDIAN を参照して、
```
   __mipsel__ , __mipseb__ , __mips64el__ , __mips64eb__
```
のどれかを定義することにした。
メモリ不足はなぜ起きるのか？まずは map から
```
  #  cat /proc/プロセス番号/maps
```
とすることで、どこに map しているかが分かる。qemu-mipsel を使っても元の mips の mapping に従っているように見える。maps を整理すると ...
```
      00400000-              プログラム(cc1 など) 
      xxxxxxxx-              heap (text - data - bss の次から)
      40000000-40001000 ---p 
      40001000-40a01000 rw-p stack
      40a01000-              /lib/ld-2.12.so

      40000000-              /lib/ld.2.12.so
      40b1c000-              libgcc_s.so.1

      60000000-             qemu-mipsel
      6d523000-6d544000     [heap] (qemu 自体の)
  2b898922c000-             /lib64/ld-2.12.so
```
heap や stack について、簡単なプログラムで printf してチェックしたところ、heap は、プログラムの終わりから stack は、40a10000 あたりから逆向きに割り当てられることが分かった。

要するにプログラムが使えるアドレス空間は、ダイナミックライブラリを除くと 00400000 - 40000000 の約 1GB ということになる。これが足りない.... ということが起きるかどうかは、分からない。随分前のバージョンでも数百MB なら使っているのを見たことがある。

問題は、スタックかも知れない。 40000000 からの 1ページは、アクセス不可になっている。ということは、これがボトムでこれを超えることは出来ないのかも。そうだとすれば 40a01000 までの　10MB がスタックに割り当てられた領域。

stack も alloca を使うと大量に消費することになるから、stack 領域の不足の可能性は高い。

ただ、 40000000 にアクセスしたときに copy-on-write で割り当て直すかも知れない。これも簡単なプログラムで確かめることが出来る。確かめてみたところ、40001000 には書き込めたが、40000000 だと core dump した。たぶん、stack bottom は超えられないのだろう。

追記: 調べていたら、qemu の -s オプションでスタックサイズを変更できることが分かった。

たとえば、qemu-mipsel -s 67108864 /bin/bash.mips として起動すると /lib/ld-2.12.so のアドレスが 44001000 に変わる。

で、ソースを見てみると ... ulimit も参照してスタックサイズを決めている。
```
stack size              (kbytes, -s) 10240
```
ulimit で見てみたら、10MB にしていたのは、自分であった。そして、たとえば ulimit -s 65536 とすれば、64MB 確保されることが確認できた。
```
virtual memory exhausted: Cannot allocate memory
```
それはクリアできたが、やはりダメだ。... というより悪化しているかも。

追記: 結構出来てきた。パッケージ数にして 208 個。(... といっても 1/5 ぐらい。)

cc1 , cc1plus

なんとかセルフで cpp, gcc , g++ と cc1, cc1plus を作ることはできた。忘れないように書いておくが、エラーになったら prev-gcc の cc1 をクロスのものに置き換える。2 回ぐらい置き換えたらなんとか誤魔化せた。

セルフ環境では、セルフで作成した binutils , glibc の rpm を使っている。

binutils は、オリジナルの srpm で OK だったが、glibc は locale の作成でメモリ不足でエラー。
まとめて変換しているところを 1 つづつ行うように修正。それでも最後はダメなので、いくつか削除しておく。

元のインクルードファイルは、一旦 /usr/include-x86_64 に rename して新しく作った glibc-headers と glibc の作成に使ったカーネルヘッダをベースにした。

で、基本は、cc1, cc1plus をクロスのものに置き換えて使う。

... これで良いかと思ったのだが、クロスは、/usr/mipsel-linux/include を要求する。これはシンボリックでごまかす。ただし、/usr/mipsel-linux/lib を作るとまずい。-ldl がないといったエラーは lib も作ったためのようで、かなりハマった。

良く知らないのだが、cc1 は cpp の機能も兼ねるのが原因みたい。__mipsel__ などの定義もクロスでは作っていないので、有効にならない。これも要注意。

binutils も実をいうと良くわからない。セルフで作った ld は、/usr/lib /lib を見てくれるが、クロス用はちょっと挙動が違うような ...

あと /usr/bin/ldd と /sbin/ldconfig は、新しく作った glibc のものと置き換えた。
pkgconfig

もともと pkgconfig は、/usr/lib64/pkgconfig に *.pc として作られている。
これらは、/lib64 などを参照するように書かれている。これらを全部書き換えるのではなく、
セルフ用に作った pkgconfig を使うようにしている。こうすると新しく作った /usr/lib/pkgconfig/*.pc のみを参照するようになる。

足りないものは、x86_64 の方から取ってきて書き換える。
linux/xx.h

Ingenic のカーネルヘッダが元だが、足りない定義がある。問題が起きるのは、audit など
```
    capability.h  falloc.h  netfilter.h
```
いまのところ上記を置き換えている。
libgcrypt

-DNO_ASM を指定するとなんとか。
elfutils

ビルドできていない。どうしたものか。
メモリ不足(空間不足)

解決できていない。gcc のビルドや、glibc のビルドで起きている。
chrpath
いんちき spec

rpm の依存関係がループしていたりするので、いきなり正しい rpm は作れない場合がある。こういうのは、とりあえず作っておいて、後で作り直す。

... で、そういう対応をしたものが実に多かったりする。特に python とか。

当面の目標は、python をビルドすること。これができると大分進んだことになる。
PATH_MAX

この定義がないのでエラーが起きるものがいくつかある。正しく修正したいが、どこを修正すべきか分かっていない。
valgrind ( arch がないというエラー )

とりあえず、python が出来た。だが、perl も rpm もビルドできていない。あとポイントになりそうなもので、mesa がある。

rpm にために必要なもので作れていないのは、elfutils と nss (nspr, nss-softokn, nss-util)
libtiff , tcp_wrappers

どうもおかしい。ちゃんとリンクできないみたいだ。

posted by すｚ at 00:46| Comment(0) | TrackBack(0) | 日記

この記事へのコメント

コメントを書く

この記事へのトラックバックURL
http://blog.sakura.ne.jp/tb/47630611
※ブログオーナーが承認したトラックバックのみ表示されます。

この記事へのトラックバック

日	月	火	水	木	金	土
			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30	31