Mona/C++の例外とRTTI/02.ななしさんログ


Top / Mona / C++の例外とRTTI / 02.ななしさんログ

02.ななしさんログ

経緯

ななしさんとの会話 http://d.hatena.ne.jp/higepon/20110824/1314195216#c をこちらにコピー。

ななしさん 2011/08/27 06:29
先生!正攻法が駄目な理由をもっとツッコむと具体的にはどんな感じですか!
作るのが面倒とか保守が面倒とか既存ソースの移行が面倒とか開発ツールの移行が面倒とか!

 higepon 2011/08/27 07:05

それらを含めて時間があればと書いています。
いつかはやらなくてはいけないという意味で。

 ななしさん 2011/08/27 08:08

回答ありがとう!gccのビルド時間もクソ長いことなので、
トライアンドエラー諸々含めて正直面倒臭そうとは思った!

 higepon 2011/08/27 08:45

そうですね。面倒でした。ビルドオプションで色々削っているので遅いマシンで15分くらいでした。>ビルド

 ななしさん 2011/09/06 10:17

捨てる程時間があったのでMona用のgccとlibsupc++/libgccを作ってみた!
俺のマシンは余裕でその4倍以上の時間がかかる遅さだった!
RTTI抜きのICUは確保出来てるようなので今更なんだけどね!
需要があればMona用gccのビルド方法なりlibsupc++/libgccのバイナリなりを何らかの形で晒すよ!
今重要でなくともその内役に立つかもしれないので、差し当たりレポートを残す。超長いよ。

やってみて分かったことは、gccをMona用に作っても別に問題は解決しないということ。
newはMonAPIの中でも使われていてlibsupc++にはmalloc/free/abortが最低限要るので、
今のMonaのライブラリ構成に修正を入れないとMonAPIとlibsupc++で相互依存になる。
解決方法として思い付くのは
1. MonAPI側でnewを提供し、例外抜きで使う場合は-fno-exceptionsとnothrow版newの利用を強制
2. malloc/free/abort相当のものを最下層に実装、その上にlibsupc++(new入り)、その上にMonAPI
1の場合は(monapi)→(libsupc++)→(アプリ)というような依存関係、
2の場合は(libmallocfreeabort)(libsupc++)→(monapi)→(アプリ)というような依存関係になるよ!
どっちもそれで問題無く機能するかまでは試してない。

ライブラリが相互依存になっていると、リンカに

現状libsupc++/libgccのバイナリを配布して各自のMinGW環境に突っ込ませるのが良さそうな気がする。
ただバイナリ配布にしても、どのgccのバージョンを基準にしていくかは悩むところ。
MinGWのgccバイナリを使えば他のクロスコンパイラを用意する必要が無い、をどの程度重視するか。
一切重視せずクロスコンパイラ用意を前提にするなら、Mona用gcc路線がアリな話になってくる。

Mona用gccを用意する路線の場合、libtool本家にconfig.sub/config.guessへの修正取り込んでもらわないと
autotoolsなconfigureの為にいちいち手作業でconfig.sub/guessの修正が要るので、少しだけ面倒増えるかも。
修正しないとi[34567]86-pc-monaosとかのtrippletがconfigureで弾かれてしまう。
一旦本家に取り込まれれば、長い目で見てOSSの移植が楽になるかもしれないけどね。無駄にハクも付くし、
何よりOSSを移植した際にmona用の変更部分を本流に取り込んでもらいやすくなる。
実際に取り込まれるかどうかは多分外人の気分次第。SkyOSとかAtheOS、Syllableとかも既に入ってはいる。

現状でMona用gccの必要性がまだ分かっていないので、今はMinGW用のgccをビルドする過程で
libsupc++の依存が少ない版(_GLIBCXX_HOSTEDで分岐)を作るための手順を探してる。

