Feature #5053

ruby コマンドと libruby の食い違いチェック

Added by Makoto Kishimoto almost 4 years ago. Updated over 2 years ago.

[ruby-dev:44156]
Status:Rejected
Priority:Low
Assignee:Nobuyoshi Nakada

Description

ビルドした ruby を、インストールせずに、ビルドディレクトリで ./ruby のように実行すると、実行する ruby コマンドと、ロードされる libruby でバージョンが食い違うことがありますが、その警告というのは(バイナリライブラリに互換性がないバージョンだったりしなければ)特に出たりしません
たまにはまることがあるので、main.c 中で RUBY_DESCRIPTION マクロと、グローバル変数 ruby_description で一致するかどうかを調べて、違うようならウォーニングを出す、というパッチです
(※基本的なアイディアはえぐちさんによるものです)

patch-revisioncheck.txt Magnifier (1.23 KB) Makoto Kishimoto, 07/19/2011 02:20 PM

No5053.pdf - [ruby-dev:45708] コンペ向けの資料 (17.5 KB) Makoto Kishimoto, 06/24/2012 05:10 PM

0001-revision-check.patch Magnifier (4.97 KB) Nobuyoshi Nakada, 07/21/2012 08:34 PM

History

#1 Updated by Anonymous almost 4 years ago

ビルドした ruby を、インストールせずに、ビルドディレクトリで ./ruby のように実行すると、実行する ruby コマンドと、ロードされる libruby でバージョンが食い違うことがありますが、その警告というのは(バイナリライブラリに互換性がないバージョンだったりしなければ)特に出たりしません
たまにはまることがあるので、main.c 中で RUBY_DESCRIPTION マクロと、グローバル変数 ruby_description で一致するかどうかを調べて、違うようならウォーニングを出す、というパッチです
(※基本的なアイディアはえぐちさんによるものです)

./configure --program-suffix=hogehoge とかしても librubyは上書きされて消えてしまうので、
以前すごくイライラした記憶があるんですけど、そもそもlibrubyにバージョン番号か、
program suffixをつけるべきな気がしてるんですよね。

衝突を検知するよりも、衝突しない方向に頑張る方が前向きな気がするんですよ。はずしてるかなぁ

#2 Updated by Anonymous almost 4 years ago

ビルドした ruby を、インストールせずに、ビルドディレクトリで ./ruby のように実行すると、実行する ruby コマンドと、ロードされる libruby でバージョンが食い違うことがありますが、その警告というのは(バイナリライブラリに互換性がないバージョンだったりしなければ)特に出たりしません
たまにはまることがあるので、main.c 中で RUBY_DESCRIPTION マクロと、グローバル変数 ruby_description で一致するかどうかを調べて、違うようならウォーニングを出す、というパッチです
(※基本的なアイディアはえぐちさんによるものです)

./configure --program-suffix=hogehoge とかしても librubyは上書きされて消えてしまうので、
以前すごくイライラした記憶があるんですけど、そもそもlibrubyにバージョン番号か、
program suffixをつけるべきな気がしてるんですよね。

衝突を検知するよりも、衝突しない方向に頑張る方が前向きな気がするんですよ。はずしてるかなぁ

#3 Updated by Makoto Kishimoto almost 4 years ago

きしもとです

./configure --program-suffix=hogehoge とかしても librubyは上書きされて消えてしまうので、
以前すごくイライラした記憶があるんですけど、そもそもlibrubyにバージョン番号か、
program suffixをつけるべきな気がしてるんですよね。

衝突を検知するよりも、衝突しない方向に頑張る方が前向きな気がするんですよ。はずしてるかなぁ

FreeBSD だと ruby18 と ruby19 という ports になってますが、1.8.?
では "libruby18.so" 、1.9.? では "libruby.so" という名前になるので
たまたま /usr/local/lib に共存できてたりしてます。

r23368 より前では、configure.in で RUBY_SO_NAME='$(RUBY_INSTALL_NAME)'
となっているので、program suffixが影響するわけですね。r23368 の変更は
からの議論の結果によるもののようです。

#4 Updated by Makoto Kishimoto almost 4 years ago

きしもとです

./configure --program-suffix=hogehoge とかしても librubyは上書きされて消えてしまうので、
以前すごくイライラした記憶があるんですけど、そもそもlibrubyにバージョン番号か、
program suffixをつけるべきな気がしてるんですよね。

衝突を検知するよりも、衝突しない方向に頑張る方が前向きな気がするんですよ。はずしてるかなぁ

FreeBSD だと ruby18 と ruby19 という ports になってますが、1.8.?
では "libruby18.so" 、1.9.? では "libruby.so" という名前になるので
たまたま /usr/local/lib に共存できてたりしてます。

r23368 より前では、configure.in で RUBY_SO_NAME='$(RUBY_INSTALL_NAME)'
となっているので、program suffixが影響するわけですね。r23368 の変更は
からの議論の結果によるもののようです。

#5 Updated by Usaku NAKAMURA over 3 years ago

パッチがこれでいいかどうかは確認してませんが、このチェックを入れることには
賛成します。

個人的には警告でなくエラーでいいと思う。

回避の努力自体はもうそれなりに入ってるので、それはそれ、これはこれ、
ということで。

#6 Updated by Makoto Kishimoto over 3 years ago

コンパイルした時刻のunix timeを埋め込んで、とかいうのも考えましたが、
そうするとちょっとオーバーキルかな、と思いました

