Gauche:Cygwin
Gauche-0.8以降のGauche on cygwin
「20030307より新しいbinutilsを使えば大丈夫」
( Gauche/Cygwin(Dos)での問題 )
Cygwin 以外で Gosh を利用した時にインタラクティブな表示が返ってこない。
c:/cygwin/usr/local/bin/gosh.exe -i
などできちんと動くようになります。
古い話
以下の話題は解決済みですが、記録のために残しておきます。
- Gacuheはgcc-2でなければコンパイルできないんですね。--hoti
- いや、そんなことはありませんよ。20030307より新しいbinutilsを使えば大丈夫です。ここには古い記述が残っているので、注意が必要です。このあいだも酒井さんに cygwin 版の gtk ができてないのはここにある以前の制限のせいではないことを伝えないといけませんでしたし……--shelarcy
- 混乱を避けるために、古い話はそう明示しました。この項も適当に書き換えちゃって下さい。-- Shiro(2004/06/16 04:43:52 PDT)
- 下のページを見て勘違いしました。混乱を与えるので、「適当に書き換え」ました。--hoti (http://practical-scheme.net/gauche/features-j.html#ports )
Gauche on cygwinの制限
Shiro(2004/06/16 04:45:39 PDT): この制限は現在(0.8)はもうありません。
Cygwinでも通るようにしていますが、今のところいくつか制限があります。
- dso (dlopen()されるdll)から別のdsoの参照が出来ない: 例えばmath.mt-randomモジュールの C定義ルーチンの一部がgauche.uvectorのC定義ルーチンを参照しているのですが、 cygwinでのビルドではそれがうまくハンドリングできません。 (現在は問題のあるルーチンはcygwinではコンパイルされないようになっています)。 多分、cygwinの制限ではなくwindowsの制限だと思うのですが、 dsoのビルド時に全てのシンボルが解決されなければならないためです。 一応、方針としては、他からも参照されるdsoについては機能本体を通常のdll としてコンパイルし、ブリッジとなる部分だけをdsoにしておくことを考えて います。その機能が必要な他のdsoはリンク時にdllをリンクするように指定 してやるわけです。 但し、ビルド/インストールプロセスをかなり変更しなければならないため、 まだ手をつけていません。
- Gauche-gl, Gauche-gtk等の拡張モジュールもgauche.uvectorのC定義ルーチン を参照しているため、現在のところ上記の理由からビルド不可です。
Gauche-0.7 with the newest gdbm, iconv
(2003/06/02 21:15:12 PDT)
- It seems that the newest gdbm (1.8.3-1) separated the dbm/ndbm compatibility routine to libgdbm_compat. The configure script fails to find them. After configuration, add -lgdbm_compat in the make rule of ndbm.la and odbm.la in ext/dbm/Makefile.
- It also seems you need to add -liconv manually in the male rule of libcharconv.la in ext/charconv/Makefile.
ビルド時にgccがSegmentation fault
Gauche-0.6.7.1.tgzをcygwinでビルドしようとしたら、 こんなこと言われてしまいました。
gcc -g -O2 -I../../src -I../../gc/include -fomit-frame-pointer -march=i686 -DUSE_I686_PREFETCH -c -o uvector.o uvector.c uvector.c:125: internal error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
configureには何も引数を与えていません。 また最適化オプションをすべて外しても再現しました。
使用しているcygwinとgccのパッケージはそれぞれ、
- cygwin-1.3.20-1
- gcc-3.2-3 です。
とりあえず報告まで。 ...って、報告する場所はここでいいのかな... -- さかい
- Shiro: Cygwin+gcc3の組み合わせは試したことが無いんですが、 もしかしてDLL内のデータの参照法とかが変更になったりしてるでしょうか。 いまのところ、doc/cygwin-memo.txt にあるようなトリックを使っています。 (でも以前に別のプラットフォームでgcc3で問題が出たような覚えもかすかにあるので 一般的な問題かもしれません)。
- cygwinのgcc-3.2は、なんとgcc-3.2.2をビルドできません。なので、gccのせいじゃないでしょうか。なので私はgaucheのビルドにはgcc-2を使っています。
- さかい gcc-2ならば無事にコンパイルできました。ありがとうございます。 ところでこのトリックは面白いですね。
パスの'~'は$HOMEではなく$HOMEPATH
file.utilのexpand-pathでハマったので書いておきます。--hira
file.utilのexpand-pathで使用される環境変数は$HOMEではなく$HOMEPATHです。 Cygwinの$HOMEPATHは「コンピューターの管理/システムツール/ローカルユーザーとグループ/ユーザー/<UserName>/プロファイル/ホームフォルダ/ローカルパス」の設定が元になっています。
その情報を元に/etc/passwdが生成され、ここの設定がCygwinの$HOMEPATHになるようです。 なので、$HOMEと$HOMEPATHが違っている場合、Cygwinインストール前ならWindowsのユーザープロパティーを変更すればよいし、Cygwinインストール後なら両方書き換えておけばよいでしょう。
- Shiro(2004/06/16 04:43:52 PDT): 現在、"~"の展開はgetpwnamもしくはgetpwuidを使って 直接パスワードファイルエントリを読んでホームディレクトリを展開しているので、 環境変数は見ません。