ひげぽんに例外RTTIサポートに関していつか自分でやらなければいけない、やりたいという思い、
つまりおいテメェ勝手に俺のプリン食ってんじゃねええええええ的なアレがあれば余計なことはしないよ!
Monaはひげぽんのプリンだ!俺のじゃない!
逆に、やって欲しいことがあれば時間の在庫が切れるまでは試してみようと思うので
何か要望があれば言ってくれ。コレ試せとかアレ試せ系のが何かあれば。死ぬほど暇だから!

 higepon 2011/09/06 12:32

いくら時間があったとはいえ Mona のために時間を割いて頂いてありがとうございます。
少し長くなりそうなので 1 つのお願いと 2 つの選択肢を先に書いておきます。

■お願い
ななしさんの現時点での成果を一切無駄にしないために、可能でしたら簡単な作業ログを http://wiki.monaos.org/ に適当なページを作って書いてもらえないでしょうか。ページ名は適当で良いです。あとでリネームします。
書いて欲しいのは

■選択肢1
C++ の例外/rtti 対応はメモを残すにとどめて今回はあきらめる。

■選択肢2
もしななしさんがある程度の時間を使ってくださるならば理想と現実の間の落とし所を
私と検討してもらって成果を取り込んで 例外/rtti を入れる。

■以下詳細

前提:現状の Mona はほぼ僕一人しか開発者がいません。これは重要な前提。

もしも僕に多くの時間があり、長い期間コミットしてくれる専任の協力者がいるのであれば実現したい理想は

ですがそれは現実的ではありません。

今の現実は

さて ICU 問題は解決したので今のところ例外や rtti は強くは必要とはされていません。
なのでそれらの機能は Webkit 移植や Mona を毎日使っていき少しずつ改善していくことに比べたらかなり優先度が下がってしまいます。
もちろん例外や rtti は他の多くのプラットフォームでは存在するのであるに越したことはありません。

となるとそれらの導入をする場合以下の条件が成立する必要があると考えてます。

これは言い換えると

ということになります。これが 選択肢2 を書いた意図です。
以下コメントに対するお返事をインラインで書いて行きます。

 今重要でなくともその内役に立つかもしれないので、差し当たりレポートを残す。超長いよ。

ありがとうございます。あとに続く人たちのためにもこういうレポートは大変ありがたいです。

 やってみて分かったことは、gccをMona用に作っても別に問題は解決しないということ。

 今のMonaのライブラリ構成に修正を入れないとMonAPIとlibsupc++で相互依存になる。

はい。私も結局それにぶちあたりました。正しい認識だと思います。

1. MonAPI側でnewを提供し、例外抜きで使う場合は-fno-exceptionsとnothrow版newの利用を強制

 2. malloc/free/abort相当のものを最下層に実装、その上にlibsupc++(new入り)、その上にMonAPI

2 のほうが好みです。自分がこの作業をやったときは libgcc.a と libsupc++ を MONAPI.DLL に含めてしまうことにトライしました。
もう少しでうまく行きそうだったのですが。あれなんでやめたんだっけか。

ライブラリが相互依存になっていると、リンカに

--start-group -lmonapi-imp -lsupc++ -lgcc --end-group

こんなオプションあるんですね。知らなかった。

現状libsupc++/libgccのバイナリを配布して各自のMinGW環境に突っ込ませるのが良さそうな気がする。

はい。賛成です。

ただバイナリ配布にしても、どのgccのバージョンを基準にしていくかは悩むところ。

ライブラリを作るのがそこまで手間でなければ

Ubuntu の mingw が 4.6 系になったらそれ一本で。c++0x の auto などを使いたいので 4.6 のほうがうれしいんですよね。

MinGWのgccバイナリを使えば他のクロスコンパイラを用意する必要が無い、をどの程度重視するか。

一切重視せずクロスコンパイラ用意を前提にするなら、Mona用gcc路線がアリな話になってくる。

上にも書きましたが現時点では Mingw を使い続けるのが現実的であると考えています。

ひげぽんに例外RTTIサポートに関していつか自分でやらなければいけない、やりたいという思い、

