【GUI】wxWidgets(旧wxWindows) その5【サイザー】

【GUI】wxWidgets(旧wxWindows) その5【サイザー】 (960ﾚｽ)
上下前次 1-新

671: 2014/08/29(金)19:04 ID:GS9LyL7J(1) AAS
その説明にac1だの何だの自分以外分からない定義を使う必要があったのだろうか

672: 2014/08/29(金)19:07 ID:AEJEOYpd(2/2) AAS
今から見るとそうかも。
a: Windows Native or MFC
b: wzWidgets
c: CUI
g: GUI
r:release, d:debug
d:dynamic link, s:static link

673(1): 2014/08/30(土)00:17 ID:S/CtHe8u(1/4) AAS
>>668

>最後の段落：多分、wxWidgets 本体を MInGW32 用のビルドする際は、
>configure は使えない気がする。

なにいってんだCodeBlocksのドキュメントにそう書いてあるだけで
基本autotoolsで作られたソースはconfigureでビルドできるぞ
実際自分はWindows上のmingw32/64、LinuxのクロスビルドからのMinGWでconfigure使ってる

なぜMakefileでやれという指示なのかというと、そのほうが簡潔で保守しやすいからだ
省4

674(3): 2014/08/30(土)00:21 ID:S/CtHe8u(2/4) AAS
>>670
MinGWビルドでバイナリをストリップしたやつとか比較しないのか

675: 2014/08/30(土)07:56 ID:pUv0T+7B(1/5) AAS
>>674
Stripに詳しくないので、言っている意味が分からない。

Stripって Release 用に Build した Binary に対して行っても
サイズダウンできたりするの？

676: 2014/08/30(土)07:58 ID:pUv0T+7B(2/5) AAS
>>674
Stripに詳しくないので、言っている意味が分からない。

Stripって Release 用に Build した Binary に対して行っても
サイズダウンできたりするの？

677: 2014/08/30(土)08:15 ID:hpIa4Qjb(1) AAS
日本語インライン入力の対応ってまだなの？
というか予定自体なくて諦めた方がいい？
wxWidgets使ってるEditraってエディタにそろそろ移行できるかなと
思って試してみたら、未だにインライン入力できない

678(3): 2014/08/30(土)08:19 ID:pUv0T+7B(3/5) AAS
>>674

小さくなりますた!!

Relese, 動的リンク
/wxWidgets-2.8.12/samples/keyboard/gcc_mswdll/keyboard.exe

strip 前：299,808 bytes
strip 後：124,430 bytes

Relese, 静的リンク
省4

679(1): 2014/08/30(土)08:22 ID:pUv0T+7B(4/5) AAS
>>673
>エディタの補助機能を使うべきだ、Emacsなら矩形範囲選択で一気に書ける

詳しく：

680: 2014/08/30(土)11:51 ID:RJxcDZkh(1) AAS
馬鹿には無理

681(1): 2014/08/30(土)12:02 ID:S/CtHe8u(3/4) AAS
スタンド・アローン・コンプレックスと化した馬鹿には無理さんオッスオッス

>>679
cua-modeでググって
外部ﾘﾝｸ:qiita.com

例えばイベントテーブルとかはこれでザクッと一気に書ける
もちろん個々のwxWindowIDとメソッド定義は書かなくてはいけないが
クラス名とマクロ定義は同じ文字列の繰り返しなのでだいぶ楽になる

682(1): 2014/08/30(土)13:53 ID:pUv0T+7B(5/5) AAS
>>681
あー、そういう風に沢山のイベントを一気に書きたいんじゃなくて、
開発段階で徐々にイベントを追加して行く際に、

1. *.h のクラス内にメンバ関数宣言
2. *.cpp に EVENT MAP
3. *.cpp にメンバ関数定義の本体

の三箇所にコードを書くのが面倒ということなんだわ。

683: 2014/08/30(土)14:33 ID:S/CtHe8u(4/4) AAS
>>682
それは自分で作らないと無さげですねえ

