Mac OS Xでビルド †
- 10.3.9でしか試してないからTigerの人も確認ちょーだい
下準備 †
- MinGW32ようのコンパイラを用意（MinGW クロスコンパイラでぐぐるといいかも）
- Monoも用意。
- Monaのソースをダウンロードする。
- bim2bin.tar.bz2 fat_write.tar.bz2 config.tar.bz2をダウンロードする。
- ちなみにfat_writeとbim2binはtrunkに既にマージされています。此処のは使わないで。
- Monaのソースを展開した後、bim2binとfat_writeをMonaNew/tool/に、configをMonaNew/に入れる。
- MonaNew/core/PEAnalyzeLib/Makefile.incを弄ってMono対応にする。
MonaNewのビルド †
環境変数MONADIRをセットしてmakeする。
きっとビルド出来るはずだお（＾ω＾ ）
contribのビルド †
Makefileの中のMesa関連をコメントアウトしてmake
エラーでたらここに書いてちょーだい †
過去の遺物 †
題通り、しかしビルドに失敗、エラーログの最後の方はこちら
cd tool/mkimg && make clean && make
rm -f mona.img
make clean
rm -f mona.img
perl mkimg.pl
/Users/Yume/tmp/mona/build
cp /Users/Yume/tmp/mona/build/share/fat_write/fat_template.img mona.img
fat_write mona.img --mbr /Users/Yume/tmp/mona/build/bin/firstboot.bin
fat_write mona.img MONA.CFG MONA.CFG
can not create file
Died at mkimg.pl line 27.
make[1]: *** [all] Error 2
make: *** [all] Error 2
途中までmakeが通る奴
ビッグエンディアン対応のfat_write
コメント †
- こんにちは。環境がないのでなんともいえませんが、Intel Macでないのであればエンディアンの問題かもしれませんね。 -- ひげぽん
- そ れ だ ！ 明日にでもbim2binとfat_writeのソースを見てみます。 -- Yume
- それか。fopenのrb+とか？ -- ひげぽん
- fopenの方は問題なさそうです。が、やはりエンディアンがらみです。私が直そうにもソースを把握しきれません・・・ -- Yume
- エンディアンに依存してそうなところを抽出したらいいんですね。ちょい見てみまっす。 -- shadow
- 対象環境がないと開発がつらそうです。arm環境があるんですが、ixp425なんですよね。 -- shadow
- 一応ファイルの書き込みが出来るようになりましたが、ディレクトリ関連がまだ出来ておりません。もう少しかかるかもしれないです。 -- Yume
- すばらしい！ -- ひげぽん
- あとはEFI対応のブートローダがあればIntelMacで動くね！ --
- mkdir及びファイルの書き込みが完成しました。とりあえずMac OS Xでは動くと思いますが、他のプラットホームで動かすにはendian.cppを弄ってください。 -- Yume
- Mona用のコードも書きました。あと、先ほどアップロードしたfat_write.tar.bz2を削除していただけませんでしょうか？ -- Yume
- ありがとうございます。ファイル削除しました。fat_writeですがCVSにマージしようと思っていますがどうでしょうか? Intel MacはWindowsとおなじエンディアンとかいう罠がありそうですがautotoolsの練習で僕がやってもかまわないでしょうか? -- ひげぽん
- CVSへのマージはまだバグが有るかもしれないので、まって下さい。 -- Yume
- Intel MacとWindowsは同じエンディアンですね。だけどこのソースはMacではCoreFoundation使ってるんです。 -- Yume
- 了解しました。もう少し待ちます。 -- ひげぽん
- Monaが無事起動出来たのでマージしてOKです。 -- Yume
- やってて思うんですけどconfigureでbim2bin使わない設定とか出来たらいいな〜とか考えてますww -- Yume
- 対応お疲れ様です。把握できないとか言っといて、ささっとやっちゃうなんて、すごいですね。この調子で独自アプリも(何 -- shadow
- CVSへのマージの準備としてまずfat_writeをautotools対応にしました。http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/mona/MonaNew/tool/fat_write/ -- ひげぽん
- む。まずい。make installが微妙だ。修正中。 -- ひげぽん
- Mona用のエンディアン変換コードが他にも流用出来そうなのでパッチ作っときました。 -- Yume
- ↑は残念ながらパッチとして機能していません。パッチの作り方を参考にしてみてはいかがでしょうか。 --
- デバッグ用のメッセージとか抜いたやつアップしました。 -- Yume
- 祝。MaｃOS X進出。ということで、Yumeさん、fat.cppとendian.cpp/.hに名前入れません？ -- Gaku
- Yumeさんにお願いです。Yumeさんのコードを取り込んだものを用意しました。(Autotoolsに対応したものです）。Yumeさんの環境で意図通りに動作しているかご確認いただけないでしょうか。by ひげぽん
- 変更の詳細はここにに書いてあります。
- 確認してもらいたいポイントは以下の通りです。
- ./configure, make, make install, make unistall が動作するか
- fat_writeが正しく動作するか
- もしも気になる点がありましたらfat_write-0.0.1.tar.gzに上書きをする形で変更していただけると助かります。
- IStorageDevice.hが抜けていますよ。あと実行属性が付きまくっているので、パーミッションにも配慮した方が良いかと。 --
- Windows上でつくったtar玉は確か実行属性つく様な・・・ - Yume
- Windowsアプリで扱うと確かに自動的に実行属性が付きますが、Cygwinで処理すると区別して保持されますよ。 --
- IStorageDevice.hとfat_template.imgを入れないとmakeでこけるので、その二つを入れるとmakeできました。 -- Yume
- お二人ともご指摘･ご確認ありがとうございます。ファイルが足りないのはmake distがおかしかったせいです、追って修正します。実行属性はYumeさんのおっしゃるように特に何かをしているわけではないです。 （うまいやり方があったらぜひ教えてください）--ひげぽん
- Cygwinで扱う場合、圧縮する前にchmodするだけです。ExplorerなどWindowsアプリから触ったり（移動、コピー等）、Windowsの圧縮ツールで圧縮すると、自動的に実行属性が付きます。 --
- 補足ですが、FAT上のCygwinではパーミッションは決め打ちで実行属性が外せなかったはずです。chmodが有効なのはNTFS上だけのはずです。 --
- 念のためお聞きしますが実行属性がついているのは良くない（＝一律実行属性ととっておけ）ということですよね？ -- ひげぽん
- 一律というのは語弊があります。実行しないものには実行属性は付けませんが、install-shのように実行属性が付いていないといけないものもあります。何でも良いので他のAutotoolsを使った有名どころを取って来て確認すると良いかと。 --
- ありがとうございます。install-sh, configureに実行属性をつけるようにします。--ひげぽん
- あとついでですが、Autotoolsを使うとファイルがごちゃごちゃしてプロジェクト側で作成したソースが識別しにくくなるので、ルートディレクトリに全部突っ込むよりも、srcディレクトリ等を掘って入れた方がきれいです。 --
- なるほどありがとうございます。srcに移動するのは今気力がないのでやれたらやります。-- ひげぽん
- 実行属性(configure, install-shのみ)。足りないファイルを補いました。-- ひげぽん
- bim2binの方も対応が完了したのでうpしておきます。 -- Yume
- fat_writeがcygwinでcoredumpするので原因調査中。 -- ひげぽん
- cygwin&Linuxでは__LITTLE_ENDIAN__が定義されていないのが原因。-- ひげぽん
- Appleのgccの拡張かも知れません・・・＞__LITTLE_ENDIAN__ -- Yume
- ありがとうございます。 -- ひげぽん
- 上の問題に対応したつもりのfat_writeです。大変お手数ですがMac OS X環境でご確認できませんでしょうか。＞Yumeさん
- checking whether byte ordering is bigendian... yes となっているか？
- 実際に動くか?coredumpしないか？
- bim2binですが、endian-util.hにextern "C"が必要そうです。上記のbigendianチェックがうまくいっていることが確認できしだいautotools対応をしてCVSに追加いたします。 >Yumeさん -- ひげぽん
- checking whether byte ordering is bigendian... yesになってます。--mkdirが出来ないようです。 -- Yume
- ビルドし直したらできました。なんでだ？ -- Yume
- 見逃されるといけないので、ホットなこっちに書きます。「AC_C_BIGENDIANを使っても、きちんとユーザーがそのたびに ./configureすれば問題ないじゃん。」←そ〜ゆ〜問題じゃないです。詳しいことはこの辺（特に下のスクリーンショット参照）を見ていただければ分かると思いますが、ユニバーサルバイナリと言って、1つの実行ファイルの中にx86とPPCの両方のコードが入っているんです。つまり1回のコンパイルでx86とPPCの両方のコードが生成されるので、Linuxなどのように対象アーキテクチャごとにconfigureをやって別々のバイナリを作るわけではないのです。だからAutoconfの結果に頼れないということです。 --
- だからAppleのgccにはエンディアン判定用のマクロが用意されてる訳ですが・・・ -- Yume
- 理解しました。すっきりしました。となると、まずは「fat_writeのようなツールがユニバーサルバイナリとしてビルドされるのが当たり前」かどうかが知りたいですね。ユニバーサルバイナリが主流であれば、MAC OS Xかどうかで判断して切り替えないといけなさそうです。 そのあたりご意見いただきたく＞ななしさん。Yumeさん-- ひげぽん
- ユニバーサルバイナリにするにはgccに-archオプションを渡すのでソースからビルドの場合は気にしなくていいです。 -- Yume
- つまりオプションで指定しない限りユニバーサルバイナリにはならないってことです。 -- Yume
- なるほど。つまり。いまの./configure時にエンディアンをチェックする形式でよいということですね。理解できましたのでbim2binの対応も済ませようと思います。 -- ひげぽん
- ぶっちゃけ一番単純なのは、泥臭く演算することのような気がします。パフォーマンス的な面が気になりますが、少なくともエンディアンに左右されません。 --
inline uint32_t readu32(const unsigned char* src) {
return src[0] | (src[1] << 8) | (src[2] << 16) | (src[3] << 24);
}
inline void write(unsigned char* dst, uint32_t v) {
dst[0] = (unsigned char)(v & 0xff);
dst[1] = (unsigned char)((v >> 8) & 0xff);
dst[2] = (unsigned char)((v >> 16) & 0xff);
dst[3] = (unsigned char)(v >> 24);
}
fat_write-0.0.1-endian.tar.gz 787件
[詳細]
Mona1.png 641件
[詳細]
Mona2.png 658件
[詳細]
