或る時のOpenOffice.org Writer/Calcでは、Internet Explorerに文書を表示できていました。
参考になる画面写真：
http://sites.google.com/site/kaihatsublog/activex-control-plugin-viewer/openoffice-org-writer
http://sites.google.com/site/kaihatsublog/activex-control-plugin-viewer/openoffice-org-calc
これが、LibreOfficeになってから、表示できなくなっています。
しかし、ヘルプによりますと、表示できることになっています。
Internet Explorer でドキュメントを表示させるための ActiveX コントロール
http://help.libreoffice.org/Common/ActiveX_Control_to_Display_Documents_in_Internet_Explorer/ja
どういう事か調べましたら、情報が有りました。
Windows build with ActiveX
http://nabble.documentfoundation.org/Windows-build-with-ActiveX-td3926953.html
～～～～～
英文：
I tried to find the activex dll (so_activex.dll & so_activex64.dll) in my
latest official install (LibreOffice 3.5.2.2 / Version ID :
281b639-6baa1d3-ef66a77-d866f25-f36d45f) and did not find it.
I did find it in the latest build of Win-x86@15-Prague_Win32 tinderbox
though (program subfolder).
Is it intentional we do not provide it by default or not ?
Yes, it is. We disable it in distro-configs/LibreOfficeWin32.conf
(--disable-activex-component). You can enable it in your own build and
play with it. As Tor mentined in the other thread, it does not work as
one can expect, and it has no maintaner, so in order to avoid numerous
bug reports we simply disable it.
～～～～～
和訳：
私は公式の最新版LibreOffice3.5.2.2から、activex dllを見つけ出そうとしましたが、見付かりませんでした。
Tinderboxの最新ビルドからは、その機能を見つけることができましたが…
その機能の提供有無についての判断は、故意によるものですか?
はい。そうです。我々はdistro/configs/LibreOfficeWin32.conf (--disable-activex-component)で、その機能を無効にしています。
あなたは、自分のビルドにおいて、その機能を有効にできます。
Tor氏が他のスレッドで言及しているように、その機能は期待するようには動いておらず、手入れできる人材もいません。数え切れない数のバグレポートを回避するために、我々は単にその機能を無効にしています。
きちんと事情が有るようでした（＾＾；
2012年4月21日土曜日
エクスプローラのロックと待機チェーン
Windows Server 2008 R2 Foundationを常用しています。
このOSのリソースモニターに、「待機チェーン」を見る機能が備わっています。(以前のWindowsにも備わっている機能かもしれませんが…)
プログラムがフリーズしている場合に見ると、原因調査の役に立つようです。
普段は全く、見る必要のない画面です。
～～～
「ショートカットキー」を使って、アプリの切り替えをバンバンしていますと、時々フリーズ状態が起こります。
画面写真の内容は、丁度、そのフリーズ状態で、エクスプローラの分析結果を撮ったものです。
「ショートカットキー」とは、どちらの「ショートカットキー」でしょうか。
ショートカットのプロパティを表示しますと、「ショートカットキー」の設定が有ります：
コマンドプロンプトのショートカット・プロパティを表示しています。
同時に4つは使いたいので、4つショートカットを探し出しては、別々のキーを割り当てています。
Ctrl+Alt+M 「Visual Studio 2005 コマンド プロンプト」
Ctrl+Alt+N 「SDK コマンド プロンプト」
Ctrl+Alt+. 「Visual Studio Command Prompt (2010)」
Ctrl+Alt+, 「Visual Studio 2008 コマンド プロンプト」
良く分からないのですが、切り替えるタイミングによってフリーズを起こします。
解決方法をご存知ではないでしょうか…
このOSのリソースモニターに、「待機チェーン」を見る機能が備わっています。(以前のWindowsにも備わっている機能かもしれませんが…)
プログラムがフリーズしている場合に見ると、原因調査の役に立つようです。
普段は全く、見る必要のない画面です。
～～～
「ショートカットキー」を使って、アプリの切り替えをバンバンしていますと、時々フリーズ状態が起こります。
画面写真の内容は、丁度、そのフリーズ状態で、エクスプローラの分析結果を撮ったものです。
「ショートカットキー」とは、どちらの「ショートカットキー」でしょうか。
ショートカットのプロパティを表示しますと、「ショートカットキー」の設定が有ります：
コマンドプロンプトのショートカット・プロパティを表示しています。
同時に4つは使いたいので、4つショートカットを探し出しては、別々のキーを割り当てています。
Ctrl+Alt+M 「Visual Studio 2005 コマンド プロンプト」
Ctrl+Alt+N 「SDK コマンド プロンプト」
Ctrl+Alt+. 「Visual Studio Command Prompt (2010)」
Ctrl+Alt+, 「Visual Studio 2008 コマンド プロンプト」
良く分からないのですが、切り替えるタイミングによってフリーズを起こします。
解決方法をご存知ではないでしょうか…
～は動作を停止しました (CLR20r3：MDbg.exe編)
初めての方は、前編をご覧ください。
今回は、
.NET SDK コマンド ライン デバッガ (MDbg.exe) を用いて進めていきます。
.NET Framework 2.0 SDK等、SDKを入れていないと使えません。納品先等で活用したい場合は、持ち運ぶ等の工夫をします。
使用の際の注意点を：
「Error: デバッグ対象とデバッガが互換性のないプラットフォームにあるので、操作に失敗しました。 (HRESULT からの例外: 0x80131C30)」
32ビット版・64ビット版の区別、つまりPlatformの区別が有ります。
64ビット版(x64)の.NET Frameworkで動いているプログラムにアタッチするには、64ビット版のSDKに含まれているMDbg.exeを使います。
つまり「デバッガのPlatform＝アタッチ先のPlatform」となるように、Platformを合わせる必要が有ります。
起動：
C:\Program Files\Microsoft.NET\SDK\v2.0 64bit\Bin>Mdbg.exe
MDbg (Managed debugger) v2.0.50727.42 (RTM.050727-4200) started.
Copyright (C) Microsoft Corporation. All rights reserved.
For information about commands type "help";
to exit program type "quit".
mdbg>
「a」コマンドで、アタッチ可能なプロセス一覧を表示します。
mdbg> a
Please choose some process to attach
Active processes on current machine:
(PID: 968) C:\Proj\FNF\bin\Debug\FNF.exe
(ID: 1) FNF.exe
(PID: 4020) C:\Proj\FNF\bin\Debug\FNF.vshost.exe
(ID: 1) FNF.vshost.exe
「a 968」を、実行。968番にアタッチします。
mdbg> a 968
[p#:0, t#:0] mdbg>
ちょっとプロンプトが変わりました。
「p -d」で、デバッガ変数の一覧を表示します。例外落ちで停止しているので、$exが現れています。
[p#:0, t#:0] mdbg> p -d
$ex=System.ComponentModel.Win32Exception
$thread=System.Threading.Thread
「p $ex」で、例外情報を見ます。
[p#:0, t#:0] mdbg> p $ex
$ex=System.ComponentModel.Win32Exception
nativeErrorCode=2
_className=<null>
_exceptionMethod=<null>
_exceptionMethodString=<null>
_message="指定されたファイルが見つかりません。"
_data=<null>
_innerException=<null>
_helpURL=<null>
_stackTrace=array [192]
_stackTraceString=<null>
_remoteStackTraceString=<null>
_remoteStackIndex=0
_dynamicMethods=<null>
_HResult=-2147467259
_source=<null>
_xptrs=0
_xcode=-532459699
情報が見えてきました。
「w」で、スタックトレースを見ます。
[p#:0, t#:0] mdbg> w
Thread [#:0]
*0. System.Diagnostics.Process.StartWithShellExecuteEx (source line information unavailable)
1. System.Diagnostics.Process.Start (source line information unavailable)
2. FNF.Program.Run (Program.cs:13)
3. FNF.Program.Main (Program.cs:9)
Process.Startの中でトラぶっているのが判ります。
これで大体の原因は判ると思います。
それで、今回の例外落ちプログラムのソースコードは次のようになっています：
using System;
using System.Collections.Generic;
using System.Text;
using System.Diagnostics;
namespace FNF {
class Program {
static void Main(string[] args) {
new Program().Run();
}
private void Run() {
Process.Start(Guid.NewGuid().ToString("N") + ".exe");
}
}
}
今回は、
.NET SDK コマンド ライン デバッガ (MDbg.exe) を用いて進めていきます。
.NET Framework 2.0 SDK等、SDKを入れていないと使えません。納品先等で活用したい場合は、持ち運ぶ等の工夫をします。
使用の際の注意点を：
「Error: デバッグ対象とデバッガが互換性のないプラットフォームにあるので、操作に失敗しました。 (HRESULT からの例外: 0x80131C30)」
32ビット版・64ビット版の区別、つまりPlatformの区別が有ります。
64ビット版(x64)の.NET Frameworkで動いているプログラムにアタッチするには、64ビット版のSDKに含まれているMDbg.exeを使います。
つまり「デバッガのPlatform＝アタッチ先のPlatform」となるように、Platformを合わせる必要が有ります。
起動：
C:\Program Files\Microsoft.NET\SDK\v2.0 64bit\Bin>Mdbg.exe
MDbg (Managed debugger) v2.0.50727.42 (RTM.050727-4200) started.
Copyright (C) Microsoft Corporation. All rights reserved.
For information about commands type "help";
to exit program type "quit".
mdbg>
「a」コマンドで、アタッチ可能なプロセス一覧を表示します。
mdbg> a
Please choose some process to attach
Active processes on current machine:
(PID: 968) C:\Proj\FNF\bin\Debug\FNF.exe
(ID: 1) FNF.exe
(PID: 4020) C:\Proj\FNF\bin\Debug\FNF.vshost.exe
(ID: 1) FNF.vshost.exe
「a 968」を、実行。968番にアタッチします。
mdbg> a 968
[p#:0, t#:0] mdbg>
ちょっとプロンプトが変わりました。
「p -d」で、デバッガ変数の一覧を表示します。例外落ちで停止しているので、$exが現れています。
[p#:0, t#:0] mdbg> p -d
$ex=System.ComponentModel.Win32Exception
$thread=System.Threading.Thread
「p $ex」で、例外情報を見ます。
[p#:0, t#:0] mdbg> p $ex
$ex=System.ComponentModel.Win32Exception
nativeErrorCode=2
_className=<null>
_exceptionMethod=<null>
_exceptionMethodString=<null>
_message="指定されたファイルが見つかりません。"
_data=<null>
_innerException=<null>
_helpURL=<null>
_stackTrace=array [192]
_stackTraceString=<null>
_remoteStackTraceString=<null>
_remoteStackIndex=0
_dynamicMethods=<null>
_HResult=-2147467259
_source=<null>
_xptrs=0
_xcode=-532459699
情報が見えてきました。
「w」で、スタックトレースを見ます。
[p#:0, t#:0] mdbg> w
Thread [#:0]
*0. System.Diagnostics.Process.StartWithShellExecuteEx (source line information unavailable)
1. System.Diagnostics.Process.Start (source line information unavailable)
2. FNF.Program.Run (Program.cs:13)
3. FNF.Program.Main (Program.cs:9)
Process.Startの中でトラぶっているのが判ります。
これで大体の原因は判ると思います。
それで、今回の例外落ちプログラムのソースコードは次のようになっています：
using System;
using System.Collections.Generic;
using System.Text;
using System.Diagnostics;
namespace FNF {
class Program {
static void Main(string[] args) {
new Program().Run();
}
private void Run() {
Process.Start(Guid.NewGuid().ToString("N") + ".exe");
}
}
}
～は動作を停止しました (CLR20r3編)
納品先などで、.NET Framework用プログラムが例外落ちした際の、例外情報の取得方法について考えてみたいと思います。
例外落ちの際、次のような画面が表示されると思います。
「問題の詳細」を一見しても、中身が判らないことが多いです：
---
説明:
Stopped working
問題の署名 01: fnf.exe
問題の署名 02: 1.0.0.0
問題の署名 03: 4f921d53
問題の署名 04: System
問題の署名 05: 2.0.0.0
問題の署名 06: 4ea78da2
問題の署名 07: 3aae
問題の署名 08: 288
問題の署名 09: System.ComponentModel.Win32
OS バージョン: 6.1.7601.2.1.0.272.33
ロケール ID: 1041
---
「System.Component.Win32Exceptionが発生したのか」程度は読み取ることができます。
イベントビューアで確認しても、似たような情報しか無いので、詳細に行き着きません。
そこで、プログラム終了する前に、デバッガをアタッチし、原因を追究します。
ここからは、デバッガごとに記事を分けたいと思います：
MDbg.exe
例外落ちの際、次のような画面が表示されると思います。
「問題の詳細」を一見しても、中身が判らないことが多いです：
---
説明:
Stopped working
問題の署名:
問題イベント名: CLR20r3問題の署名 01: fnf.exe
問題の署名 02: 1.0.0.0
問題の署名 03: 4f921d53
問題の署名 04: System
問題の署名 05: 2.0.0.0
問題の署名 06: 4ea78da2
問題の署名 07: 3aae
問題の署名 08: 288
問題の署名 09: System.ComponentModel.Win32
OS バージョン: 6.1.7601.2.1.0.272.33
ロケール ID: 1041
オンラインのプライバシーに関する声明をお読みください:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0411
オンラインのプライバシーに関する声明が利用できない場合は、プライバシーに関する声明をオフラインでお読みください:
C:\Windows\system32\ja-JP\erofflps.txt---
「System.Component.Win32Exceptionが発生したのか」程度は読み取ることができます。
イベントビューアで確認しても、似たような情報しか無いので、詳細に行き着きません。
そこで、プログラム終了する前に、デバッガをアタッチし、原因を追究します。
ここからは、デバッガごとに記事を分けたいと思います：
MDbg.exe
2012年4月5日木曜日
netatalk-2.xをCygwinでビルドしますとcat: command not found等を連発する件
Cygwinにて、netatalkのconfigureを実行中、Checking Berkeley DB libraryの辺りから挙動が怪しくなります：
checking Berkeley DB library (-ldb46)...
./configure: line 31862: cat: command not found
./configure: line 31865: cat: command not found
./configure: line 31866: cat: command not found
./configure: line 31889: rm: command not found
./configure: line 31919: sed: command not found
PATHが壊されているものと推測。
追求してみました。次の行で壊れています：
eval export $shlibpath_var=$bdblibdir
このshlibpath_varの出所は：
dynamic_linker='Win32 ld.exe'
# FIXME: first we should search . and the directory the executable is in
shlibpath_var=PATH
ここで壊れる原因を作っているようです。
取り敢えずの回避策につきましては、
aclocal.m4を修正します：
dynamic_linker='Win32 ld.exe'
# FIXME: first we should search . and the directory the executable is in
shlibpath_var=LIBPATH
PATHをLIBPATHに変えただけです。
この後、
autoconf
./configure --with-bdb=/usr/local
make
等でビルドを進めて行きます。
netatalk-3 の場合は、ちょっと下の『shlibpath_varの件は』を参照。
―――
bin/megatron/macbin.cの90行目辺り：
bin.gmtoff = tp->tm_gmtoff;
tm_gmtoffが無い、といわれた場合は、config.hのNO_STRUCT_TM_GMTOFFを定義する必要が有りそうです。
/* Define if the gmtoff member of struct tm is not available */
#define NO_STRUCT_TM_GMTOFF 1
本当は、configure.acを触って、cygwinの場合は、AC_DEFINE(NO_STRUCT_TM_GMTOFF)を加えるのがより良い方法と思いますが、今回はこれで。。。
―――
shlibpath_varの件は、/usr/share/aclocal/libtool.m4を修正した方が根本解決になるかもしれません。：
# FIXME: first we should search . and the directory the executable is in
shlibpath_var=LIBPATH
libtool.m4が無い場合は、Cygwinのsetup.exeでlibtoolを入れておきましょう
次に、再構築：
aclocal -I macros
autoconf
./configure --with-bdb=/usr/local
make
―――
NO_STRUCT_TM_GMTOFFの件は、configure.acを修正できます：
1箇所目。前後の文言で探して、太字部分を足す：
dnl --------------------- determine operating system from "target"
case "$host_os" in
...
*cygwin*) this_os=cygwin ;;esac
2箇所目。前後の文言で探して、太字部分を足す：
dnl ----- Cygwin specific -----
if test x"$this_os" = "xcygwin"; then
AC_MSG_RESULT([ * CYGWIN specific configuration])
AC_DEFINE(NO_STRUCT_TM_GMTOFF, 1, [Define if the gmtoff member of struct tm is not available])
fi
dnl ------ Check for sendfile() --------
次に、再構築：
autoconf
./configure --with-bdb=/usr/local
make
―――
checking whether to enable srvloc (SLP) support... no
./configure: line 15955: syntax error near unexpected token `AVAHI,'
macros/zeroconf.m4で、PKG_CHECK_MODULESが解決できないために出ている様です。
Cygwinのsetup.exeで、pkg-configを入れましょう。
―――
/bin/sh ../../libtool --tag=CC --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../include -D_U_="__attribute__((unused))" -g -O2 -I../../sys -MT cache.lo -MD -MP -MF .deps/cache.Tpo -c -o cache.lo cache.c
../../libtool: line 879: X--tag=CC: command not found
../../libtool: line 912: libtool: ignoring unknown tag : command not found
../../libtool: line 879: X--mode=compile: command not found
netatalk付属のlibtoolの挙動が怪しかったら、/bin/libtoolから持って来ましょう。
―――
checking Berkeley DB library (-ldb46)...
./configure: line 31862: cat: command not found
./configure: line 31865: cat: command not found
./configure: line 31866: cat: command not found
./configure: line 31889: rm: command not found
./configure: line 31919: sed: command not found
PATHが壊されているものと推測。
追求してみました。次の行で壊れています：
eval export $shlibpath_var=$bdblibdir
このshlibpath_varの出所は：
dynamic_linker='Win32 ld.exe'
# FIXME: first we should search . and the directory the executable is in
shlibpath_var=PATH
ここで壊れる原因を作っているようです。
取り敢えずの回避策につきましては、
aclocal.m4を修正します：
dynamic_linker='Win32 ld.exe'
# FIXME: first we should search . and the directory the executable is in
shlibpath_var=LIBPATH
PATHをLIBPATHに変えただけです。
この後、
autoconf
./configure --with-bdb=/usr/local
make
等でビルドを進めて行きます。
netatalk-3 の場合は、ちょっと下の『shlibpath_varの件は』を参照。
―――
bin/megatron/macbin.cの90行目辺り：
bin.gmtoff = tp->tm_gmtoff;
tm_gmtoffが無い、といわれた場合は、config.hのNO_STRUCT_TM_GMTOFFを定義する必要が有りそうです。
/* Define if the gmtoff member of struct tm is not available */
#define NO_STRUCT_TM_GMTOFF 1
本当は、configure.acを触って、cygwinの場合は、AC_DEFINE(NO_STRUCT_TM_GMTOFF)を加えるのがより良い方法と思いますが、今回はこれで。。。
―――
shlibpath_varの件は、/usr/share/aclocal/libtool.m4を修正した方が根本解決になるかもしれません。：
# FIXME: first we should search . and the directory the executable is in
shlibpath_var=LIBPATH
libtool.m4が無い場合は、Cygwinのsetup.exeでlibtoolを入れておきましょう
次に、再構築：
aclocal -I macros
autoconf
./configure --with-bdb=/usr/local
make
―――
NO_STRUCT_TM_GMTOFFの件は、configure.acを修正できます：
1箇所目。前後の文言で探して、太字部分を足す：
dnl --------------------- determine operating system from "target"
case "$host_os" in
...
*cygwin*) this_os=cygwin ;;esac
2箇所目。前後の文言で探して、太字部分を足す：
dnl ----- Cygwin specific -----
if test x"$this_os" = "xcygwin"; then
AC_MSG_RESULT([ * CYGWIN specific configuration])
AC_DEFINE(NO_STRUCT_TM_GMTOFF, 1, [Define if the gmtoff member of struct tm is not available])
fi
dnl ------ Check for sendfile() --------
次に、再構築：
autoconf
./configure --with-bdb=/usr/local
make
―――
checking whether to enable srvloc (SLP) support... no
./configure: line 15955: syntax error near unexpected token `AVAHI,'
macros/zeroconf.m4で、PKG_CHECK_MODULESが解決できないために出ている様です。
Cygwinのsetup.exeで、pkg-configを入れましょう。
―――
/bin/sh ../../libtool --tag=CC --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../include -D_U_="__attribute__((unused))" -g -O2 -I../../sys -MT cache.lo -MD -MP -MF .deps/cache.Tpo -c -o cache.lo cache.c
../../libtool: line 879: X--tag=CC: command not found
../../libtool: line 912: libtool: ignoring unknown tag : command not found
../../libtool: line 879: X--mode=compile: command not found
netatalk付属のlibtoolの挙動が怪しかったら、/bin/libtoolから持って来ましょう。
―――
2012年4月2日月曜日
libtiffをCygwinでビルドするオプション
./configure "CXXFLAGS=-static -static-libgcc" "CFLAGS=-static -static-libgcc"
登録:
投稿 (Atom)