Feature #5315
closed
config.hからコンパイラのバージョンチェックを外して欲しい
Added by kaoriya (Taro MURAOKA) about 13 years ago.
Updated about 13 years ago.
Description
http://www.garbagecollect.jp/ruby/mswin32/ja/
で配布しているrubyで確認したので外しているかもしれません。その場合はあしからず。
問題:
rubyの外部モジュールをコンパイルする際に、ruby本体と異なるバージョンのコンパイラではコンパイルできない
詳細:
上記で配布されているRubyはMSVC9でコンパイルされています。
一方VimなどネイティブでRubyとリンクする外部モジュールをMSVC10でコンパイルしようとした場合
Ruby配布物に含まれている include/ruby-1.9.1/x64-mswin64_80/ruby/config.h に
コンパイラのバージョンチェックがあるため、そのままでは利用できません。
#if _MSC_VER != 1400
#error MSC version unmatch: _MSC_VER: 1400 is expected.
#endif
提案内容:
なにか理由があってこうなっているのかもしれませんが、
手元で無効化して回避しても特に問題もなく使えているようです。
なのでこのチェック自体を破棄するか、もともとの理由に即したものに修正することを提案します。
- Status changed from Open to Third Party's Issue
そちらで配布されているものはRubyの公式な配布物ではありません。
当該サイトの『はじめに』のページに記載されている連絡先までお問い合わせください。
こんにちは、なかむら(う)です。
In message "[ruby-dev:44500] [Ruby 1.9 - Feature #5315][Open] config.hからコンパイラのバージョンチェックを外して欲しい"
on Sep.13,2011 19:35:15, koron.kaoriya@gmail.com wrote:
なにか理由があってこうなっているのかもしれませんが、
そりゃそうです。
手元で無効化して回避しても特に問題もなく使えているようです。
偶然です。
ちなみに、malloc'edなメモリブロック、ファイルディスクリプタ、
その他Cランタイムが管理するリソースをやり取りした場合、問題が
起きます。
これはCランタイムバージョン間の非互換に起因する問題なのでruby
にはどーにもできません。
なのでこのチェック自体を破棄するか、もともとの理由に即したものに修正することを提案します。
そうですね、ここはコンパイラのバージョンじゃなくて今ターゲッ
トとしているCランタイムのバージョンのチェックを行わないといけ
ないような気はします。
それでそちらが踏んでる問題に違いが生じる気がしないのがいささ
か残念ではありますが。
で、香り屋さんとこのVimとrubyは実のところ非常に疎な結合状況だ
と思うので、rubyのヘッダ/インポートライブラリを使ってリンクす
るんじゃなくて、実行時ロードにすれば全ての問題が解決するよう
に思ってるんですが、いかがなもんでしょうか?
って、数年前の知識で言ってるので今はもうそうなってたりして¶
それでは。¶
U.Nakamura usa@garbagecollect.jp
ダイナミックローディングについては最初から(VimにRubyが組み込まれた時から)なっています。
それでも最低限のヘッダーは必要なのでこの問題は起こります。
あとMSVCRTの話は確かにそのとおりで、それらをやり取りするとキツイですね。
逆に言うとそれらをやりとりするようなI/F設計にすべきではないとも言えます。
ただご指摘の通りVimのケースでは少ないか無いでしょう。
いずれにせよコンパイラのバージョンで拒絶するのは筋が違います。
それが解消したあとに起こるランタイムバージョン違いなどの問題については、
組み込んだ側の責任で良いんじゃないですか?
こんにちは、なかむら(う)です。
In message "[ruby-dev:44508] [Ruby 1.9 - Feature #5315] config.hからコンパイラのバージョンチェックを外して欲しい"
on Sep.13,2011 22:08:17, koron.kaoriya@gmail.com wrote:
ダイナミックローディングについては最初から(VimにRubyが組み込まれた時から)なっています。
あれ、では私が何かと混同してますね。これは失礼しました。
あとMSVCRTの話は確かにそのとおりで、それらをやり取りするとキツイですね。
逆に言うとそれらをやりとりするようなI/F設計にすべきではないとも言えます。
普通、rubyのヘッダって、rubyを組み込むのに使われるより、ruby
が外部のライブラリを取り込むための拡張ライブラリの方に使われ
ておりまして、そんなI/F設計はしたくはないんですが、外部のライ
ブラリさんはまあその...
いずれにせよコンパイラのバージョンで拒絶するのは筋が違います。
それが解消したあとに起こるランタイムバージョン違いなどの問題については、
組み込んだ側の責任で良いんじゃないですか?
rubyが拒絶してるのを回避するのは、俺は大丈夫だと確信を持って
る人が自分の責任でやればいいんじゃないですか?
rubyは現状安全側に倒すという選択をしていて、危険なことをした
い人こそ自力で頑張りなさい、そういうことしたい人なら幾らでも
回避できるやろそれくらい、っていうことになってるわけです。
これが絶対の方針で永久に維持する、とかいうわけじゃないですが、
Windows版に関係なくruby自体がもっとカジュアルに組み込める方向
に進化するとかしない限り、方針を変える気はあまりしないです。
でも、別の方向で説得してくれたら私の気分は変わるかもしれませ
ん。
例えば、ガードはするけどもっと筋のいいこういう方法がいいんじ
ゃね、とか。
それでは。¶
U.Nakamura usa@garbagecollect.jp
残念ながら筋の良いガードの仕方はないです。このあたりはWindowsのDLLの問題ですね。
それでもあえて言えばRubyがランタイムライブラリの生成するオブジェクトを、
I/Fを通じて外と直接やりとりする設計になってるのも筋は良くないね、とは指摘しておきます。
もちろんそんなことでI/Fを変えるのがコストに見合わないことは理解した上での「あえて」です。
Also available in: Atom
PDF
Like0
Like0Like0Like0Like0Like0