Big Sky

VCだとビルド出来るらしいけど、strawberry perlとかだとコンパイル出来ない。
まずCoro側のpatch。

diff -ur Coro-5.132.orig/Coro/libcoro/coro.c Coro-5.132/Coro/libcoro/coro.c
--- Coro-5.132.orig/Coro/libcoro/coro.c 2008-11-19 11:50:13.000000000 +0900
+++ Coro-5.132/Coro/libcoro/coro.c  2009-06-19 15:01:16.140625000 +0900
@@ -228,6 +228,9 @@
   #if __CYGWIN__
     ctx->env[7] = (long)((char *)sptr + ssize) - sizeof (long);
     ctx->env[8] = (long)coro_init;
+  #elif defined(__MINGW32__)
+    ctx->env[4] = (int)((unsigned char *)sptr + ssize);
+    ctx->env[5] = (long)coro_init;
   #elif defined(_M_IX86)
     ((_JUMP_BUFFER *)&ctx->env)->Eip   = (long)coro_init;
     ((_JUMP_BUFFER *)&ctx->env)->Esp   = (long)STACK_ADJUST_PTR (sptr, ssize) - sizeof (long);

mingw32のjumpbufは4番目がEipで5番目がEspだったはず。
一応手元で動いてます。
あとこのままでも駄目で、ExtUtils::MakeMakerがgccの時に付けてしまう--image-baseオプションがまずい。
アドレスの作り方が Coro::Event であれば Event という文字列に対して上位4バイト、下位4バイトで分けてunpackとかやってござる。

    if ($GCC) {
        my $dllname = $self->{BASEEXT} . "." . $self->{DLEXT};
        $dllname =~ /(....)(.{0,4})/;
        my $baseaddr = unpack("n", $1 ^ $2);
        $otherldflags .= sprintf("-Wl,--image-base,0x%x0000 ", $baseaddr);
    }

なので、Coro::Event が使っている Event というモジュールと --image-base がバッティングして起動時にメモリロケーション不正参照のエラーが起きる。
こちらについては、ExtUtils::MakeMakerに含まれる MM_Win32.pm を修正する。最近の gcc は勝手に --image-base 作ってくれるので、そちらに任せる。

--- MM_Win32.pm.orig    2009-06-22 17:48:43.906250000 +0900
+++ MM_Win32.pm 2009-06-22 17:49:05.703125000 +0900
@@ -307,12 +307,12 @@
 # we try to overcome non-relocateable-DLL problems by generating
 #    a (hopefully unique) image-base from the dll's name
 # -- BKS, 10-19-1999
-    if ($GCC) {
-       my $dllname = $self->{BASEEXT} . "." . $self->{DLEXT};
-       $dllname =~ /(....)(.{0,4})/;
-       my $baseaddr = unpack("n", $1 ^ $2);
-       $otherldflags .= sprintf("-Wl,--image-base,0x%x0000 ", $baseaddr);
-    }
+#    if ($GCC) {
+#      my $dllname = $self->{BASEEXT} . "." . $self->{DLEXT};
+#      $dllname =~ /(....)(.{0,4})/;
+#      my $baseaddr = unpack("n", $1 ^ $2);
+#      $otherldflags .= sprintf("-Wl,--image-base,0x%x0000 ", $baseaddr);
+#    }
 
     push(@m,'
 # This section creates the dynamically loadable $(INST_DYNAMIC)

SYNOPSISの例でもちゃんと動きます。

あとはバグ報告から上手く修正されれば...

http://twitter.com/itkz/statuses/220045412

GtkTwitter の configure がこける理由がわからないので、aclocal.m4 の AM_PATH_GTK_2_0 を解析する羽目になった。仕事ってなにそれおいしいの

http://twitter.com/itkz/statuses/219941692

GtkTwitter をどうやっても起動できない。GTK+ Runtime をインストールしても動かないし、DLL を全て実行ファイルと同じ階層に置いても動かない。関数のエントリポイントが見付からないんだとよ！ 舐めてっとぶっ飛ばすぞ。どういうことだ。

http://twitter.com/itkz/statuses/222783012

（続き）もちろん、GtkTwitter の configure は pkg-config をスルーしてるので config.log にエラーなど残っていない。だからコンパイル時の問題だと思って CFLAGS をいじくったりしていたわけだ。

http://twitter.com/itkz/statuses/221271572

結局のところ、数時間かけても GtkTwitter のビルドには成功していない。まずバイナリで落としてきた libcurl をリンクすると「エントリポイントがねえ」と言ってくる。調べると「cURL が MinGW で動かねえと騒いでる糞どもはソースからビルドしろ」と一喝されている

これ以上ほったからしにしておくと、惨殺されるという噂なので焦って記事アップしました...(嘘です)

まず、リポジトリですが

http://gtktwitter.googlecode.com/

にあります。ダウンロード用アーカイブは古いのでsvnから使って下さい。
mingw32の場合は、autotoolを使うまでもないので確認していません。(ごめんなさい)
必要な物は

GnuWin32
Glade/GTK+ for Windows
cURL: win32-ssl-mingw from Mirrors

あたりでダウンロード出来るかと思います。
Makefileは適当に

all : gtktwitter.exe

gtktwitter.exe : gtktwitter.o gtktwitter.res
    gcc -o gtktwitter.exe \
        -Lc:/gtk/lib \
        gtktwitter.o \
        gtktwitter.res \
        `pkg-config --libs gtk+-2.0 libxml-2.0 gthread-2.0` \
        -lcurl

gtktwitter.o : gtktwitter.c
    gcc -c \
        `pkg-config --cflags gtk+-2.0 libxml-2.0` \
        gtktwitter.c

gtktwitter.res : gtktwitter.rc
    windres -o gtktwitter.res --output-format=coff gtktwitter.rc

clean:
    -rm *.o *.res *.exe

あたりで誤魔化して下さい。
あとは、curl.hやlibcurl.aをmingwへ入れ

set PKG_CONFIG_PATH=C:\GTK\lib\pkgconfig

してからmake(mingw32-make)すると出来上がると思います。

どうか、これでお許し下さい。苦笑