〜2002年10月上旬〜
338通。やはり増えてる。
commitされたのでそろそろGNU ldチェックを入れよう。 週末かな。
Microsoft .NET Framework にVC7が入ってるという噂を聞いた。 160MBをダウンロードするのがかなり痛いがインストールしてみると確かに
C:\Program Files\Microsoft Visual Studio .NET\Vc7
が存在する。でもincludeやlibを見るとPlatform SDK相当のファイルがない。 windows.hとか。 ってことは今度は Core SDK あたりが必要か？明日ダウンロードしてみよう。って200MBかよ。
わざわざ縦断してる最中に帰宅したらしい。30分遅らせれば傘も要らなかったのに。
version.hが1.6.8になってる。ってことは昨日作った20021001はちとまずいね。 20021002を作ったからいいや。
結局Core SDKをインストールしたら必要なものはそろった。 あっちこっちばらばらだと環境変数の設定も面倒なので一ヶ所に集めてみた。 たとえばd:\vcに集めるにはこんな感じ。
% cd /d/vc % sdk='c:/Program Files/Microsoft SDK' % vc7='c:/Program Files/Microsoft Visual Studio .NET/Vc7' % mkdir -p bin include lib % cp -av "$vc7"/bin "$vc7"/include "$vc7"/lib . % cp -av "$sdk"/bin/rc.exe bin % cp -av "$sdk"/bin/rcdll.dll bin % cp -av "$sdk"/bin/win64/cvtres.exe bin % cp -av "$sdk"/bin/win64/lib.exe bin % cp -av "$sdk"/bin/win64/nmake.exe bin % cp -av "$sdk"/bin/win64/dumpbin.exe bin % cp -av "$sdk"/bin/win64/msvcr70.dll bin % cp -av "$sdk"/bin/win64/msvcp70.dll bin % cp -av "$sdk"/bin/win64/mspdb70.dll bin % cp -av "$sdk"/bin/win64/msobj10.dll bin % (cd "$sdk"; tar cf - include lib --exclude=Win64 --exclude=IA64) | \ tar xfv -
あとはコマンドプロンプトで
set INCLUDE=d:\vc\include set LIB=d:\vc\lib PATH=%PATH%;d:\vc\bin
で準備完了。試しにrubyをmakeしてみる。okだ。 最適化はしてくれないので
cl : コマンド ライン warning D4029 : 標準の編集コンパイラでは最適化は使用できません。 cl : コマンド ライン warning D4002 : 認識不可能なオプション '-Og-' を無視しました。
となる。「標準の編集コンパイラ」とはStandard Editionということか？
本屋で3rd edtionを見た。Volume1, 2と2冊になってる。 どっちも分厚い。ちょっと買う気が失せた。うーむ。
なぜかCygwin上のzshでnmakeすると、途中で
Creating config.status makefile(15) : fatal error U1054: cannot create inline file '' Stop.
となる。早速 例のリファレンスマニュアル を見ると環境変数TMPがあやしい。実は~/.zshrcでunset TMPしてるのだ。
ただし、TMP 環境変数が定義されていない場合は、 カレントディレクトリに作成されます。
とあるが、コマンドプロンプト上でset TMP=してからnmakeするとやはり同じエラーになる。 どうもnmakeがバグってるらしい。とりあえず
% TMP=. nmake
でよさげだが、
<<[filename]
とあるので、win32/Makefile.subの中で明示的に名前を指定する手もあるか。
すぐにでも1.6.8が出そうな勢いなので、慌ててcommitした。 とりあえずはLinuxだけ。
cl.exeの リファレンスマニュアル を見ていたら、コマンドファイルに書けば-linkは最後になくてもいいような気がしてきた。早速実験してみる。
% unset LIB INCLUDE
% cat resp
-link -libpath:c:/vc/lib
-Ic:/vc/include
% cat foo.c
#include <stdio.h>
main(){}
% PATH=/c/vc/bin:$PATH cl @resp foo.c
Microsoft(R) 32-bit C/C++ Standard Compiler Version 13.00.9466 for 80x86
Copyright (C) Microsoft Corporation 1984-2001. All rights reserved.
cl -link -libpath:c:/vc/lib
-Ic:/vc/include
foo.c
Microsoft (R) Incremental Linker Version 7.00.9466
Copyright (C) Microsoft Corporation. All rights reserved.
/out:foo.exe
-libpath:c:/vc/lib
foo.obj
okだ。2つ以上libpathを指定するときは
-link -libpath:c:/some/foo -libpath:c:/some/bar
とするより
-link -libpath:c:/some/foo -link -libpath:c:/some/bar
と複数行に分けるのがよさそう。
でもENV['LIB']の代わりにコマンドファイルを使うようにしても、 何の解決にもなっていない気が。没だ。
いつものようにGCC 2.95.3でmakeしようと思ったが、 いきなりconfigureでエラーを喰らう。
checking for gcc... /usr/bin/gcc checking version of /usr/bin/gcc... 2.95.3, bad checking for gnumake... no checking for gmake... no checking for make... make checking version of make... 3.79.1, ok configure: error: *** These critical programs are missing or too old: gcc *** Check the INSTALL file for required versions.
じゃいくつ以上ならいいんだとconfigureを見ると
case $ac_prog_version in
'') ac_prog_version="v. ?.??, bad"; ac_verc_fail=yes;;
3.[2-9]*)
ac_prog_version="$ac_prog_version, ok"; ac_verc_fail=no;;
*) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=yes;;
と、3.2以上じゃないとだめらしい。それは危険の2乗という感じがしないでもない。 あ、INSTALLにちゃんと3.2以上を使えと書いてあった。
最後の最後でctype関係がmultiple definitionになり終了。うーむ。 このマシンのbinutilsは2.10だった。2.10.1以上じゃないとだめなのか？ 2.13をインストールしてみる。okだ。 やはりINSTALLに書いてある推奨のものを使わないといけないらしい。
% tar xfv glibc-2.3.tar.bz2 --bzip2 % cd glibc-2.3 % tar xfvz ../glibc-linuxthreads-2.3.tar.gz % mkdir linux; cd linux % CFLAGS=-Os ../configure --prefix=/usr --enable-add-ons i586-pc-linux-gnu % make % mkdir ~/glibc-2.3 % make install_root=$HOME/glibc-2.3 install localedata/install-locales % cd ~/glibc-2.3/etc % ln -sf ../usr/share/zoneinfo/Japan localtime % cd .. % tar cfv ~/glibc-2.3-bin.tar.bz2 * --bzip2 --owner=root --group=root
このtarballをメインマシンへ転送して
% sudo tar xfv glibc-2.3-bin.tar.bz2 -C / --bzip2 % sudo ldconfig
と実行する。
/binの主要なものは既にstatically linkedなので全く問題はないが、 他にいろいろ試してみると動かなくなったものもある。
w3mが
w3m: relocation error: w3m: symbol __libc_stack_end, \ version GLIBC_2.1 not defined in file ld-linux.so.2 with link time reference
と言われて起動しない。これはBoehm GCだな。とりあえずmakeし直せばok。
cvsupは
*** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL0 *** use option @M3stackdump to get a stack trace
となる。これはバイナリをそのまま使っているだけに痛い。どうしようかな。 sourceからだとModula-3が必要だし。うーむ。rsyncしちゃう手もあるか。
vim, emacs, cvs, ssh, gccあたりは大丈夫。
まっさらなRuby 1.7をmakeしてみる。念のためrm -rf ~/.ccacheしとく。 minirubyをリンクする時に
libruby.a(error.o): In function `set_syserr': error.o(.text+0x9fb): `sys_nerr' is deprecated; \ use `strerror' or `strerror_r' instead
と警告される。いやstrerrorを使うためにsys_nerrも使ってるんだよね。 どんどん使えるものが少なくなるなあ。 とりあえずmake testもokだ。
Ruby 1.6は*.oをそのままでmakeしてみる。undefined referenceだらけだ。 というわけで、make cleanぐらいはしないとまずそう。 なんとなくほかのライブラリもちょっと心配ではある。
% CFLAGS=-Os CC='/usr/i386-linux-uclibc/bin/i386-uclibc-gcc -static' \ ../configure --prefix=/usr --disable-nls
考えてみると、 こうやってどんどんglibc離れしてるから大した影響がないのかもしれない。
cvsupは
% file =cvsup /usr/local/bin/cvsup: ELF 32-bit LSB executable, Intel 80386, version 1, statically linked, stripped
だった。うーむ。staticallyなのになぜ動かなくなる？ ltrace -Sしてみると
SYS_open("/etc/resolv.conf", 0, 0666) = 4
SYS_open("/etc/nsswitch.conf", 0, 0666) = 4
SYS_open("/etc/ld.so.cache", 0, 00) = 4
SYS_open("/lib/libnss_files.so.2", 0, 00) = 4
SYS_open("/lib/libc.so.6", 0, 03) = 4
SYS_open("/lib/ld-linux.so.2", 0, 01005737020) = 4
と非常に怪しいopenがある。ってことはなんとなくdlopenしてる雰囲気だ。 確認してみよう。gethostbynameあたりが適当か。
% cat x.c
#include <stdio.h>
#include <netdb.h>
main()
{
puts(gethostbyname("localhost")->h_name);
}
% gcc -static x.c
% ltrace -S ./a.out |& grep SYS_open
SYS_open("/etc/resolv.conf", 0, 0666) = 3
SYS_open("/etc/nsswitch.conf", 0, 0666) = 3
SYS_open("/etc/ld.so.cache", 0, 037777777777) = 3
SYS_open("/lib/libnss_files.so.2", 0, 06740) = 3
SYS_open("/lib/libc.so.6", 0, 015570) = 3
SYS_open("/lib/ld-linux.so.2", 0, 020430) = 3
SYS_open("/etc/host.conf", 0, 0666) = 3
SYS_open("/etc/hosts", 0, 0666) = 3
% nm a.out |grep dlopen
0806002a T __libc_dlopen
0805ffd0 t do_dlopen
これは反則技に等しい。結局共有ライブラリが必要なんだから。
2.5.39もそうだけど、login promptまでは順調に立ち上がるのに、 なぜかkey入力を一切受けつけない。リセットスィッチを押すしかない。 そろそろfeature freezeらしいのに何がいけないんだろう？
APELを上げたついでに、SEMI 1.14.4, LIMIT 1.14.7に更新。
cvsupはあきらめてrsync -e sshで同期することにした。 それはそれとしてwww.ruby-lang.orgでrsync serverが動いているか調べてみる。
% rsync www.ruby-lang.org:: ftp All of ftp ruby ruby ruby-contrib ruby/contrib ruby-ML ruby/ML www All of www
動いているね。cvsはなかったか。前田さんよろしく〜ってここに書いてもむだか。
Fのsampleをコピーしてパッケージング。
更新。
WineでCL.EXEは動くのか試してみる。
% wine -- cl wine: relocation error: /usr/local/lib/libntdll.dll.so: \ symbol __libc_fork, version GLIBC_2.1.2 not defined \ in file libc.so.6 with link time reference
うーむ。これもglibc 2.3の影響だな。Wineもmakeし直さないと。
strerror(10000)だとどうなるのか実験。
glibc: Unknown error 10000 diet libc: [unknown error] uClibc: SEGV Cygwin: error 10000 msvcrt: Unknown error
見事なまでにばらばらだ。uClibcはチェックすらしてないらしい。 やっぱsys_nerrと比較したくなるじゃん。
再度試してみる。
% wine -- cl Microsoft(R) 32-bit C/C++ Standard Compiler Version 13.00.9466 for 80x86 Copyright (C) Microsoft Corporation 1984-2001. All rights reserved. 使い方: cl [ オプション... ] ファイル名... [ /link リンク オプション... ]
おぉ。動いてる。実際にコンパイルしてみよう。
% echo 'main(){}' >foo.c
% wine -- cl foo.c -link -libpath:'f:\vc\lib'
Microsoft(R) 32-bit C/C++ Standard Compiler Version 13.00.9466 for 80x86
Copyright (C) Microsoft Corporation 1984-2001. All rights reserved.
foo.c
Microsoft (R) Incremental Linker Version 7.00.9466
Copyright (C) Microsoft Corporation. All rights reserved.
/out:foo.exe
-libpath:f:\vc\lib
foo.obj
できてるね。
いつものようにcvs upしてみるとUnknown host anoncvs.cygnus.com.と言われてしまう。 そういえばcygnus.comはもう使えなくなると言ってた気がする。 これ か。
% ruby -pi~ -e 'sub(/anoncvs\.cygnus\.com/, "sources.redhat.com")' **/CVS/Root
とした。あ、~/.cvspassも書き換えないと。
この件 を調べるためにMSYS 1.0.7をインストールした。 make installしてみるとやはりなんかおかしい。
$ ./miniruby -e 'puts ARGV[0]' /usr/local C:\msys\1.0\local
とても厭な仕様だ。