Bug #4397
closed
test-mkmf fails due to compilation errors
Description
=begin
手元の環境では r30621 から以下のようにtest-allが失敗するようになっています。
http://www.atdot.net/sp/raw/vsnlgl
ちょっと変更の意図が分からないので説明していただけませんか。困っているので、特に意味が無いようであればrevertします。
あと以前から思っているのですが、ユーザーから渡されたコンパイルフラグを勝手に弄るのは感心しません。
=end
Updated by kosaki (Motohiro KOSAKI) about 13 years ago
=begin
2011年2月14日18:12 Shyouhei Urabe redmine@ruby-lang.org:
Bug #4397: test-mkmf fails due to compilation errors
http://redmine.ruby-lang.org/issues/show/4397起票者: Shyouhei Urabe
ステータス: Open, 優先度: Normal
ruby -v: ruby 1.9.3dev (2011-01-21) [x86_64-linux]手元の環境では r30621 から以下のようにtest-allが失敗するようになっています。
http://www.atdot.net/sp/raw/vsnlgl
ちょっと変更の意図が分からないので説明していただけませんか。困っているので、特に意味が無いようであればrevertします。
小崎です
微妙に当事者のような気がしなくもないのでご説明いたします。
まず、r30550で -Werror=implicit-function-declaration が自動的に付加されるように
変更されました。
これにより、#includeが漏れていてimplicit declarationが存在する
conftestが誤って失敗するようになり動かなくなったので、僕と近永さんでいくつか
テストを直しました（r30612, r30615, r30618）
最後に今回問題になっているr30621により根本修正としてconftest中は
-Werror=implicit-function-declaration が自動付加をしなくなりました。
r30621を入れる前にconfigure.inのテストはだいたい確認したので、revertしても
動くような気はしていますが、Linuxでしかテストしていないので他のOSでは
何か影響があるかもしれません。まあ、conftestのほうを直せばすむ話なので
大きな問題ではないと思います。
あと、うちのx86_64 linuxでは再現しないので、ディストリ、カーネル、libcの
それぞれのバージョンを教えてください。あと明示的に与えている configureと
makeのオプションも。可能な範囲で調査します。
あと以前から思っているのですが、ユーザーから渡されたコンパイルフラグを勝手に弄るのは感心しません。
こちらは経緯を知らないのでノーコメントでお願いします。
=end
Updated by shyouhei (Shyouhei Urabe) about 13 years ago
=begin
(2011/02/14 18:24), KOSAKI Motohiro wrote:
手元の環境では r30621 から以下のようにtest-allが失敗するようになっています。
http://www.atdot.net/sp/raw/vsnlgl
ちょっと変更の意図が分からないので説明していただけませんか。困っているので、特に意味が無いようであればrevertします。
小崎です
微妙に当事者のような気がしなくもないのでご説明いたします。
まず、r30550で -Werror=implicit-function-declaration が自動的に付加されるように
変更されました。これにより、#includeが漏れていてimplicit declarationが存在する
conftestが誤って失敗するようになり動かなくなったので、僕と近永さんでいくつか
テストを直しました（r30612, r30615, r30618）最後に今回問題になっているr30621により根本修正としてconftest中は
-Werror=implicit-function-declaration が自動付加をしなくなりました。
r30621の問題点は
warnflags=
としてユーザーが与えたフラグを一切無視するようになっている点なので、ようするに
殺しすぎです。下に記したとおり私の環境ではwarnflagsでわざわざ-Wno-long-longと
して警告を抑制していたのに、その抑制まで取り去っているのが誤り。
r30621を入れる前にconfigure.inのテストはだいたい確認したので、revertしても
動くような気はしていますが、Linuxでしかテストしていないので他のOSでは
何か影響があるかもしれません。まあ、conftestのほうを直せばすむ話なので
大きな問題ではないと思います。
ではrevertする方向で。
あと、うちのx86_64 linuxでは再現しないので、ディストリ、カーネル、libcの
それぞれのバージョンを教えてください。あと明示的に与えている configureと
makeのオプションも。可能な範囲で調査します。
おおむねの情報は実はさっき出したURLをたどると書いてあるのですがさすがに長すぎ
て読めないはずなので、抜粋すると、
- Debian lenny (1/21だったので), port amd64 (i386でも現象確認済み)
- gcc-4.3 4.3.2-1.1
- libc6 2.7-18lenny7
- linux-image-2.6.32-26-server 2.6.32-26.48
- configureのオプションは、
/bin/sh /src/configure
--cache-file=config.cache
--prefix=/usr/local
--enable-install-doc
--with-valgrind
CPPFLAGS="-D_FORTIFY_SOURCE=2 -D_BSD_SOURCE -D_SVID_SOURCE -D_POSIX_SOURCE -D_POSIX_C_SOURCE=200809L"
optflags="-pipe -O0 -march=athlon64 -mcmodel=large"
warnflags="echo -W{all,extra,undef,no-{format,long-long,parentheses,unused,sign-compare,missing-field-initializers}}"
debugflags="-ggdb3 -std=iso9899:199409 -pedantic" - makeにはオプションは付けていない
これでもまだ長いと思われるので更に解説すると、debugflagsによりgccはstrict ansi
modeになっており、warnflagsで数々のgcc拡張機能を使ったときの警告を抑制していま
す。なのでwarnflagsだけ切られるとstrict ansiとしてコンパイルしようとして失敗す
るわけ。
=end
Updated by kosaki (Motohiro KOSAKI) about 13 years ago
=begin
これでもまだ長いと思われるので更に解説すると、debugflagsによりgccはstrict ansi
modeになっており、warnflagsで数々のgcc拡張機能を使ったときの警告を抑制していま
す。なのでwarnflagsだけ切られるとstrict ansiとしてコンパイルしようとして失敗す
るわけ。
親切にありがとうございます。今後は時間のあるときはこのオプションでもテストするようにします。
ところで、素朴な疑問なんですが、これの意図は？「gcc拡張をうっかり使ってしまってportabilityが下がるのを防ぎたい」という意図であればデフォルトでこのオプションになるようにすべきではないんでしょうか？
今のままだと自然に卜部さんだけが問題にあたって「ぎゃっ」と叫ぶ構図になっているんじゃないかと思いますがどうでしょうか
=end
Updated by shyouhei (Shyouhei Urabe) about 13 years ago
=begin
(2011/02/14 19:33), KOSAKI Motohiro wrote:
ところで、素朴な疑問なんですが、これの意図は？「gcc拡張をうっかり使ってしまってportabilityが下がるのを防ぎたい」という意図であれば
はい。防ぎたいというか検出したいと思ってこのような設定になっています。したがっ
てあまり警告がたくさん出ると埋もれてしまって嬉しくないです。
デフォルトでこのオプションになるようにすべきではないんでしょうか？
今のままだと自然に卜部さんだけが問題にあたって「ぎゃっ」と叫ぶ構図になっているんじゃないかと思いますがどうでしょうか
しかしデフォルトにしちゃうのはどうなのかなあ。きっとgcc拡張に依存している拡張
ライブラリとかいっぱいありそうに思うので、デフォルトまで行っちゃうとちょっとや
りすぎのような気もします。あくまで私の環境では素のrubyしかコンパイルしないから
ここまできつい制限でも赦されているという気がする。
=end
Updated by mame (Yusuke Endoh) about 13 years ago
=begin
遠藤です。
2011年2月14日19:53 Urabe Shyouhei shyouhei@ruby-lang.org:
デフォルトでこのオプションになるようにすべきではないんでしょうか？
今のままだと自然に卜部さんだけが問題にあたって「ぎゃっ」と叫ぶ構図になっているんじゃないかと思いますがどうでしょうかしかしデフォルトにしちゃうのはどうなのかなあ。きっとgcc拡張に依存している拡張
ライブラリとかいっぱいありそうに思うので、デフォルトまで行っちゃうとちょっとや
りすぎのような気もします。あくまで私の環境では素のrubyしかコンパイルしないから
ここまできつい制限でも赦されているという気がする。
素の Ruby でも、gcc 拡張が使える場合は使ってるはずです。
具体的には、YARV が labels as values を使って direct threaded code を
実装してます。もしそれらのオプションでこの最適化が効かなくなるのだとしたら
問題です。
--
Yusuke Endoh mame@tsg.ne.jp
=end
Updated by shyouhei (Shyouhei Urabe) about 13 years ago
=begin
(2011/02/14 20:05), Yusuke ENDOH wrote:
遠藤です。
2011年2月14日19:53 Urabe Shyouhei shyouhei@ruby-lang.org:
デフォルトでこのオプションになるようにすべきではないんでしょうか？
今のままだと自然に卜部さんだけが問題にあたって「ぎゃっ」と叫ぶ構図になっているんじゃないかと思いますがどうでしょうかしかしデフォルトにしちゃうのはどうなのかなあ。きっとgcc拡張に依存している拡張
ライブラリとかいっぱいありそうに思うので、デフォルトまで行っちゃうとちょっとや
りすぎのような気もします。あくまで私の環境では素のrubyしかコンパイルしないから
ここまできつい制限でも赦されているという気がする。素の Ruby でも、gcc 拡張が使える場合は使ってるはずです。
具体的には、YARV が labels as values を使って direct threaded code を
実装してます。もしそれらのオプションでこの最適化が効かなくなるのだとしたら
問題です。
あわてて補足しておくと、手元のはあくまでうっかりミスの防止が目的で、ちゃんと
configureで使えるかどうか判定してから使えない場合の次善策をきちんと提供した上
で使う分にはいいのではないでしょうか。VMが可能な場合に限りgoto labelしているの
を悪いことだとは思いません。
ただしそれがいいためにはconfigureで走らせるテストが実際にコンパイルするときと
完璧に同じ状況である必要があるはずで、でないと正しく判定できないはずなのであ
り、ユーザーからもらったフラグを弄るなという主張はつまり弄ってしまうと
configureの結果が信用できなくなるという主張でもあります。今回のように。
=end
Updated by shyouhei (Shyouhei Urabe) about 13 years ago
- Status changed from Open to Closed
- % Done changed from 0 to 100
=begin
This issue was solved with changeset r30872.
Shyouhei, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.
- configure.in: revert r30621. That revision introduced mkmf test
failures and it turned out to be OK to revert. [ruby-dev:43203]
=end
Updated by kosaki (Motohiro KOSAKI) about 13 years ago
=begin
最後に今回問題になっているr30621により根本修正としてconftest中は
-Werror=implicit-function-declaration が自動付加をしなくなりました。r30621の問題点は
warnflags=
としてユーザーが与えたフラグを一切無視するようになっている点なので、ようするに
殺しすぎです。下に記したとおり私の環境ではwarnflagsでわざわざ-Wno-long-longと
して警告を抑制していたのに、その抑制まで取り去っているのが誤り。
この説明に引っかかるところがあったので調べ直しました。
なぜなら warnflags= は if test "$GCC:${warnflags+set}:no" = yes::no; then のif文の中にあるので
warnflagsを指定したときは通らないはずだからです。
結論からいうと、
もしwarnflagsが未指定でGCCなら¶
if test "$GCC:${warnflags+set}:no" = yes::no; then
warnflagsを一時的に空にして、それをrb_cv_warningsに保存¶
rb_cv_warnflags="$warnflags"
warnflags=
fi
(いろいろやって、スクリプトの最後で)
warnflags="$rb_cv_warnflags"
となっているのですが、warnflagsを指定するとrb_cv_warnflagsが初期化されないので、スクリプトの
最後の warnflags="$rb_cv_warnflags" でwarnflagsが空になってしまいます。よって添付のように
rb_cv_warnflagsの初期化位置をずらしてやれば卜部さんの configure optionでもコンパイル出来ることを
確認しました。
コンパイル不能以外に反対理由がないのであれば、中田さんの意思を尊重して再コミットしようかとも
思うのですが、ご意見お聞かせください。
Attachment: 0001-patch.patch
=end
Updated by shyouhei (Shyouhei Urabe) about 13 years ago
=begin
卜部です。
(2011/02/14 21:43), KOSAKI Motohiro wrote:
結論からいうと、
もしwarnflagsが未指定でGCCなら¶
if test "$GCC:${warnflags+set}:no" = yes::no; then
warnflagsを一時的に空にして、それをrb_cv_warningsに保存¶
rb_cv_warnflags="$warnflags"
warnflags=
fi
(いろいろやって、スクリプトの最後で)
warnflags="$rb_cv_warnflags"となっているのですが、warnflagsを指定するとrb_cv_warnflagsが初期化されないので、スクリプトの
最後の warnflags="$rb_cv_warnflags" でwarnflagsが空になってしまいます。よって添付のように
rb_cv_warnflagsの初期化位置をずらしてやれば卜部さんの configure optionでもコンパイル出来ることを
確認しました。
なるほど。
コンパイル不能以外に反対理由がないのであれば、中田さんの意思を尊重して再コミットしようかとも
思うのですが、ご意見お聞かせください。
いえ、コンパイル不能以外には理由はありません。
=end