[MD:4668] cygwin で mingw-runtime 3.2 を使ってビルドするには？

["M.Fujii" <boochang@xxxxxxxxxxxx>]

藤井です。

以下のように mingw-runtime 3.2 をインストールすると cygwin でビルドで
きない問題が meadow-users-jp ML で報告されていますが、一応ビルドできる
ようになりました。

# こんな対処で良いのかどうかは不明なので、とりあえず meadow-develop の
# 方に投稿します。

From: MIYOSHI Masanori <miyoshi@xxxxxxxxxxxxxxxx>
Subject: Re: mingw-runtime 3.2-1 でコンパイルエラー(Meadow2)
Date: Thu, 16 Oct 2003 07:23:24 +0900
Message-ID: <ufzhu9m3n.wl%miyoshi@xxxxxxxxxxxxxxxx>

> >>>>> [meadow-users-jp : No.4782] にて
> >>>>> "広松" = Takashi Hiromatsu <takashi-hiromatsu@xxxxxxxxxxx> さんは書きました:
> 広松> Windows95 上の、Cygwin でコンパイルをしていますが、
> 広松>     20031004版のPatch適用
> 広松>     mingw-runtime 3.2-1
> 広松> だと、emacs.cのコンパイル時に、エラーが出ます。
> 
> この現状を確認しました。
> 
> Mingw の stdio.h と s/ms-w32.h の #define が衝突しているようです
> ね。
> 
> これは CVS Head の NTEmacs でも発生する問題です。
> 
> 直すのはちょっと面倒ですので、NTEmacs で対処されるのを待ってから、
> Meadow2 に取り込みたいと思います。

これは、ad hoc な対応になりますが、以下のように fileno のマクロによる
リネームをしないようにすれば、とりあえずコンパイル *は* 出来るようにな
ります。

--- src/s/ms-w32.h.orig	2003-06-18 03:18:56.000000000 +0900
+++ src/s/ms-w32.h	2003-10-16 21:50:26.281250000 +0900
@@ -355,7 +355,12 @@
 #define fcloseall _fcloseall
 #define fdopen	  _fdopen
 #define fgetchar  _fgetchar
+#ifdef __MINGW32__
+#include <_mingw.h>
+#endif
+#if !defined(__MINGW32__) || !(__MINGW32_MAJOR_VERSION >= 4 || __MINGW32_MAJOR_VERSION == 3 && __MINGW32_MINOR_VERSION >= 2)
 #define fileno	  _fileno
+#endif
 #define flushall  _flushall
 #define fputchar  _fputchar
 #define fsync	  _commit

これで、コンパイルは可能になりますが、以下のようにダンプ時に実行時エラー
が発生するので結局ビルドはできません。

bash-2.05b$ make install
(snip)
cd oo-spd/i386 && ./temacs.exe -nd -batch -l loadup dump
Loading loadup...
Using load-path (../../../lisp)
Loading byte-run...
Loading subr...
Loading version.el (source)...
Loading widget...
Loading custom...
Loading emacs-lisp/backquote...
Loading map-ynp...
Loading env...
Loading cus-start...
Note, built-in variable `x-bitmap-file-path' not bound
Note, built-in variable `x-stretch-cursor' not bound
Loading international/mule...
Loading international/mule-conf.el (source)...
Loading format...
Loading bindings...
Loading simple...
Loading files...
Lists of integers (garbage collection statistics) are normal output
while building Emacs; they do not indicate a problem.
((10265 . 4459) (3885 . 0) (496 . 3) 120540 30495 (3 . 0) (16 . 0) (6024 . 465))
Loading loaddefs.el (source)...
((21788 . 14178) (5804 . 0) (507 . 5) 172484 30495 (5 . 0) (16 . 0) (9857 . 160))
Loading help...
Loading international/mule-cmds...
Loading case-table...
Loading international/utf-8...
Loading international/utf-16...
Loading international/characters...
End of file during parsing: d:/home/fujii/work/setup/Meadow-2.00b1/lisp/internat
ional/characters.elc
Signal 127
make[1]: *** [oo-spd/i386/Meadow.exe] Error 255
make[1]: Leaving directory `/home/fujii/work/setup/Meadow-2.00b1/src'
make: *** [all-other-dirs-gmake] Error 2

このエラーの原因についても調べてみました。

これは、mingw-runtime 3.2 での変更点として getc などの関数のインライン
関数化が含まれているのですが、このインライン関数の実装にバグがあるよう
に思われます。

getc は 0 〜 UCHAR_MAX もしくは EOF を返す訳ですが、mingw-runtime 3.2 
のインライン版は 0x80 以上のキャラクタをバッファから読み込むと負の数を
返すようです。

Meadow(Emacs) では read1()@lread.c において読み込んだキャラクタコード
が負の場合に EOF と判定するようにコーディングされており、mingw-runtime
3.2 のインライン版 getc などを用いた場合に 0x80 以上のキャラクタを読み
込んだ時に EOF と誤認してしまいます。

このため、上記エラーメッセージ "End of file during parsing: ..." を出
力してエラー終了します。

これを修正するには、以下の方法が考えられます。

	(1) MinGW の stdio.h を編集してインライン関数版 getc/getchar を
            修正する。

	(2) インライン関数版 getc/getchar を使わないようにビルドする。

(1) は Meadow 側ではどうにもならないので、(2) のアプローチを考えてみま
した。

stdio.h を見ると、getc などのインライン関数版はスレッドセーフではない
ため、マルチスレッドアプリとしてビルドすると、ランタイムライブラリ版の 
getc を使うように条件コンパイルできるようになっています。

ですので、gcc のコンパイルオプションに -mthreads を追加するとインライ
ン関数版を使用せず、ランタイムライブラリの関数がリンクされるようになり
ます。

ですので、gmake.meadow.defs を以下のように修正してみました。

--- nt/gmake.meadow.defs.orig	2003-10-16 07:53:44.947875000 +0900
+++ nt/gmake.meadow.defs	2003-10-16 23:50:34.651375000 +0900
@@ -267,7 +267,7 @@
 endif
 
 ifdef NOCYGWIN
-NOCYGWIN = -mno-cygwin
+NOCYGWIN = -mno-cygwin -mthreads
 endif
 
 ifeq "$(ARCH)" "i386"


これで正常にビルドできるようになります。

ここまでやるぐらいなら mingw-runtime 3.1 のままにした方が良さそうな気
もしますが、一応原因が分かったということでご報告します。

また、最適化オプションをはずすことによっても、gcc のインライン関数の展
開が抑止されるため、ランタイムライブラリの getc/getchar が使用されるよ
うになるようです。

文章が長くなりましたが、以上ご報告まで。

--
藤井 正行 / Masayuki FUJII ( boochang@xxxxxxxxxxxx )