accomplish nothing

Larcenyが準拠しないSRFIの一覧とその理由。2007年の12月から更新がないので多少古いけど、今読んでも十分参考になる。

例えば、

Larceny does not support SRFI 88. Use symbols instead.

Larceny Project. Deprecated SRFIs, Version 3, Dec 2007. At https://trac.ccs.neu.edu/trac/larceny/wiki/DeprecatedSRFIs.

とのことで、キーワードには反対の立場らしい。シンボルを使え、とのこと。確かに、alistとかで簡単に同じことができるし、そういう考え方も理解できる。

他にも、SRFI 18やSRFI 21のマルチスレッドサポートは、POSIXスレッドを前提にしている節があるのでサポートしてない、とか。Larcenyでスレッドを使いたいときは、tasking.schがファイバの実装なので、それを使えってことなんだろうか。

こういう、開発者の考えが詳しく書かれたドキュメントがあると、処理系選びの助けになるし、それに、自分以外の考えを知るのは単純に面白い。

使ってて思ったこと。

Gauche

FFIを、PLT SchemeやLarcenyやIkarus Schemeみたいに動的にやりたい。あのライブラリのあの関数をちょっと使いたい、なんてときにコンパイルやリンクが間に入るとめげる。対応するのは1.0以降とのことで、先は長い。

PLT Scheme

賛成したからには、規格が風化する前に、実用的なR6RS環境を整備して欲しい。独自ライブラリの対応があんまり進んでない気がする。

Larceny

0.97を早く使いたい。それと、Solaris/x86でのネイティブコンパイルに対応して欲しい。Solarisは使うんだけど、うちにSPARCはないんだ。

Ikarus Scheme

早く独自拡張部分の仕様を固めて欲しい。リポジトリにシンボリックリンクとか入っててWindowsで困る。BazaarのWindows用の公式バイナリが使えない。

Cygwin 1.7.0-43にIkarus Schemeをインストールする。

Ikarusは多倍長整数の計算にGMPを使うので、ない場合はインストール。GMPはGCC 4も使っているので、GCC 4がインストールされている環境にはある。今回はGCC 4.3.3でコンパイルしたのでインストールは省略。

FFIを使うために、libffiのインストール。

$ tar xfz libffi-3.0.8.tar.gz
$ cd libffi-3.0.8
$ ./configure
$ make
$ make install

libffi 3.0.8時点での標準では、libffiのヘッダが、PREFIX/includeではなくて、PREFIX/lib/libffi-version/includeにインストールされることに注意。これを忘れていると、Ikarusのconfigureでffi.hが見付からずにエラーになる。

Ikarusのインストール。今回はリポジトリの最新版をチェックアウトしてビルドするので、AutoconfとAutomakeが必要なのに注意。それと、IkarusはBazaarでバージョン管理されているので、チェックアウトにはBazaarが必要。ないときはCygwinのインストーラからインストールする。公式のWindowsバイナリではシンボリックリンクが張れないので、チェックアウトに失敗する。

$ bzr co --lightweight http://www.cs.indiana.edu/~aghuloum/ikarus.dev
$ cd ikarus.dev
$ CPPFLAGS=-I/usr/local/lib/libffi-3.0.8/include ./configure
$ make
$ make install

Cygwin 1.7.0-43上でGCC 4.3.3をビルドしたところ、libibertyのコンパイル中にエラーが発生。

../../../gcc-4.3.3/libiberty/strsignal.c:408: error: conflicting types for 'strsignal'
/usr/include/string.h:79: error: previous declaration of 'strsignal' was here

とのこと。どうやら、Cygwinのstring.hと、GCCのlibiberty/strsignal.cとで、strsignalの型に食い違いがあるらしい。

それぞれを比べてみると、

/* string.h */
char  *_EXFUN(strsignal, (int __signo));
...

/* libiberty/strsignal.c */
const char *
strsignal (int signo)
{
  ...

確かに違う。でも、libiberty/strsignal.cのstrsignalの定義は、#ifndef HAVE_STRSIGNALで囲まれている。Cygwinのlibcにstrsignalがあるなら、定義部分はコンパイルされないので、こんなエラーは出ないはず。何故だ。というわけで、色々調べた。

とりあえず宣言と定義の食い違いについて。POSIXに準拠するために、strsignalの戻り値の型をconst char*からchar*に修正する動きがあって、Cygwinのstring.hはリビジョン1.22、GCCのlibiberty/strsignal.cはtrunkのリビジョン136949で修正された。なんだけど、Cygwin 1.7.0-43のstring.hではこの修正がされているのに対して、既に別のブランチになっていたGCC 4.3.3のlibiberty/strsignal.cでは、戻り値の型がconst char*のままなので、食い違いが起きた。

次に本題、HAVE_STRSIGNALマクロについて。結論から。以前はCygwinのライブラリをビルドするのに、libibertyの関数を使っていたので、強制的にconfigureのチェックを外していたらしい。ちくしょー、妙なkluge仕掛けてんじゃねー、とか思わないでもないけど、必要だった時期があったんだろうから仕方がないか。疲れた。

CygwinでGMPをビルドしたんだけど、スタティックライブラリはできているのに、DLLがない。はて？　と思ってconfigure.inを調べたところ、Cygwinでは--enable-sharedと--enable-staticが排他的な関係になっていた。gmp.hの内容がそれぞれで違ってくるからだそうだ。

言われてみれば、WindowsのDLLでは、関数をエクスポートやインポートするときに、修飾子を使ったりするんだったっけ。納得。