684: 2014/08/30(土)19:11 ID:5dlfaubU(1) AAS
wxFormBuilderでしかGUIとイベントを設計できない俺には何言ってるのかさっぱりわからんぜよ……

685(1): 678 2014/08/31(日)15:54 ID:X+I89xFV(1/3) AAS
wxAUI のデモ・アプリ wxauitest.exe のサイズは、1,417,216 bytes。
スタンドアロンのアプリで、環境変数からパスを完全に消去しても起動
できた。つまり、ライブラリはDLLを使わずに静的リンクされている。
wxAUIはFloating & Dockingのできる強力なGUI。

>>678 に示した keyboard.exe はキーボードから押されたキーの値を
表示するだけで、上記アプリよりずっとシンプルなのにも関わらず、
1,887,758 bytes と 470,542 bytes も大きい。
省1

686: 2014/08/31(日)15:56 ID:5rh0udnx(1/2) AAS
そんなことしなくても
DLLの依存関係調べるツールあるのに

687(1): 2014/08/31(日)16:01 ID:5rh0udnx(2/2) AAS
ちなみにwxWidgetsで作った一番小さいexe探したら65kbのがあった

688(1): 678 2014/08/31(日)17:34 ID:X+I89xFV(2/3) AAS
Windows実行形式であっても、コンパイラが、MinGW32 と VC++ でサイズに
大幅な違いが出てくるのかな？

689: 678 2014/08/31(日)17:41 ID:X+I89xFV(3/3) AAS
>>687
それは DLL 版だよ。絶対に。

690: 2014/08/31(日)19:56 ID:F1QgxQvq(1/2) AAS
>>685
実行ファイルの関数テーブルに何が入っているか nm で確認したら少しはわかるかもね

>>688
大幅とは行かないかもしれないがVC++はWindowsのみをターゲットにしているから
基本的にコンパイル後のバイナリサイズは MinGW ＞ VC++ だよね

691(2): 2014/08/31(日)20:18 ID:da+aRwUf(1/8) AAS
CodeBlocks + MinGW32 で、
wxWidgets の Monolithic、ASCIIライブラリ, 静的リンクで
最も簡単な Frame Based な GUI を作成してみたら、
2,073,600 バイトよりは小さくならなかった。

wxWidgets のライブラリは、
-Os
-ffunction-sections
省15

692(2): 2014/08/31(日)20:27 ID:da+aRwUf(2/8) AAS
ちなみに、Unicode 版より ASCII 版のほうが小さくなることを確認済みである。

