[#14922] alias $gvar — Koji Arai <JCA02266@...>

新井です。

19 messages 2001/10/14

[#15006] Re: eval.c (rb_stack_check): prohibit recursive raising error — WATANABE Hirofumi <eban@...>

わたなべです。

13 messages 2001/10/26
[#15008] Re: eval.c (rb_stack_check): prohibit recursive raising error — Shugo Maeda <shugo@...> 2001/10/26

前田です。

[ruby-dev:14879] Re: ruby-1.6.5 MacOS X 10.1 patch

From: SHIROYAMA Takayuki <psi@...>
Date: 2001-10-03 18:48:27 UTC
List: ruby-dev #14879
しろやまです。

>
> インストール前はminirubyを指して、インストール後は
> インストールされたrubyを指すようなマクロがあれば
> 記述できるのですが、あるわけ無いですよね。
>

実際の所、librubyを作るときに undefinedになるシンボルって
_environだけなんですよ。

なので、なんとかして crt1.oにある _environを ldに教え込
ませる事ができれば、-bundle_loaderはそもそも不要になります。
モジュールを ruby以外のバイナリがロードする可能性(たとえば
erubyとか)を考えるなら、-bundle_loaderは使わないに越した事
ないです。

しかし、どーやったら crt1.oをldがみてくれるのか、__environ
のシンボルをldが認識してくれるのか私にはわからなくて...
# こんなくだらない事で悩んでいるより、今まで通りにすればいける
# ので、さくっと送ったのがあのパッチというわけです。

ぱっと思いつく回避策は、

LDSHARED='cc -dynamic -bundle -bundle_loader /usr/lib/crt1.o '

です。こうすると、_environへの参照は解けるのでとりあえずは
動きます。が、こんどは bundleの頭に着く bundle1.oとのシン
ボルの衝突が出るのでワーニングがばかばか出てうるさいです(--;

しかし、これで拡張モジュールは two_level_namespaceで動くので
すが、libruby.dylibが flat_namespaceのままなのでこれがまた
悲しい...

---
SHIROYAMA Takayuki

In This Thread