ここから始まる地獄、は、確かに微かなる地獄なわけだ。

ここでやった MeCab.py は、振る舞いがヘンなわけね。nodeToParse を使う場合にのみおかしい感じなんだけれど、ともあれこやつから返る最初のノードの表層形がおかしい(2つ目のノードまでかもしれない)。

で、「問題の切り分け」の術としては、「Unix ならどうなんだ」って理想的環境をベースに考えるのがおそらく最善なんだけれど、その前に起動は手軽な msys2 の方でやってみようかと思った。

msys2 は日常使いしてないもんで、持ってたのがあんまり新しくなくて、たぶん 2017年6月2日版、かな? インストーラが残ってないんだけれど、/usr/bin の中にある、パッケージマネージャ関係以外のタイムスタンプを見る限り、おそらく。で、こいつには python2.7 だけが入ってた(なぜか dll だけは 3系のがいたけど)。

なんかね。全然ダメ。MSVC でやったのと非常に似ているんだけれど、こちらはコンパイルエラーではなくてリンクエラーの方。unsigned long、char* const 関係のオーバロードに関するものみたいだから、まさしく「64bit対応」に関係する部分なのだけれども、HAVE_UNSIGNED_LONG_LONG_INT は configure スクリプトがしっかり把握して config.h にブチ込んでくれてるので「それじゃない」んだよね。うーん、64bit 版 CRT、みたいなものは msys64 であれば「問答無用で 64bit版」なのであろうから、そこでリンクエラーになるのもよーわからん。(あ、これはワタシの MeCab.py 用 setup.py だけの話じゃなくて、標準のビルド「./configure ; make」でも同じね、念のため。)

ゆえ、「msys2 が古いからかなぁ」と、2年半ぶりということになるか、msys2 のアップデートを。msys2-x86_64-20190524 ってバージョンのヤツな。

python は pacman -S python2、 pacman -S python3 でそれぞれインストール。python3 は 3.7 なのか。3.8 じゃないのね。(つーかワタシはまだ native Windows な CPython では 3.5 ユーザなので、3.7 でも十分に新しいわけだが。)それと、危うく忘れそうになったが、gcc もインストールね。pacman -S gcc(なぜか大前提のいくつか(mecab のためには make、diffutils、あと python バインディングのために libcrypt-devel) がデフォルトで入らないのでそれらも)。

で、「問題の切り分け」をしたいわけなので、MeCab に関しても、「公式」と「野良ビルド」両方やりたいわけよね。けれども、mecab は pacman での管理対象外、つまり pacman ではインストール出来ない。結局野良ビルドしかない。

結論。「最新の msys2 でも状況はまったくおんなじ」。あぁ、もう msys2 での検証はダメだな。

で、重くて億劫なので出来れば避けたかったが、やむを得ず VirtualBox な Fedora (26) で。ちいとばかし迷走したが、python バインディングは以下で、つまり「抱え込まない」ビルドでは動く:

 1 #! /usr/bin/env python                                                                                 
 2 
 3 from distutils.core import setup, Extension, os
 4 import re
 5 
 6 def cmd1(str):
 7     return os.popen(str).readlines()[0][:-1]
 8 
 9 def cmd2(str):
10     return re.split(r"\s+", cmd1(str))
11 
12 setup(name = "mecab-python",
13         version = cmd1("mecab-config --version"),
14         py_modules=["MeCab"],
15         ext_modules = [
16                 Extension("_MeCab",
17                         ["MeCab_wrap.cxx",],
18                         include_dirs=cmd2("mecab-config --inc-dir"),
19                         library_dirs=cmd2("mecab-config --libs-only-L"),
20                         libraries=cmd2("mecab-config --libs-only-l"))
21                         ])

(蛇足: この setup.py は公式な GitHub レポジトリにおいてあるやつを一箇所だけ書き換えたもの。)

して、結論としては、「Windows での振舞いとほぼ同じ」。つまり、最初のノードの表層形はやっぱりおかしい。

昨日のだっけか、「ライブラリとしてはダメ」と言ったけれど、これねぇ、おそらくなんだけど、「parseToNode をベースに parse を作った」のではなくて、たぶん逆。parse が基礎で、「それをノードに分解する機能」として parseToNode をわざわざ作ったんだと。でないとこんなへんちくりんな振る舞い、説明出来ない。なんだかなぁ。機能分割を根本的に誤っとるつーか。

つまりは、「ワタシの野良ビルド」の問題なんかではなくって、元からおかしい、てことで良さそうだ。(あるいは linux 版のだって結局 64bit ビルドなので、RPM Fusion なパッケージでのビルドも「ワタシと同じく失敗している」可能性もないではないけれども。)

なんというか、もうあれだわ。「parse 以外の機能は諦めて、parse の結果を自力でパースする」か、「ダミー。」で誤魔化すかの二択、てことなのだわ。parseToNode は壊れてるとして諦めるのが賢明。

蛇足。

久々に Fedora ったんだけれど、やっぱワタシは linux、特に「RedHat 系」が大嫌いだ。何度も何度でも「ワタシはマインドとしては根っからの Unix ユーザ」と言っているけれど、はっきりいって「linux ラバーズ」ではないんだよ。なんつーか「研究者・開発者のための Unix」という大事な大事な精神を、台無しにしようと台無しにしようと努力を重ねてきたのが「RedHat を筆頭としたディストリビュータ」だからね。

何を言ってるのかって?

「コンパイラの付いてない Unix なんか Unix じゃねー」。の話。今回の検証で、g++ をインストールしてなかったことに気付いて愕然とし、mecab も「mecab-devel も必要だ」という無駄なノウハウを必要とし。「開発者しか開発環境はいるはずがねーだろヴァーカヴァーカ」てのはね、「Unix を使いたいユーザ」の想いとは真逆の親切なんだよ。ほんと、めっさストレスがたまる。とてもじゃないが Unix を使ってる気分になれない。