Windows7(x64) 上で動く 32bit mode cygwin で ruby-1.9.x のテストを通そうとして苦闘する日々
RubyKaigi2011 でなんかつぶやいたので細々と苦闘してます。
環境
$ uname -a CYGWIN_NT-6.1-WOW64 mypc 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin $ gcc --version gcc (GCC) 4.3.4 20090804 (release) 1 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
目標
- ソースはThe Ruby Programming Language · GitHub
- configure はオプション指定しない
- define.h はいじらない
- ext/Setup はいじらない
- make が通ること
- 途中終了からの再開はあり
- make test が全部 OK になること
./miniruby.exe -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems ./tool/rubytest.rb ./miniruby.exe -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems "./bootstraptest/runner.rb" --ruby="ruby.exe -I./lib" -q ./miniruby.exe -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems "./bootstraptest/runner.rb" --ruby="ruby.exe" ./KNOWNBUGS.rb
-
- tool/rubytest.rb は OK
- bootstraptest/runner.rb で fork した子プロセスが死にまくってるので調査中(イマココ)
経過
dlopen した so のアドレスが変わってしまってるのかなぁ。変えちゃいけないルールとかあるのかなぁ
エラーを素直に解釈すれば、親プロセスでロード済みの so を子プロセスが参照しようとしたけど、親プロセスの持ってるアドレスと違ってるからダメー、と言ってるように見えるんだよなぁ
単純に fork した結果を眺めてみればいいのかな。それにしても sample の下は普通に実行できてて bootstrap の下だけうまくいかないとか分け分からん
さらに経過
わりと残念なことが分かった。
でも、多分余剰領域は無くてリトライしきって終わる。子は死ぬ。これが根っこらしい。
cygwin1.dll の fork を Vista/Windows7 以降の ASLR を無視するようにパッチ書くのは容易だ。
でも、それをやると多分ほかのプログラム(linux由来のやつ)が動かなくなる。
dll のベースアドレスが親子で違ってても動くというのは Vista/Windows7 に限らず他 OS でも普通にやってるはずなのだが、linux はやってなさそうなイメージがある。
(だからこそ親子で同一 dll のベースアドレスが同一でないとエラーにしているのだろうから)。
なんとなく対処は思い付くけど面倒そうだなぁ。
あと、やるだけの価値が特に無いなぁww。