つまりおいテメェ勝手に俺のプリン食ってんじゃねええええええ的なアレがあれば余計なことはしないよ!

Monaはひげぽんのプリンだ!俺のじゃない!

例外RTTI プリンは僕のプリンじゃありません!

逆に、やって欲しいことがあれば時間の在庫が切れるまでは試してみようと思うので

何か要望があれば言ってくれ。コレ試せとかアレ試せ系のが何かあれば。死ぬほど暇だから!

上に書いたとおり、ななしさんの動機とどれだけ時間を使っていただけるかで選択肢 1, 2 のどちらかを選んでいただければと思います。
もし 2 ならば詳細はまた相談させてください!

 ななしさん 2011/09/06 13:37

OKならこいつは俺が食っていいプリンだ!

■お願い
Wikiへの文書化は了解した。

■選択肢1

C++ の例外/rtti 対応はメモを残すにとどめて今回はあきらめる。

■選択肢2

もしななしさんがある程度の時間を使ってくださるならば理想と現実の間の落とし所を

私と検討してもらって成果を取り込んで 例外/rtti を入れる。
まずは現状の成果についてWikiへメモを残す。その上で、
ぶっちゃけ急務でないのでそちらの好きなタイミングで口出ししてくれていい。

前提:現状の Mona はほぼ僕一人しか開発者がいません。これは重要な前提。
一人か!ロックだな!減ったな!けど重要な情報だ!

さて ICU 問題は解決したので今のところ例外や rtti は強くは必要とはされていません。
これは理解してる。

- Mingw のままで C++ 例外・rtti をサポートする
ひげぽんがUbuntuで開発していてそれ以外の環境をそこまで気にかけなくていいなら、
1. 最初はMingwへのライブラリ追加で対応
2. ELFサポートの強化
3. ELFベースへの移行により、Linux用コンパイラへのライブラリ追加orで済ます
という具合に段階的に移行するルートの可能性も生まれる。
ELFサポートの強化やLinux用コンパイラが使えるかの検証はこちらでやれるだけ試す。

2 のほうが好みです。
手元で2案を試してみて、動きそうならgithubの方へpull requestを送る。
実は個人的には1案も結構気に入っている!2優先で余裕あれば両方試してみる。

- Ubuntu mingw gcc 4.5.1? (apt-get ではいるやつ)

- gcc 4.6.1
バイナリ配布時はその方向で進める。

Ubuntu の mingw が 4.6 系になったらそれ一本で。c++0x の auto などを使いたいので 4.6 のほうがうれしいんですよね。
D言語好きなのでautoが無いなんて考えられねえ!

もし 2 ならば詳細はまた相談させてください!
当面2。やる気が無くなったらちゃんと言う!
Wikiのページ作ったらそちらは見るようにするので、必要があればそっちででもどこででも言ってくれ!

長いのに付きあってもらって悪いね!えーとWebKit上手くいきますようにって念送っとくわ!

コメント

コメントはありません。 コメント/Mona/C++の例外とRTTI/02.ななしさんログ?

お名前:

MENU

now: 6

リンク


最新の20件
2018-10-07 2018-09-20 2018-09-03 2018-05-09 2017-09-29 2017-01-10 2016-12-11 2016-10-04 2016-08-14 2016-05-29 2015-12-28 2013-02-25 2013-02-21 2013-02-20 2013-02-12 2013-02-11 2013-02-10
最新の20件
2010-02-01 2010-01-31 2010-01-30 2010-01-29 2010-01-16

Counter: 1089, today: 1, yesterday: 1

リロード   新規 編集 凍結 差分 添付 複製 改名   トップ 一覧 検索 最終更新 バックアップ   ヘルプ   最終更新のRSS

Last-modified: 2011-09-06 (火) 17:11:59 (2628d);  Modified by mona
PukiWiki 1.4.6 Copyright © 2001-2005 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji
Powered by PHP 5.2.17
HTML convert time to 0.052 sec.