茂木さん、詳しい報告と対処方法をありがとうございます。
「僕が交渉する」とおおっぴらに宣言してしまったのですが、ちょっと今いきなり作業が増えてしまってしばらくかかるかもしれません(涙)。しばしお待ちを...。 そんなに待てない！という場合は茂木さんのほうからさっさとあげてしまっても構いません。掩護射撃が必要な場合はその都度一報もらえれば援護いたします。 ではでは。 2013/4/23 Isamu Mogi <[email protected]> > (再送)すみません、昨日送信してしまった、全体的に文字化けしたメールを文字 > 化けしないように修正して再送します。 > > 吉田様、皆様 > > 吉田様のご厚意で、日本語環境でビルドした際にしか起こらないビルドエラーに > 対応するソースコードの修正をアップストリームへの反映の交渉をしていただけ > るとのことのため、僕が遭遇した日本語環境でしか起こらないビルドエラーと対 > 策を列挙します。どう英訳しようか悩んでいたところに渡りに船です。よろしくお > 願いします。下記の3点になります。 > > (1) idlc.exeがstd::abortする > (2) filter-showIncludes.awkが失敗する > (3) utf-8のソースファイルのコンパイルが失敗する > > また、これらの問題は、英語版のWindowsでも言語環境を日本語にしたり、日本 > 語版VisualC++をインストールすることで再現できるはずです。逆に、日本語版 > のWindowsでも言語環境を英語にし、英語版VisualC++を入れることで再現しなく > なります。 > > -- > > (1) idlc.exeがstd::abortする > > ビルド中にidlc.exeコマンドを実行しているようなのですが、これが引数などを解析する > 際にsal/textenc/textenc.cxxの383行目付近、 > > if(!module_.loadRelative(&thisModule,SAL_MODULENAME("sal_textenc"))){ > SAL_WARN("sal.textenc","Loadingsal_textenclibraryfailed"); > std::abort(); > } > > で、 std::abortでこけます。 原因は、shift_jis用のエンコーディングの関数をsal_textenc.dll > から読む際、sal_textenc.dllがまだビルドされていないことがあるためです。ちなみに、 > asciiやutf-8は特別扱いされ、それらの言語だとstd::abortにはならず正常に動作しま > す。そのため、環境変数SOLAR_USER_RTL_TEXTENCODINGを11に指定するな > どし、内部のエンコーディングを強制的にasciiにしてしまえばいちおう動きます。が、 > あまりよくない気がします。ビルドの順序を修正すれば解決になると思いますが、今 > は調べている時間がないです。 > > (2) filter-showIncludes.awkが失敗する > > filter-showIncludes.awkは、VisualC++のコンパイラ本体のcl.exeから標準出力 > された依存関係の文字列を解析するスクリプトのようです。ただ、cl.exeの出力 > は各国語版によって内容が変わるので、その内容をconfigureスクリプトで拾っ > て環境変数SHOWINCLUDES_PREFIXに格納し、filter-showIncludes.awkはその環境 > 変数を利用しているのですが、その中に下記のコードがあります。 > > showincludes_prefix = ENVIRON["SHOWINCLUDES_PREFIX"]; > regex = "^ *"showincludes_prefix" *" > if ($0 ~ regex){ > > これは、該当の環境変数から正規表現を作っているコードですが、日本語版 > cl.exeの場合、その内容はshift_jis「メモ:インクルードファイル:C:\Temp > \stdio.h」などになります。バイナリデータでは > > 83 81 83 82 3a 20 83 43 83 93 83 4e 83 8b 81 5b |....:.C...N...[| > 83 68 20 83 74 83 40 83 43 83 8b 3a 20 20 43 3a |[email protected]..: C:| > 5c 54 65 6d 70 5c 73 74 64 69 6f 2e 68 0d 0a |\Temp\stdio.h..| > > となり、正規表現の特殊文字『[』が含まれます。これにより、スクリプトが正 > 規表現でマッチを行っている箇所でエラーになり、依存関係の調査に失敗しま > す。これが修正されるパッチを作りました。 > > https://gerrit.libreoffice.org/gitweb?p=core.git;a=commitdiff;h=de1188d44e2daa9c7b600ffe74bd588089f7dbdb > これは、正規表現をつかわずindex関数を使うように修正するものです。このコミ > ットをうまい具合にに整形してupstreamへの反映依頼をお願いします。 > > (3) utf-8のソースファイルのコンパイルが失敗する > > cl.exeはソースファイルを読むとき、bomがついている場合はutf-8として、つい > ていない場合はshift_jisで読みます。そのため、shift_jisと相性の悪いutf-8 > のデータがソースに書いてあるとコンパイルに失敗してしまいます。 > > 該当ソースは下記です。 > > sw/qa/extras/ooxmlexport/ooxmlexport.cxx > sw/qa/extras/rtfexport/rtfexport.cxx > sw/qa/extras/rtfimport/rtfimport.cxx > > 同様のエラーが過去(https://issues.apache.org/ooo/show_bug.cgi?id=76970) > にあり、そのときはutf-8文字列を16進のエスケープ文字に変換したようです > が、今回列挙したコードで利用されているutf-8文字列は、たとえば下記のよう > なものになります。 > > OUString("sin α ± sin β = 2 sin {1} over {2} left ( ... "); > > これをエスケープしてしまうと次のソースになります。 > > OUString("sin \xCE\xB1 \xC2\xB1 sin \xCE\xB2 = 2 sin {1} over {2} left ( > ... "); > > このようにエスケープ後は意味不明なソースになってしまうため、私としては、 > 該当ソースにbomを付加する対応をお願いしたいです。副作用として、古いgccで > はbomつきのutf-8を読もうとすると失敗することがあります。古いosxのxcode付 > 属のgccが危なそうです。 > 以上になります。 > > -- > 茂木勇 > > -- > Unsubscribe instructions: E-mail to [email protected] > Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette > List archive: http://listarchives.libreoffice.org/ja/discuss/ > All messages sent to this list will be publicly archived and cannot be > deleted > > -- Unsubscribe instructions: E-mail to [email protected] Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/ja/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