#7 Updated by Takahiro Kambe over 3 years ago

In message redmine.journal-19373.20110720134723@ruby-lang.org
on Wed, 20 Jul 2011 13:47:24 +0900,
Makoto Kishimoto redmine@ruby-lang.org wrote:

Issue #5053 has been updated by Makoto Kishimoto.

コンパイルした時刻のunix timeを埋め込んで、とかいうのも考えましたが、
そうするとちょっとオーバーキルかな、と思いました
同じソースコードから作成される限り、コンパイルした日時に関わらず同じ
実行ファイルとなった方が嬉しいと思います。

--
神戸 隆博 (かんべ たかひろ) at 仕事場

#8 Updated by Takahiro Kambe over 3 years ago

In message redmine.journal-19373.20110720134723@ruby-lang.org
on Wed, 20 Jul 2011 13:47:24 +0900,
Makoto Kishimoto redmine@ruby-lang.org wrote:

Issue #5053 has been updated by Makoto Kishimoto.

コンパイルした時刻のunix timeを埋め込んで、とかいうのも考えましたが、
そうするとちょっとオーバーキルかな、と思いました
同じソースコードから作成される限り、コンパイルした日時に関わらず同じ
実行ファイルとなった方が嬉しいと思います。

--
神戸 隆博 (かんべ たかひろ) at 仕事場

#9 Updated by Makoto Kishimoto over 3 years ago

同じソースでも違うバイナリになることも問題かと思いますが、一種の個体追跡
(CPUの個体IDのような)のようなことに使えるのも問題かなと思いました。

ソースコードのとバイナリの同一性を重視するのであれば、指定したファイルの
ハッシュ値とかになるでしょうかね?

#10 Updated by Kenta Murata about 3 years ago

同じソースでもコンパイルオプションを変えれば異なるバイナリが生成される可能性は十分ありますから、ソースの同一性だけでは判定できない気がします。

#11 Updated by Yusuke Endoh about 3 years ago

  • Assignee set to Masaya Tarui
  • Status changed from Open to Assigned

#12 Updated by Makoto Kishimoto almost 3 years ago

コンペ向けの資料を添付

#13 Updated by Yusuke Endoh almost 3 years ago

資料受け取りました。
(よく読んでませんが) これ、まつもとさんの認可が必要な内容なんですかね。
なかださんか誰かが勝手にやってしまえばいいレベルの話な気も。
まあ一応聞いてみます。

#14 Updated by Nobuyoshi Nakada almost 3 years ago

正直なところ何が嬉しいのかさっぱりだったので放っておいたのですが…。

バージョンが一致しないlibrubyがロードされると嬉しくないのは同感なのですが、このチェックによって ./ruby が実行できなくなるとそのストレスは解消するものなんでしょうか。

#15 Updated by Nobuyoshi Nakada over 2 years ago

  • File 0001-revision-check.patch added
  • Status changed from Assigned to Feedback

ちょっと前(r36277)に、Makefileにrunnableというターゲットを追加しました。
今のところLinuxとMac OS Xしか対応していませんが、--enable-load-relativeを指定しておくと./bin/rubyでビルドしたバイナリが実行できるはずです。
こういったものではまずいでしょうか。

一応、RUBY_REVISIONとconfig.hのチェックサムで一致しない場合にエラーになるようにするパッチも作ったは作ったので、置いておきます。

ちなみに、私は https://github.com/nobu/build-files/blob/master/ruby.rb のようなラッパーで実行しています。

#16 Updated by Nobuyoshi Nakada over 2 years ago

  • File deleted (0001-revision-check.patch)

#17 Updated by Nobuyoshi Nakada over 2 years ago

テスト用にconfigureオプションを消していたのを忘れてました。

#18 Updated by Yusuke Endoh over 2 years ago

  • Assignee changed from Masaya Tarui to Nobuyoshi Nakada

きしもとさん

これはなかださんに一任となりました。
まつもとさんの意見は以下の 2 点です。

  • fail early の観点で、よい実装方法があるなら取り込みたい

  • ただし RUBY_DESCRIPTION を使うのはよい実装方法と思わない

Yusuke Endoh mame@tsg.ne.jp

#19 Updated by Yusuke Endoh over 2 years ago

  • Status changed from Feedback to Assigned

なかださん、いかがお過ごしでしょうか

Yusuke Endoh mame@tsg.ne.jp

#20 Updated by Yusuke Endoh over 2 years ago

  • Status changed from Assigned to Rejected

2012年11月20日 23:30 Nobuyoshi Nakada nobu@ruby-lang.org:

(12/11/20 23:18), mame (Yusuke Endoh) wrote:

なかださん、いかがお過ごしでしょうか

いい具合でゴキゲンですが、でも書いたように解決の方針がそもそも明後日ではないかと思います。

一任されたなかださんがその意見なら、このチケットは rejected でよろしいかと思います。

Yusuke Endoh mame@tsg.ne.jp

#21 Updated by Nobuyoshi Nakada over 2 years ago

(12/11/20 23:18), mame (Yusuke Endoh) wrote:

なかださん、いかがお過ごしでしょうか

いい具合でゴキゲンですが、でも書いたように解決の方針がそもそも明後日ではないかと思います。

--
--- 僕の前にBugはない。
--- 僕の後ろにBugはできる。
中田 伸悦

Also available in: Atom PDF