ども、白山 / fortune.nest.or.jpです。

非常に遅れて申し訳ございません。NeXTSTEP3.3J上での
Ruby-1.0-970110のコンパイル情況をお伝えします。

ええっと、まず dynamic-loadを一切しない、ext/Setupで
nodynamicを選択した場合は、そのままでなんら問題なく
コンパイルできます。従って普通の用途ですと ext/Setupで
nodynamicを設定し、全てをスタティックリンクすればなんら
問題なくrubyで遊ぶことができます(^^;)

問題は、dynamicloadをおこなう場合で・・・・

1. NeXTSTEP3.3Jのrld_load関数の仕様で、ロードするコマンド
   側にシンボルがない共有ライブラリの関数はロードされる
   オブジェクトから呼び出せない。

   つまり、プログラムmasterが オブジェクト obをrld_load関数
   によってdynamic loadしようとすると、obが呼び出すであろう
   ライブラリ関数のシンボルをmasterは持ってないといけま
   せん。(ないと、呼び出せない)

1' この為、rubyのように何を呼び出すか分からない場合は、
   libsys_s.shlib(libc)に入っている関数のシンボル全てを
   rubyインタプリタ側にひっつけとかないといけない。

2. rld_lookup関数で関数のアドレスを調べる時には、関数名の
   頭に _ が必要

3. NeXTではdynamic loadで呼び出されるオブジェクトを作成
  するのに、ccに いかなるオプションも必要としない。
  その為、逆に-fpicがつくと妙な状態になる。

っという難儀な問題があります。( ここらへん、4.1Jでは解消
されたそうですが・・・私はもってないので知りません(^^;))

問題1'からruby側ではlibsysに入っているものと同じ名前の関数
名は使えなくなります。その為・・・regex.c のre_match関数が
libsysの同名関数とぶつかります。また、 -lmを指定すると libm
とlibcでまた名前がぶつかります。

2.は・・・どうも私の(あの小汚い)コード(^^;)を matzさんが
直されたおりに _ が入らなくなったみたいです。
(あと、非常につまらない事ですが、この関数名の作成をdln.cの
 関数init_funcname でおこなうようになった為、dln.c1262行目
 の変数len, 1263行目の変数point,1264行目の変数init_nameが
 無意味になってます(^^;))

以上が問題点です。そして・・・

1,及び 1'の解決策として、

a. regex.cの関数re_matchはregex.cの内部(の一か所)
   でしか呼ばれてないので、関数名をrre_matchと直し名前
   の衝突を避ける

b. ruby本体のMakefileのLIBSに入ってる-lm を除去

c. 同Makefileに  LDFLAGS = $(CFLAGS) -u libsys_s
  っと -u libsys_sを追加。

2.の解決策として

d. rld_lookupの第二引き数(検索する関数名)に _が入るように
   小手先の修正をかます。具体的には・・・無意味になってた
   変数 len, init_nameを生かして・・・

dln.c: 1261行目
	void (*init_fct)();
	int len = strlen(buf);
	char *point;
	char init_name[len +2];
	
	object_files[0] = file;
	
	/* Load object file, if return value ==0 ,  load failed*/
	if(rld_load(NULL, NULL, object_files, NULL) == 0) {
	    LoadError("Failed to load %.200s", file);
	}

	/* lookup the initial function */
	sprintf(init_name,"_%s",buf);
	if(rld_lookup(NULL, init_name, &init_address) == 0) {
	    LoadError("Failed to lookup Init function %.200s",file);
	}
dln.c1277行目

   っと修正。

3.の解決策として
e, ext/extmk.rbを検索し、-fpicを添付してた部分を潰して
   CFLAGに -fpicが含まれないようにする
   (何の事はない、"-fpic"って文字列をさがしだして、そこを
    ""にしただけです)

の以上五点を直す事により、dynamic loadもうごくようになりました。


さすがにそろそろ気力もつきてきたので(^^;)、a,dに関しては後日
改めて patchにしてお送りします。

b,cに関しては、configureが勝手に作るものなので、私はどうすれば
いいか分かりません。のでNeXTでconfigureした時はLIBSに -lmを含め
ず、そしてLDFLAGには -u libsys_sというオプションが入るよう修正、
お願いします。

同様に eに関しても、現在のOSをみて -fpicを入れないようにする
対策、お願い致します。> matzさま

---
SHIROYAMA-Takayuki: HigashiZyuzyo Kita,Tokyo,Japan.
「 昭乃さん、いま、幸せですか?     <Psi / fortune.nest.or.jp>
   幸せなら、私も ちょっと幸せ  」
 fingerprint  36 81 03 C3 CC 65 24 00  96 07 1F 66 12 FC 8E 18
PS: しかし・・・この修正で喜ぶのって、私だけなのかも・・・
PS/2: 動的にエンディアンを調べるコードまで作成して頂き、
    ありがとうございます。そのうち Intelマシンを調達して
    チェックしますので、しばしお待ち下さいませ。