[Compiler settings - #defines]
が、標準では、
__GNUWIN32__, __WXMSW__, WXUSINGDLL, wxUSE_UNICODE, WX_PRECOMP
となるところを：
__GNUWIN32__, __WXMSW__
だけとし、
省20

693: 2014/08/31(日)20:33 ID:da+aRwUf(3/8) AAS
誤：[Search Directories] の Compiler, Linker, Compiler
正：[Search Directories] の Compiler, Linker, Resource Compiler

誤：Win32のimport libraryは、ライブラリを動的リンクする場合はライブ
　　ラリのDLLが行っているの
正：wxWidgets ライブラリをアプリに動的リンクする場合は
　　wxWidgets ライブラリの DLL 部分が Win32 の import library の
　　リンクを行っているの

694(3): 2014/08/31(日)20:45 ID:0aT2mco7(1) AAS
サイズはどうでもよくないか。exeを使う側としては速度では?
あとコア、主要のライブラリのビルドから、ダイナミックリンクを徹底してOSに丸投げしたら小さくなるだろ。

695: 2014/08/31(日)20:48 ID:ks+4W1rG(1/2) AAS
完全テンプレートライブラリにしたら軽くなるんだろうか

696(1): 2014/08/31(日)20:58 ID:da+aRwUf(4/8) AAS
>>694
でも wxWidgets がやっていることの割にはリンクされるバイト数が多すぎる
感じがする。
基本、Win32をラッピングしているだけなのだから、2MBも必要ない。

697(3): 2014/08/31(日)21:00 ID:ks+4W1rG(2/2) AAS
ラッピングしてるだけじゃなくマルチプラットフォームのために徹底した抽象化をしてるんでしょ
とソースも読まず推測

698: 2014/08/31(日)21:04 ID:da+aRwUf(5/8) AAS
>>697
でもソースを呼んでみたら、たとえば、wxListCtrl なんかは、
Win32 の LIST CONTROL をそのまま使っていた。
DrawRect()などで書いているわけではない。
ただし、wxGenericListCtrl だったかは、DrawRect()みたいなグラフィック
関数で独自に描画していた。が、それは、Windows版では簡単には使えない
という噂を聞いたが。

699: 2014/08/31(日)21:06 ID:da+aRwUf(6/8) AAS
>>697
wxWidgets の基本設計は、Widgetは、OS nativeの物を使うが、
どんなサイズであっても対応できるように Sizer で Layout を
コントロールする、という物。

なので、抽象化はサイズと配置程度で済むはずなのだが・・・。

700(1): 2014/08/31(日)21:09 ID:F1QgxQvq(2/2) AAS
>>696

>>697の言ってることが正しい。

---------------------
　　　　wxWidgets
---------------------
Win32 | GTK | Cocoa etc...
---------------------
省7

701: 2014/08/31(日)23:57 ID:da+aRwUf(7/8) AAS
wxWidgets の samples で ListCtrl 関連を見てみたが、ヘッダを
ドラッグしようとしてもドラッグできないので、ドラッグによる列の入れ替
えは出来ないようだった。

実は、Win32 の LIST CONTROL は、

・マウスドラッグによる自動的な列の入れ替えをした際、どこにどの列が
　行ったかを掌握するには注意が必要。動作を知るには基本的に実験を必要
　とする。
省4

702: 2014/08/31(日)23:59 ID:da+aRwUf(8/8) AAS
wxWidgets の samples で ListCtrl 関連を見てみたが、ヘッダを
ドラッグしようとしてもドラッグできないので、ドラッグによる列の入れ替
えは出来ないようだった。

実は、Win32 の LIST CONTROL は、

・マウスドラッグによる自動的な列の入れ替えをした際、どこにどの列が
　行ったかを掌握するには注意が必要。動作を知るには基本的に実験を必要
　とする。
省4

703(1): 2014/09/01(月)00:00 ID:X69OanmZ(1/10) AAS
>>700
>wxWidgetsは通常のGUI用ライブラリに一枚レイヤを重ねた形になるので
>型情報・関数テーブルの情報だけで結構容量食う

オイラはコンパイラの基本部分に詳しいが、それだけで1MBなどには
ならない。

704(1): 2014/09/01(月)00:06 ID:X69OanmZ(2/10) AAS
>>694
諦めることも手かも知れないけど、やっている事の規模とサイズとの
ギャップに納得がいかない人もいるはず。

wxWidgetsはラッピング・ライブラリの一種。

8bit時代、16bit時代を知る人にとって、Widget 程度が64KBを超える
事があってはならない。どういうプログラミングをしたら2MBにもなる
のか。

705: 2014/09/01(月)01:16 ID:7Pg7L2PA(1) AAS
>>703
>>704
一理あるのでちょっとメーリングリストを探ってみたり
まず、wx/wx.hがいろいろなヘッダファイルを事前にincludeしているので
それがバイナリサイズの増加の一因になっているらしい

[wxMSW]: why EXE-files are so large?
外部ﾘﾝｸ:groups.google.com

706: 2014/09/01(月)07:25 ID:X69OanmZ(3/10) AAS
>>591 のライブラリを samples/keyboard にも使ってみたら、
keyboard.exe のサイズを 1,619,968 にまで縮小することに成功した。
コンパイラは MinGW32 のまま。
条件は：release, 非UNICODE(ASCII), SHARED=0(静的リンク), MONOLITHIC = 1

どうやら MONOLITHIC であるかどうかは最終 exe サイズには関係してないらしい。
ライブラリと言うのは集めてもばらしても、最終 exe のリンク結果には影響を
及ぼさない事が基本なので、元々当たり前なことなのだが。
省17

707: 2014/09/01(月)07:31 ID:X69OanmZ(4/10) AAS
誤：>>591
正：>>691

708: 【大吉】 2014/09/01(月)07:40 ID:zQucGkuf(1) AAS
wxWidgets の samples で ListCtrl 関連を見てみたが、ヘッダを
ドラッグしようとしてもドラッグできないので、ドラッグによる列の入れ替
えは出来ないようだった。

実は、Win32 の LIST CONTROL は、

・マウスドラッグによる自動的な列の入れ替えをした際、どこにどの列が
　行ったかを掌握するには注意が必要。動作を知るには基本的に実験を必要
　とする。
省4

709: 2014/09/01(月)07:45 ID:X69OanmZ(5/10) AAS
>>694
>あとコア、主要のライブラリのビルドから、ダイナミックリンクを徹底してOSに丸投げしたら小さくなるだろ。

「>>692」で示した Win32 import library は、Windows のシステム DLL
をリンクするための小さなライブラリ。例えば、
libcomctrl32 をリンクしていても、実際は、comctrl32.dll が動的リンク
される。libcomctrl32.a は、MinGW32 が用意している import library で：

/xxx/CodeBlocks/MinGW/lib/libcomctl32.a　# 86,428 bytes
省3

710: 2014/09/01(月)08:18 ID:1emh7fCQ(1) AAS
map出力して何がリンクされてるか見れば？

711: 2014/09/01(月)14:09 ID:X69OanmZ(6/10) AAS
MONOLITHIC の値が違うと別の *.o が作成されることが判明。
以下は、SHARED=0(静的リンク)の場合の、MONOLITHIC が 0 と 1 の場合。

CORELIB_CXXFLAGS = $(__DEBUGINFO) $(__OPTIMIZEFLAG) $(__THREADSFLAG) \
　　$(GCCFLAGS) -DHAVE_W32API_H -D__WXMSW__ $(__WXUNIV_DEFINE_p) \
　　$(__DEBUG_DEFINE_p) $(__NDEBUG_DEFINE_p) $(__EXCEPTIONS_DEFINE_p) \
　　$(__RTTI_DEFINE_p) $(__THREAD_DEFINE_p) $(__UNICODE_DEFINE_p) \
　　$(__MSLU_DEFINE_p) $(__GFXCTX_DEFINE_p) -I$(SETUPHDIR) -I..\..\include \
省13

712: 2014/09/01(月)14:13 ID:X69OanmZ(7/10) AAS
違いは、-DwxUSE_BASE の部分で、
　MONOLITHIC = 0 の場合 : -DwxUSE_BASE=0　 // #define wxUSE_BASE 0
　MONOLITHIC = 1 の場合 : -DwxUSE_BASE=1　 // #define wxUSE_BASE 1
となっている。

例えば、/xxx/src/msw/dc.cpp は、同じソースに対し make に渡すオプションに応じて
以下の2種類の *.o ファイルが作成される。
1つ目は、MONOLITHIC=0の時に作られ、2つ目は、MONOLITHIC=1の時に作られる。
省12

713(1): 2014/09/01(月)15:21 ID:M8Jh9ISi(1) AAS
別に驚くほどのことじゃ無いけど

714: 2014/09/01(月)16:14 ID:X69OanmZ(8/10) AAS
>>713
コンパイルオプションまで変えてしまって何をやっているかと言うこと
なんだよ。ライブラリの集め方だけの問題じゃないって事なんだ。

ライブラリの動作が変わってしまい、MONOLITHIC が 0 と 1とで結果が違うことに
悩まされる可能性もある。

単にライブラリのオブジェクトの集め方（含み方）の問題では無いとすると、MONOLITHIC
オプションの意味はいったい何かと言う問題になる。
省4

715: 2014/09/01(月)16:33 ID:X69OanmZ(9/10) AAS
外部ﾘﾝｸ:wiki.wxwidgets.org

「MONOLITHIC=1 :
　Packages all libraries in a single file.
　(Note: do not combine this option with a static build.)」

とあった。static build の時は、MONOLITHIC=1 にするな、と
書かれている・・・。

716: 2014/09/01(月)16:49 ID:zU7EZBBQ(1) AAS
いったい何を目的として何を検証しているんだ？

717(1): 2014/09/01(月)17:12 ID:bPa0tOdz(1) AAS
このライブラリを使うなとなる。

718: 2014/09/01(月)17:31 ID:X69OanmZ(10/10) AAS
>>717
そういうわけではない。

719(1): 2014/09/02(火)13:46 ID:TmMSlGm8(1/12) AAS
configure を試してみたら、configureのヘルプ通りには行かなかった：

・以下、xxx = wxWidgets-2.8.12 とする。/xxx/ に configure スクリプトがある。

・configureを使用するために、単なるcmd.exeではなくcygwin環境が必要であった。

・cygwinを起動する際、cygwin に入ってからの PATH が、
　(MinGWのbin) : /usr/local/bin/ : /usr/bin/ : (Winからのbin)
　の順になるようにした。

・カレントを /xxx/ にして configure した。configure の引数には少なくとも
省12

720(1): 2014/09/02(火)13:46 ID:TmMSlGm8(2/12) AAS
・regex, zlib, jpeg, png, tiff は全て無効にしていたにも関わらず、
　src/regex, src/zlib, src/jpeg, src/tiff にしかない *.h ファイルが見つから
　ないエラーとなった。。
　そこで、Makfileを直接修整して、CPPFLAGS に -I 指定によって、上記ディレクトリ
　を最後尾に追加した。

・make には成功した。

・/xxx/ に大量の *.o ファイルが作られ、*.a は /xxx/lib/ に作られた。
省7

721(2): 2014/09/02(火)13:48 ID:TmMSlGm8(3/12) AAS
・regex, zlib, jpeg, png, tiff は全て無効にしていたにも関わらず、
　src/regex, src/zlib, src/jpeg, src/tiff にしかない *.h ファイルが見つから
　ないエラーとなった。。
　そこで、Makfileを直接修整して、CPPFLAGS に -I 指定によって、上記ディレクトリ
　を最後尾に追加した。

・make には成功した。

・/xxx/ に大量の *.o ファイルが作られ、*.a は /xxx/lib/ に作られた。
省7

722: 2014/09/02(火)16:41 ID:TmMSlGm8(4/12) AAS
console.cpp の中身を printf() だけを使う4行の main() 関数だけに
書き換えてみたら問題なく起動して普通に文字列が表示された。

なので、MinGW 環境の問題ではなさそう。

723: 2014/09/02(火)17:12 ID:TmMSlGm8(5/12) AAS
wxPrintf()だけを使った console 版 hello world が、static link
で 96,468 bytes で済んだ。

ところが、wxString を使った場合、作成した exe を実行しようとすると
>>721 後半で書いたメッセージ・ボックスが出て起動できない。

724(1): 2014/09/02(火)17:17 ID:DoCZo715(1/2) AAS
libstdc++がダイナミックリンクになってるだけだろ。

725(1): 2014/09/02(火)17:44 ID:TmMSlGm8(6/12) AAS
>>724
ダイナミックライブラリであるところの
　libstdc++-6.dll
は既に読み込めているんですわ。
「libstdc++-6.dll から見つかりませんでした。」
の「から」がそれを表している。

なお、configureを使わずに、build/msw から build したライブラリだと
省2

726(2): 2014/09/02(火)19:04 ID:DoCZo715(2/2) AAS
パスが通ったところに互換性のない別バージョンのdllがあるんだろ。
mingwだとsjljとdw2の２種類あるから。

727(1): 2014/09/02(火)19:56 ID:TmMSlGm8(7/12) AAS
MinGW/bin を

i686-pc-mingw32-g++ と MinGW/bin/g++ は別物らしくコンパイラのサイズ
（作ったプログラムのサイズではなく変換機のサイズ）がそもそも違う。

また、前者では、リンク段階で何もエラーを出さないが、
後者では、ちゃんと、_gxx_persolanity_v0 や _Unwind_Resume が
undefined reference というエラーになる。

728: 2014/09/02(火)20:00 ID:TmMSlGm8(8/12) AAS
>>726
最初、xxx dw2 yyy.dll が見つからない、と言うメッセージ・ボックス
が出たのだが、そのdllを検索すると MinGW/bin にある事が分かって、
そこにパスを通したらそのメッセージ・ボックスは出なくなった。

その代わりに >>721 のメッセージ・ボックスが出るようになった。

729(1): 2014/09/02(火)20:55 ID:TmMSlGm8(9/12) AAS
結論的に言うと、自分のローカルにMinGW32 の別バージョンが沢山あった。
サンプルのコンパイルに使われたのと同じMinGW32のbinだけをパスに
設定してからサンプルを起動すると実行できるようになった。
実行結果も問題ない。実行ファイルはstripするとサイズが小さくなったが、
>>691のライブラリをリンクした物よりも大きくなってしまった。

[wxStringを使った最小な cui program のサイズ]

・>>691 のwxライブラリ使用時 : 451,584 bytes
省10

730: 2014/09/02(火)21:12 ID:WV3CuJcS(1) AAS
よかったな
-Wl,-Bstatic -lstdc++ -Wl,-Bdynamic
にすればlibstdc++とスタティックリンクできるかもな

731(1): 2014/09/02(火)22:46 ID:TmMSlGm8(10/12) AAS
cygwin版のMinGWと、cmd.exe 版のMinGWって結構違うような気がしてきた。
Makefileなんかもcygwin版だと/cygdrive/c/xxx/yyy/zzz の形式になっている
のに対し cmd.exe版は c:\xxx\yyy\zzz になっているらしい。
また、コンパイラに -I 指定したパスなんかも同様の違いがあるらしく、
configureが作ったMakefileは、cygwin版MinGW用で、
cmd.exe版のMinGWでは、#inclde "wx/setup.h" のパスが探せなかったり
する。
省6

732(1): 2014/09/02(火)22:56 ID:RsSqk3ed(1) AAS
もう完璧にスレ違いだな

733: 2014/09/02(火)22:56 ID:TmMSlGm8(11/12) AAS
cygwin版のMinGWと、cmd.exe 版のMinGWって結構違うような気がしてきた。
Makefileなんかもcygwin版だと/cygdrive/c/xxx/yyy/zzz の形式になっている
のに対し cmd.exe版は c:\xxx\yyy\zzz になっているらしい。
また、コンパイラに -I 指定したパスなんかも同様の違いがあるらしく、
configureが作ったMakefileは、cygwin版MinGW用で、
cmd.exe版のMinGWでは、#inclde "wx/setup.h" のパスが探せなかったり
する。
省6

734: 2014/09/02(火)22:57 ID:TmMSlGm8(12/12) AAS
>>732
wx アプリのサイズダウンの仕方関連なんだけど。

735: 2014/09/02(火)23:40 ID:wgXgojMH(1) AAS
作ったバイナリのサイズなんてwxWidgetsのビルド方法によって大きく変わるうえ、
最終的に使い物にならないライブラリの出来上がりとなるのが目に見えている
本当に必要なものだけを炙り出すつもりなら止めはしないが、どう考えても徒労でしかないと思うぞ

736: 2014/09/02(火)23:47 ID:r9jqoPj2(1/2) AAS
正直wxWidgetsのバイナリサイズの話以外はほとんど既出だし
CygwinとMinGWの仕様の違い、クロスコンパイラのターゲット、configureの基本
それらの件に関しては自分のブログにでも書いていてほしい

737(1): 2014/09/02(火)23:54 ID:r9jqoPj2(2/2) AAS
まあ一応上から目線でコメントしとくと

>>725
libgccの存在に関して勉強不足、>>726の言うとおりdllの種別が２種類ある
DLLにするよりもlibgccだけスタティックリンクしたほうがいいが、libtoolにかませるのが
割と面倒なので一緒に配布したほうが楽、まぜこぜにするとか初心者くさい

>>727
クロスコンパイラとネイティブコンパイラを混同している
省3

738(1): 2014/09/03(水)00:12 ID:RSu3l9Ti(1) AAS
AA省

739: 2014/09/03(水)00:20 ID:qMd+w6/O(1) AAS
>>738
スレ違いだ、こっちでやれ
Cygwin + MinGW + GCC 相談室 Part 7
2chｽﾚ:tech

あとMinGWはcmd.exeではなくminttyから使うべきだ
さっさとネットで資料を探す作業に戻るんだな

740: 2014/09/03(水)00:37 ID:kYvXCnau(1/3) AAS
ちなみに c:\cygwin\bin と c:\cygwin\usr\local\bin にパスを通せば、
cmd.exe からでも cygwin のコマンドが実行できるようになる。
gccもlsもmakeも。ここでbashを起動すればcygwin環境になる。

741: 2014/09/03(水)08:47 ID:VnTCGwbS(1) AAS
久しぶりに２ちゃん観に来たら
wxのスレめっちゃ野比てて嬉しい

742(1): 2014/09/03(水)14:50 ID:kYvXCnau(2/3) AAS
wx のソースを修正したら、wxString() を使った最小サンプルが、
静的リンクしても 70KB で済むようになった。

PATHには、MInGW/bin しか設定せずにテストしているので、wx の DLL
がリンクされている可能性は無く、間違いなくスタンド・アローンの
プログラム。

ちなみに、wx のソースを修正しなければ、451,584 バイトになってしまう。
>>729 に書いたものとほぼ同じプログラムだから。

743: 2014/09/03(水)15:05 ID:SXoWEkGr(1/2) AAS
wxというよりgccとライブラリのお話で伸びている

744: 2014/09/03(水)16:58 ID:3zk9T5qQ(1) AAS
>>742
dllの依存関係すらまともに調べられないのか
dependency walkerとかobjdumpとか使え

745: 2014/09/03(水)17:02 ID:SXoWEkGr(2/2) AAS
mingw入ってるならlddコマンドでもいける＞依存動的ライブラリ

746: 2014/09/03(水)18:30 ID:kYvXCnau(3/3) AAS
ただ、パス設定を空にして起動できるかどうか見るのも1つの確実な方法。

747: 2014/09/04(木)03:37 ID:FQO1vG1R(1/2) AAS
性格悪いな。
コンピュータ・ソフト関連の人って。

748: 2014/09/04(木)17:23 ID:FQO1vG1R(2/2) AAS
GUIアプリのサイズ縮小を試みていたが、断念するかも知れない。

749(2): 2014/09/04(木)18:46 ID:Sd68Xi30(1) AAS
△性格が悪い
○無駄が嫌い
◎無駄な事をしてる奴が嫌い

750(1): 2014/09/05(金)15:14 ID:PbioWCRT(1) AAS
>>749
何も悪いことをせず、自分にも害を与えない人を嫌うのが性格が悪いんだよ。

751(2): 2014/09/05(金)15:46 ID:JjYqHkIR(1) AAS
公園の蚊を駆除するのに外側からじゃなくて内側から始めるとかが無駄
自分にも危害が及ぶので嫌

上下前次 1-新書関写板覧索設栞歴

あと 209 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.029s