- 1 名前：デフォルトの名無しさん mailto:sage [2010/04/09(金) 15:12:36 .net]
- クロスプラットフォーム GUI ライブラリの wxWidgets (旧 wxWindows)についてのスレ。
本家
ttp://www.wxwidgets.org/
wxWindows日本語プロジェクト
ttp://wxwindowsjp.sourceforge.jp/
Cross-Platform Programming with wxWidgets
ttp://wxwidgets.info/
Let's wxWidgets
ttp://dot-gray.s33.xrea.com/
wxWindowsで始めるC++ GUIプログラミング
ttp://www.h3.dion.ne.jp/~k5_n/wxwin/
wxWidgets でクロスプラットフォーム GUIアプリを作ろう
ttp://0xcc.net/pub/uu-2004-08/
前スレ
【GUI】wxWidgets(旧wxWindows) その4【サイザー】
pc12.2ch.net/test/read.cgi/tech/1214657360/
- 655 名前：デフォルトの名無しさん mailto:sage [2014/08/24(日) 18:20:53.22 ID:Gtnn2j9y.net]
- wxWidgetsで、フォームを閉じる処理をして実際に閉じるまでの間に発生するイベントとかある？
.NETで言うところのOnClosingみたいな感じで。
- 656 名前：デフォルトの名無しさん [2014/08/25(月) 02:12:21.61 ID:OTL7uAT+.net]
- OnClose
OnVeto
- 657 名前：デフォルトの名無しさん mailto:sage [2014/08/25(月) 14:23:49.85 ID:IQl9g11m.net]
- >>656
㌧
おかげで作業が進みました。
- 658 名前：デフォルトの名無しさん mailto:sage [2014/08/26(火) 17:09:00.43 ID:QEgdFK7f.net]
- Windows で、
CrossBlock + MinGW + wxWidget
で最も簡単な GUI アプリを基本プロジェクトで作成してみたところ、
MyTest.exe のサイズ：736KB
(wxWidgetのDLL) wxmsw28u_gcc_custom.dll のサイズ : 15.9MB
MyTest.exe のメモリ使用量 : 7,732KB // TaskManagerの表示
となった。
この基本アプリは、HelpでAboutでメッセージ・ボックスが表示できる
ようになっているが、メニュー項目をクリックしてから実際にそれが
出るまで数秒かかる。実験したのはそこそこ速いマシンと速いWindows
での事。
- 659 名前：デフォルトの名無しさん mailto:sage [2014/08/26(火) 17:09:45.00 ID:QEgdFK7f.net]
- ただし、遅いのは最初の一回だけ。
一度でも表示すると後は速い。
- 660 名前：デフォルトの名無しさん mailto:sage [2014/08/26(火) 17:56:51.72 ID:QEgdFK7f.net]
- Mailer の Thunderbird-Portable なんかもマルチプラットフォーム対応
だけど、起動がかなり遅い。これも巨大な dll を読み込んだりしてる
からかな。
起動やメニュー操作が遅くなるのはマルチプラットフォーム化する代償
として負わされるのかも知れん。
こういうツールキットで軽快なアプリを作るのは難しいのかもな。
- 661 名前：デフォルトの名無しさん mailto:sage [2014/08/26(火) 19:14:34.45 ID:OmJCXozv.net]
- 小規模の自作ソフトでwxWidgetsをスタティックリンクしない理由が分からん
わざわざ合計バイナリサイズを大きく、速度も遅くする理由がどこにあるのだろう
- 662 名前：デフォルトの名無しさん mailto:sage [2014/08/26(火) 21:27:38.25 ID:QEgdFK7f.net]
- >>661
なるほど、スタティックリンクにすれば、起動後になってからユーザーの
命令に対する応答が遅れる事はなくなるかもしれない。
起動が遅くなるだけで済むんなら、そっちの方がストレスが少ないかも。
- 663 名前：デフォルトの名無しさん mailto:sage [2014/08/26(火) 21:50:56.10 ID:JtVIC4MG.net]
- ある程度規模が大きくなるとスタティックリンクだと初回起動が遅すぎになので
dllにモジュールを分割してやったほうがいい
起動時のメモリへのロード時間はどうしようもないのでスプラッシュをつけてごまかす
- 664 名前：デフォルトの名無しさん mailto:sage [2014/08/26(火) 22:39:34.76 ID:QEgdFK7f.net]
- CrossBlockでは、monolithic タイプのライブラリをビルドしてから使う
ようになってるんだけど、それも遅い原因なのかな。
でも起動後にユーザー入力に対するレスポンスが遅いのはどう説明すれば
いいんだろう？
普通の Windows の仕様だと原則、起動時に全ての DLL をロードする。
LoadLibrary()を使えば動的にロードすることも可能は可能だけど、
それをする必要は旧OSでサポートしてなかった新OSのDLLをロードする
ような場合は、多言語化のサポートなど。
なるほど、多言語化のせいかも。_("xxx") みたいなのがあったから、
gettext を使ってる。それでリソースを動的ロードしているのか。
- 665 名前：デフォルトの名無しさん mailto:sage [2014/08/27(水) 04:40:25.51 ID:IfBPvyzm.net]
- 何度かアプリ起動しているうちにWindowsのFetchが学習してくれて
DLLとか先読みしてくれるようにならないのだろうか
- 666 名前：デフォルトの名無しさん mailto:sage [2014/08/27(水) 06:47:58.33 ID:J2peHUgZ.net]
- >>665
それはなる。
・ディスクの内容は、メモリにキャッシュされる。
・同じDLLは、全てのアプリで物理メモリが共有されると聞いたことがある。
# >>664 は、CrossBlockではなく、CodeBlocksだった。スマン。
それより、wxWidget 本家のソース配布に入っている samples を
Windows の mingw32 でビルドしてみたところ、全然遅くなかった。
・アプリの起動は速い。
・起動後のメニューコマンドやユーザー入力に対するレスポンスも速い。
・Aboutダイアログも瞬間ではないが、0.3秒程度で、Windows Nativeアプリ
でも、その程度の遅さはある場合があるので遜色ない。
CodeBlocks で作ったものが遅い原因は今のところ謎。やはり monolithic な
ライブラリを使用しているからか。
- 667 名前：デフォルトの名無しさん mailto:sage [2014/08/27(水) 07:54:18.52 ID:X38Kg7Ty.net]
- >>666
># >>664 は、CrossBlockではなく、CodeBlocksだった。スマン。
なんだと思ったらわりと素人じゃねえかおい
>CodeBlocks で作ったものが遅い原因は今のところ謎。やはり monolithic な
>ライブラリを使用しているからか。
monolithicってのはwxWidgetsのモジュール全部入りのDLL作るという意味なので遅くて当然
（実際試したことないので遅いというのは初めて知ったが…）
普通は ./configure --prefix=/mingw --enable-shared みたいに指定してビルドするから
モジュールごとに分割されたDLLが作成される
Windows上で開発する時はMinGW + NTEmacs/eclipse CDTの環境がおすすめ
- 668 名前：デフォルトの名無しさん mailto:sage [2014/08/27(水) 09:58:52.27 ID:J2peHUgZ.net]
- >>667
最後の段落：多分、wxWidgets 本体を MInGW32 用のビルドする際は、
configure は使えない気がする。
CodeBlocks のQuickなんたらRefの説明では、いきなり、
make するように支持されていた。しかも、-fno なんたら dll-export
みたいなオプションを付けろと指示。これは、MinGW32のバグで、
付けないと最後のldの段階でldがクラッシュする事をたまたま発見。
ところで話は変わって聞いておきたいのですが、 eclipse では
wxWidget のイベントを書くようなときに
・BEGIN_EVENT_MAP に自動的に一行マクロを挿入してくれて
・*.h にもメンバ関数宣言を書いてくれて
・*.cpp にも5行くらいの関数定義本体の雛形を書いてくれ
たりしますか？
- 669 名前：デフォルトの名無しさん mailto:sage [2014/08/27(水) 10:01:06.29 ID:J2peHUgZ.net]
- つまり、イベント・ハンドラを追加したとき、
BEGIN_EVENT_TABLE(wxListMainWindow,wxScrolledWindow)
EVT_PAINT (wxListMainWindow::OnPaint)
EVT_MOUSE_EVENTS (wxListMainWindow::OnMouse)
EVT_CHAR (wxListMainWindow::OnChar)
EVT_KEY_DOWN (wxListMainWindow::OnKeyDown)
EVT_KEY_UP (wxListMainWindow::OnKeyUp)
EVT_SET_FOCUS (wxListMainWindow::OnSetFocus)
EVT_KILL_FOCUS (wxListMainWindow::OnKillFocus)
EVT_SCROLLWIN (wxListMainWindow::OnScroll)
EVT_CHILD_FOCUS (wxListMainWindow::OnChildFocus)
END_EVENT_TABLE()
とか、クラスを書くとき
IMPLEMENT_DYNAMIC_CLASS(wxListMainWindow,wxScrolledWindow)
見たいなものの自動生成があるとうれしいんですが、そういう IDE
はありません？
- 670 名前：デフォルトの名無しさん mailto:sage [2014/08/29(金) 11:13:03.59 ID:AEJEOYpd.net]
- wxWidgetsの問題点の1つは、プログラムのサイズが大きくなる事。
特に静的リンクしたときに顕著。
Windows は、VC++ にて、
ac1rd: CUI の Win32 と printf() を使ったもののリリース・動的リンク版が 16KB程度。
puts() を使えばもっと小さく出来る。
ac1rs: CUI の Win32 と printf() を使ったもののリリース・静的リンク版が 40KB程度。
puts() を使えばもっと小さく出来る。
ag2rd: GUI の MFC の 基本的な MDI アプリがリリース・動的リンク版で 36 KB 程度。
ag2rs: GUI の MFC の 基本的な MDI アプリがリリース・静的リンク版で 332 KB 程度。
wxWidgets 2.8.12 の samples では、
bc1rd: CUI の console.exe がリリース・動的リンク版で 138KB
bc1rs: CUI の console.exe がリリース・静的リンク版で 863KB
bc1dd: CUI の console.exe がデバッグ・動的リンク版で 184KB
bg2rd: GUI の keyboard.exe がリリース・動的リンク版で 293KB
bg2rs: GUI の keyboard.exe がリリース・静的リンク版で 2,924KB
bg2dd: GUI の keyboard.exe がデバッグ・動的リンク版で 492KB
ただし、bc1xx は、アプリ本体のプログラムが複雑なことをしているようなので、
もっと小さく出来る可能性があり。
- 671 名前：デフォルトの名無しさん mailto:sage [2014/08/29(金) 19:04:31.75 ID:GS9LyL7J.net]
- その説明にac1だの何だの自分以外分からない定義を使う必要があったのだろうか
- 672 名前：デフォルトの名無しさん mailto:sage [2014/08/29(金) 19:07:59.00 ID:AEJEOYpd.net]
- 今から見るとそうかも。
a: Windows Native or MFC
b: wzWidgets
c: CUI
g: GUI
r:release, d:debug
d:dynamic link, s:static link
- 673 名前：デフォルトの名無しさん mailto:sage [2014/08/30(土) 00:17:55.46 ID:S/CtHe8u.net]
- >>668
>最後の段落：多分、wxWidgets 本体を MInGW32 用のビルドする際は、
>configure は使えない気がする。
なにいってんだCodeBlocksのドキュメントにそう書いてあるだけで
基本autotoolsで作られたソースはconfigureでビルドできるぞ
実際自分はWindows上のmingw32/64、LinuxのクロスビルドからのMinGWでconfigure使ってる
なぜMakefileでやれという指示なのかというと、そのほうが簡潔で保守しやすいからだ
あとGNU MakeじゃないMakeでもビルドできるようにしたいとかいう微妙なこだわりが有る場合も有る
>>669
エディタの補助機能を使うべきだ、Emacsなら矩形範囲選択で一気に書ける
ソースのひな形自動生成機能は知らんなあ
- 674 名前：デフォルトの名無しさん mailto:sage [2014/08/30(土) 00:21:29.81 ID:S/CtHe8u.net]
- >>670
MinGWビルドでバイナリをストリップしたやつとか比較しないのか
- 675 名前：デフォルトの名無しさん mailto:sage [2014/08/30(土) 07:56:49.02 ID:pUv0T+7B.net]
- >>674
Stripに詳しくないので、言っている意味が分からない。
Stripって Release 用に Build した Binary に対して行っても
サイズダウンできたりするの？
- 676 名前：デフォルトの名無しさん mailto:sage [2014/08/30(土) 07:58:19.03 ID:pUv0T+7B.net]
- >>674
Stripに詳しくないので、言っている意味が分からない。
Stripって Release 用に Build した Binary に対して行っても
サイズダウンできたりするの？
- 677 名前：デフォルトの名無しさん mailto:sage [2014/08/30(土) 08:15:51.54 ID:hpIa4Qjb.net]
- 日本語インライン入力の対応ってまだなの？
というか予定自体なくて諦めた方がいい？
wxWidgets使ってるEditraってエディタにそろそろ移行できるかなと
思って試してみたら、未だにインライン入力できない
- 678 名前：デフォルトの名無しさん mailto:sage [2014/08/30(土) 08:19:53.34 ID:pUv0T+7B.net]
- >>674
小さくなりますた!!
Relese, 動的リンク
/wxWidgets-2.8.12/samples/keyboard/gcc_mswdll/keyboard.exe
strip 前：299,808 bytes
strip 後：124,430 bytes
Relese, 静的リンク
/wxWidgets-2.8.12/samples/keyboard/gcc_msw/keyboard.exe
strip 前：2,993,255 bytes
strip 後：1,887,758 bytes
strip 後も、*.exe が正常に起動することを確認済み。
- 679 名前：デフォルトの名無しさん mailto:sage [2014/08/30(土) 08:22:26.84 ID:pUv0T+7B.net]
- >>673
>エディタの補助機能を使うべきだ、Emacsなら矩形範囲選択で一気に書ける
詳しく：
- 680 名前：デフォルトの名無しさん [2014/08/30(土) 11:51:11.86 ID:RJxcDZkh.net]
- 馬鹿には無理
- 681 名前：デフォルトの名無しさん mailto:sage [2014/08/30(土) 12:02:34.82 ID:S/CtHe8u.net]
- スタンド・アローン・コンプレックスと化した馬鹿には無理さんオッスオッス
>>679
cua-modeでググって
qiita.com/yyamamot/items/7efcbfdcccdb5fa45ebe
例えばイベントテーブルとかはこれでザクッと一気に書ける
もちろん個々のwxWindowIDとメソッド定義は書かなくてはいけないが
クラス名とマクロ定義は同じ文字列の繰り返しなのでだいぶ楽になる
- 682 名前：デフォルトの名無しさん mailto:sage [2014/08/30(土) 13:53:01.64 ID:pUv0T+7B.net]
- >>681
あー、そういう風に沢山のイベントを一気に書きたいんじゃなくて、
開発段階で徐々にイベントを追加して行く際に、
1. *.h のクラス内にメンバ関数宣言
2. *.cpp に EVENT MAP
3. *.cpp に メンバ関数定義の本体
の三箇所にコードを書くのが面倒ということなんだわ。
- 683 名前：デフォルトの名無しさん mailto:sage [2014/08/30(土) 14:33:49.98 ID:S/CtHe8u.net]
- >>682
それは自分で作らないと無さげですねえ
- 684 名前：デフォルトの名無しさん mailto:sage [2014/08/30(土) 19:11:57.66 ID:5dlfaubU.net]
- wxFormBuilderでしかGUIとイベントを設計できない俺には何言ってるのかさっぱりわからんぜよ……
- 685 名前：678 mailto:sage [2014/08/31(日) 15:54:21.95 ID:X+I89xFV.net]
- wxAUI のデモ・アプリ wxauitest.exe のサイズは、1,417,216 bytes。
スタンドアロンのアプリで、環境変数からパスを完全に消去しても起動
できた。つまり、ライブラリはDLLを使わずに静的リンクされている。
wxAUIはFloating & Dockingのできる強力なGUI。
>>678 に示した keyboard.exe はキーボードから押されたキーの値を
表示するだけで、上記アプリよりずっとシンプルなのにも関わらず、
1,887,758 bytes と 470,542 bytes も大きい。
理由は不明。
- 686 名前：デフォルトの名無しさん mailto:sage [2014/08/31(日) 15:56:18.96 ID:5rh0udnx.net]
- そんなことしなくても
DLLの依存関係調べるツールあるのに
- 687 名前：デフォルトの名無しさん mailto:sage [2014/08/31(日) 16:01:12.95 ID:5rh0udnx.net]
- ちなみにwxWidgetsで作った一番小さいexe探したら65kbのがあった
- 688 名前：678 mailto:sage [2014/08/31(日) 17:34:23.46 ID:X+I89xFV.net]
- Windows実行形式であっても、コンパイラが、MinGW32 と VC++ でサイズに
大幅な違いが出てくるのかな？
- 689 名前：678 mailto:sage [2014/08/31(日) 17:41:03.82 ID:X+I89xFV.net]
- >>687
それは DLL 版だよ。絶対に。
- 690 名前：デフォルトの名無しさん mailto:sage [2014/08/31(日) 19:56:13.33 ID:F1QgxQvq.net]
- >>685
実行ファイルの関数テーブルに何が入っているか nm で確認したら少しはわかるかもね
>>688
大幅とは行かないかもしれないがVC++はWindowsのみをターゲットにしているから
基本的にコンパイル後のバイナリサイズは MinGW ＞ VC++ だよね
- 691 名前：デフォルトの名無しさん mailto:sage [2014/08/31(日) 20:18:05.13 ID:da+aRwUf.net]
- CodeBlocks + MinGW32 で、
wxWidgets の Monolithic、ASCIIライブラリ, 静的リンク で
最も簡単な Frame Based な GUI を作成してみたら、
2,073,600 バイトよりは小さくならなかった。
wxWidgets のライブラリは、
-Os
-ffunction-sections
-fdata-sections
でコンパイルし、
-Wl,--gc-sections -s
でライブラリ化した。その時のコマンド：
mingw32-make -j2 -f makefile.gcc CPPFLAGS="-MD -MP -DHAVE_W32API_H
-D__WXMSW__ -DNOPCH -DwxDEBUG_LEVEL=0 -DNDEBUG" CFLAGS="-mthreads
-fmessage-length=0 -ffunction-sections -fdata-sections -fno-builtin
-Os" CXXFLAGS="-mthreads -Wno-ctor-dtor-privacy -fmessage-length=0
-ffunction-sections -fdata-sections -fno-builtin -Os
-fno-keep-inline-dllexport" LDFLAGS="-Wl,--subsystem,windows
-Wl,--gc-sections -s -mthreads -mwindows"
BUILD=release UNICODE=0 SHARED=0 MONOLITHIC=1
CodeBlocks でアプリのリンクのオプションにも、
-Wl,--gc-sections -s
は付けてある。
- 692 名前：デフォルトの名無しさん mailto:sage [2014/08/31(日) 20:27:38.74 ID:da+aRwUf.net]
- ちなみに、Unicode 版より ASCII 版のほうが小さくなることを確認済みである。
[Compiler settings - #defines]
が、標準では、
__GNUWIN32__, __WXMSW__, WXUSINGDLL, wxUSE_UNICODE, WX_PRECOMP
となるところを：
__GNUWIN32__, __WXMSW__
だけとし、
[Search Directories] の Compiler, Linker, Compiler
の、gcc_dll の部分を、gcc_lib に変えた。
アプリにリンクするリンクライブラリとしては、上記で作成した Monolithic
ライブラリだけでは足りず、以下が必要であった。Win32のimport libraryは、
ライブラリを動的リンクする場合はライブラリのDLLが行っているので必要ない
が、ライブラリを静的リンクする場合は、アプリが直接リンクする必要がある
ため必要となるのは理解できる。libwxpng, libwxjpeg, libwxtiff, libwxzlib
が必要となった理由は不明。
libwxmsw28 // これが wxWidgets の monolithic ライブラリ本体。
libwxpng
libwxjpeg
libwxtiff
libwxzlib
libuuid // Win32 の import library
libcomctrl32 // Win32 の import library
libwinspool // Win32 の import library
liboleaut32 // Win32 の import library
libole32 // Win32 の import library
ちなみに、wxWidgets を動的リンクする場合は、ここが、libwxmsw28
だけで済む。
- 693 名前：デフォルトの名無しさん mailto:sage [2014/08/31(日) 20:33:24.61 ID:da+aRwUf.net]
- 誤：[Search Directories] の Compiler, Linker, Compiler
正：[Search Directories] の Compiler, Linker, Resource Compiler
誤：Win32のimport libraryは、ライブラリを動的リンクする場合はライブ
ラリのDLLが行っているの
正：wxWidgets ライブラリをアプリに動的リンクする場合は
wxWidgets ライブラリの DLL 部分が Win32 の import library の
リンクを行っているの
- 694 名前：デフォルトの名無しさん [2014/08/31(日) 20:45:44.37 ID:0aT2mco7.net]
- サイズはどうでもよくないか。exeを使う側としては速度では?
あとコア、主要のライブラリのビルドから、ダイナミックリンクを徹底してOSに丸投げしたら小さくなるだろ。
- 695 名前：デフォルトの名無しさん mailto:sage [2014/08/31(日) 20:48:05.22 ID:ks+4W1rG.net]
- 完全テンプレートライブラリにしたら軽くなるんだろうか
- 696 名前：デフォルトの名無しさん mailto:sage [2014/08/31(日) 20:58:57.78 ID:da+aRwUf.net]
- >>694
でも wxWidgets がやっていることの割にはリンクされるバイト数が多すぎる
感じがする。
基本、Win32をラッピングしているだけなのだから、2MBも必要ない。
- 697 名前：デフォルトの名無しさん mailto:sage [2014/08/31(日) 21:00:34.83 ID:ks+4W1rG.net]
- ラッピングしてるだけじゃなくマルチプラットフォームのために徹底した抽象化をしてるんでしょ
とソースも読まず推測
- 698 名前：デフォルトの名無しさん mailto:sage [2014/08/31(日) 21:04:00.35 ID:da+aRwUf.net]
- >>697
でもソースを呼んでみたら、たとえば、wxListCtrl なんかは、
Win32 の LIST CONTROL をそのまま使っていた。
DrawRect()などで書いているわけではない。
ただし、wxGenericListCtrl だったかは、DrawRect()みたいなグラフィック
関数で独自に描画していた。が、それは、Windows版では簡単には使えない
という噂を聞いたが。
- 699 名前：デフォルトの名無しさん mailto:sage [2014/08/31(日) 21:06:47.60 ID:da+aRwUf.net]
- >>697
wxWidgets の基本設計は、Widgetは、OS nativeの物を使うが、
どんなサイズであっても対応できるように Sizer で Layout を
コントロールする、という物。
なので、抽象化はサイズと配置程度で済むはずなのだが・・・。
- 700 名前：デフォルトの名無しさん mailto:sage [2014/08/31(日) 21:09:35.31 ID:F1QgxQvq.net]
- >>696
>>697の言ってることが正しい。
---------------------
wxWidgets
---------------------
Win32 | GTK | Cocoa etc...
---------------------
wxWidgetsは通常のGUI用ライブラリに一枚レイヤを重ねた形になるので
型情報・関数テーブルの情報だけで結構容量食う
>>692
ASCIIモードでビルドするのはやめておいたほうがいい
日本語使えないし
というかなぜMonolithicビルドにこだわるのか…
普通にconfigureからビルドしてdllごと配布したほうが立ち上がりは早い
- 701 名前：デフォルトの名無しさん mailto:sage [2014/08/31(日) 23:57:56.42 ID:da+aRwUf.net]
- wxWidgets の samples で ListCtrl 関連を見てみたが、ヘッダを
ドラッグしようとしてもドラッグできないので、ドラッグによる列の入れ替
えは出来ないようだった。
実は、Win32 の LIST CONTROL は、
・マウスドラッグによる自動的な列の入れ替えをした際、どこにどの列が
行ったかを掌握するには注意が必要。動作を知るには基本的に実験を必要
とする。
・第1カラムを削除すると第2カラム以降を削除した時とは同じとは言えない
奇妙な動作をする。奇妙な動作と言ったがバグに近い。
こういった辺りがどう処理されているか知りたかったのだが、サンプルでは
故意か偶然か、全くそこに触れていないようだった。
- 702 名前：デフォルトの名無しさん mailto:sage [2014/08/31(日) 23:59:28.64 ID:da+aRwUf.net]
- wxWidgets の samples で ListCtrl 関連を見てみたが、ヘッダを
ドラッグしようとしてもドラッグできないので、ドラッグによる列の入れ替
えは出来ないようだった。
実は、Win32 の LIST CONTROL は、
・マウスドラッグによる自動的な列の入れ替えをした際、どこにどの列が
行ったかを掌握するには注意が必要。動作を知るには基本的に実験を必要
とする。
・第1カラムを削除すると第2カラム以降を削除した時とは同じとは言えない
奇妙な動作をする。奇妙な動作と言ったがバグに近い。
こういった辺りがどう処理されているか知りたかったのだが、サンプルでは
故意か偶然か、全くそこに触れていないようだった。
- 703 名前：デフォルトの名無しさん mailto:sage [2014/09/01(月) 00:00:47.70 ID:X69OanmZ.net]
- >>700
>wxWidgetsは通常のGUI用ライブラリに一枚レイヤを重ねた形になるので
>型情報・関数テーブルの情報だけで結構容量食う
オイラはコンパイラの基本部分に詳しいが、それだけで1MBなどには
ならない。
- 704 名前：デフォルトの名無しさん mailto:sage [2014/09/01(月) 00:06:51.19 ID:X69OanmZ.net]
- >>694
諦めることも手かも知れないけど、やっている事の規模とサイズとの
ギャップに納得がいかない人もいるはず。
wxWidgetsはラッピング・ライブラリの一種。
8bit時代、16bit時代を知る人にとって、Widget 程度が64KBを超える
事があってはならない。どういうプログラミングをしたら2MBにもなる
のか。
- 705 名前：デフォルトの名無しさん [2014/09/01(月) 01:16:10.03 ID:7Pg7L2PA.net]
- >>703
>>704
一理あるのでちょっとメーリングリストを探ってみたり
まず、wx/wx.hがいろいろなヘッダファイルを事前にincludeしているので
それがバイナリサイズの増加の一因になっているらしい
[wxMSW]: why EXE-files are so large?
https://groups.google.com/d/msg/wx-users/psTmm3nB6AU/9j6-4ir95-gJ
- 706 名前：デフォルトの名無しさん mailto:sage [2014/09/01(月) 07:25:22.06 ID:X69OanmZ.net]
- >>591 のライブラリを samples/keyboard にも使ってみたら、
keyboard.exe のサイズを 1,619,968 にまで縮小することに成功した。
コンパイラは MinGW32 のまま。
条件は：release, 非UNICODE(ASCII), SHARED=0(静的リンク), MONOLITHIC = 1
どうやら MONOLITHIC であるかどうかは最終 exe サイズには関係してないらしい。
ライブラリと言うのは集めてもばらしても、最終 exe のリンク結果には影響を
及ぼさない事が基本なので、元々当たり前なことなのだが。
[samples/keyboard]
$ mingw32-make -f makefile.gcc BUILD=release UNICODE=0 SHARED=0 MONOLITHIC=1
[samples/keyboard/makefile.gcc の修整]
-------------------------------------------------------------------------------------
$(OBJS)\keyboard.exe: $(KEYBOARD_OBJECTS) $(OBJS)\keyboard_keyboard_rc.o
$(CXX) -o $@ $(KEYBOARD_OBJECTS) $(__DEBUGINFO) $(__THREADSFLAG)
-L$(LIBDIRNAME) -Wl,--subsystem,windows -Wl,--gc-sections -Wl,-s -mwindows
$(____CAIRO_LIBDIR_FILENAMES_p) $(LDFLAGS) $(__WXLIB_CORE_p) $(__WXLIB_BASE_p)
$(__WXLIB_MONO_p) $(__LIB_TIFF_p) $(__LIB_JPEG_p) $(__LIB_PNG_p)
-lwxzlib$(WXDEBUGFLAG) -lwxregex$(WXUNICODEFLAG)$(WXDEBUGFLAG) -lwxexpat$(WXDEBUGFLAG)
$(EXTRALIBS_FOR_BASE) $(__UNICOWS_LIB_p) $(__GDIPLUS_LIB_p) $(__CAIRO_LIB_p)
-lkernel32 -luser32 -lgdi32 -lcomdlg32 -lwinspool -lwinmm -lshell32 -lcomctl32 -lole32
-loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32 -lodbc32
--------------------------------------------------------------------------------------
上記は original の makefile.gcc に、
-Wl,--gc-sections -Wl,-s
を追加しただけ。
- 707 名前：デフォルトの名無しさん mailto:sage [2014/09/01(月) 07:31:05.33 ID:X69OanmZ.net]
- 誤：>>591
正：>>691
- 708 名前： 【大吉】 mailto:sage [2014/09/01(月) 07:40:36.83 ID:zQucGkuf.net]
- wxWidgets の samples で ListCtrl 関連を見てみたが、ヘッダを
ドラッグしようとしてもドラッグできないので、ドラッグによる列の入れ替
えは出来ないようだった。
実は、Win32 の LIST CONTROL は、
・マウスドラッグによる自動的な列の入れ替えをした際、どこにどの列が
行ったかを掌握するには注意が必要。動作を知るには基本的に実験を必要
とする。
・第1カラムを削除すると第2カラム以降を削除した時とは同じとは言えない
奇妙な動作をする。奇妙な動作と言ったがバグに近い。
こういった辺りがどう処理されているか知りたかったのだが、サンプルでは
故意か偶然か、全くそこに触れていないようだった。
- 709 名前：デフォルトの名無しさん mailto:sage [2014/09/01(月) 07:45:41.49 ID:X69OanmZ.net]
- >>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
C:/WINDOWS/system32/comctl32.dll # 617,472 bytes
のように、windows/system32 の comctrl32.dll を動的リンクするための
呼び出し部分だけを提供する小さなライブラリ。
- 710 名前：デフォルトの名無しさん mailto:sage [2014/09/01(月) 08:18:53.15 ID:1emh7fCQ.net]
- map出力して何がリンクされてるか見れば？
- 711 名前：デフォルトの名無しさん mailto:sage [2014/09/01(月) 14:09:14.38 ID:X69OanmZ.net]
- 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 \
$(____CAIRO_INCLUDEDIR_FILENAMES) -W -Wall -DWXBUILDING -I..\..\src\tiff \
-I..\..\src\jpeg -I..\..\src\png -I..\..\src\zlib -I..\..\src\regex \
-I..\..\src\expat\lib -DwxUSE_BASE=0 $(__RTTIFLAG) $(__EXCEPTIONSFLAG) \
-Wno-ctor-dtor-privacy $(CPPFLAGS) $(CXXFLAGS)
MONOLIB_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 \
$(____CAIRO_INCLUDEDIR_FILENAMES) -W -Wall -DWXBUILDING -I..\..\src\tiff \
-I..\..\src\jpeg -I..\..\src\png -I..\..\src\zlib -I..\..\src\regex \
-I..\..\src\expat\lib -DwxUSE_BASE=1 $(__RTTIFLAG) $(__EXCEPTIONSFLAG) \
-Wno-ctor-dtor-privacy $(CPPFLAGS) $(CXXFLAGS)
- 712 名前：デフォルトの名無しさん mailto:sage [2014/09/01(月) 14:13:21.84 ID:X69OanmZ.net]
- 違いは、-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の時に作られる。
ifeq ($(USE_GUI),1)
$(OBJS)\corelib_dc.o: ../../src/msw/dc.cpp
$(CXX) -c -o $@ $(CORELIB_CXXFLAGS) $(CPPDEPS) $<
endif
ifeq ($(USE_GUI),1)
$(OBJS)\monolib_dc.o: ../../src/msw/dc.cpp
$(CXX) -c -o $@ $(MONOLIB_CXXFLAGS) $(CPPDEPS) $<
endif
ソースを見ると、wxUSE_BASE の値に応じて場合分けされている箇所が多数ある。
つまり、MONOLITHIC の 0 と 1 の違いは単に *.o ファイルの集め方の問題では無い。
コンパイル時点のソース自体が変更されるのである。故にリンク後の*.exe のサイズ
が変わって来ても不思議は無い。これは驚くべきことである。
- 713 名前：デフォルトの名無しさん mailto:sage [2014/09/01(月) 15:21:49.13 ID:M8Jh9ISi.net]
- 別に驚くほどのことじゃ無いけど
- 714 名前：デフォルトの名無しさん mailto:sage [2014/09/01(月) 16:14:53.94 ID:X69OanmZ.net]
- >>713
コンパイルオプションまで変えてしまって何をやっているかと言うこと
なんだよ。ライブラリの集め方だけの問題じゃないって事なんだ。
ライブラリの動作が変わってしまい、MONOLITHIC が 0 と 1とで結果が違うことに
悩まされる可能性もある。
単にライブラリのオブジェクトの集め方（含み方）の問題では無いとすると、MONOLITHIC
オプションの意味はいったい何かと言う問題になる。
また、最終EXEが大きくなる理由として、アプリが使ってないオブジェクトを
非常に基本的なライブラリの一部が参照している可能性がある。
そしてそのオブジェクトが別のオブジェクトを勝手に参照して・・・という
事が続いて最終EXEのサイズが肥大化してしまっているのかも知れない。
- 715 名前：デフォルトの名無しさん mailto:sage [2014/09/01(月) 16:33:12.36 ID:X69OanmZ.net]
- wiki.wxwidgets.org/WxWidgets_Build_Configurations
「MONOLITHIC=1 :
Packages all libraries in a single file.
(Note: do not combine this option with a static build.)」
とあった。static build の時は、MONOLITHIC=1 にするな、と
書かれている・・・。
- 716 名前：デフォルトの名無しさん mailto:sage [2014/09/01(月) 16:49:54.89 ID:zU7EZBBQ.net]
- いったい何を目的として何を検証しているんだ？
- 717 名前：デフォルトの名無しさん [2014/09/01(月) 17:12:16.45 ID:bPa0tOdz.net]
- このライブラリを使うなとなる。
- 718 名前：デフォルトの名無しさん mailto:sage [2014/09/01(月) 17:31:47.05 ID:X69OanmZ.net]
- >>717
そういうわけではない。
- 719 名前：デフォルトの名無しさん mailto:sage [2014/09/02(火) 13:46:25.35 ID:TmMSlGm8.net]
- 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 の引数には少なくとも
・--build=i686-pc-mingw32 --host=i686-pc-mingw32 --target=i686-pc-mingw32
を指定し、例外, rtti, regex, zlib, jpeg, png, tiff は無効にするオプション
を設定した。他にも無効にしたものも多い。大量に及ぶので スクリプトに記述した。
・Makefileが普段の /xxx/build/msw/ ではなく、/xxx/ に作られた。
・/xxx/samplesのサブディレクトリにあるMakefileが書き換えられた。
・setup.h が、
/xxx/lib/wx/include/msw-ansi-releasw-static-2.8/wx
/xxx/lib/wx/include/msw-ansi-releasw-2.8/wx
の二箇所に作成された。元々各所にあるが、例としては
/xxx/include/ws/msw や /xxx/lib/gcc_lib/msw/wx にある。
・/xxx/ で make[ret] してみた。
・途中で例外を有効にするように言われたので有効にした。
- 720 名前：デフォルトの名無しさん mailto:sage [2014/09/02(火) 13:46:50.57 ID:TmMSlGm8.net]
- ・regex, zlib, jpeg, png, tiff は全て無効にしていたにも関わらず、
src/regex, src/zlib, src/jpeg, src/tiff にしかない *.h ファイルが見つから
ないエラーとなった。。
そこで、Makfileを直接修整して、CPPFLAGS に -I 指定によって、上記ディレクトリ
を最後尾に追加した。
・make には成功した。
・/xxx/ に大量の *.o ファイルが作られ、*.a は /xxx/lib/ に作られた。
/build/msw から make した場合は、/xxx/lib/gcc_lib に作られるのと対照的
である。
・/xxx/samples/console で make してみたら、成功した。
・「プロシージャエントリポイント _gxx_persolanity_v0 が
ダイナミック リンク ライブラリ libstdc++-6.dll から見つかりませんでした。」
のメッセージボックスが出て起動できず。
・Makefileを書き換えて、LIBS の最後に -lstdc++ を書いても症状は治まらない。
- 721 名前：デフォルトの名無しさん mailto:sage [2014/09/02(火) 13:48:11.36 ID:TmMSlGm8.net]
- ・regex, zlib, jpeg, png, tiff は全て無効にしていたにも関わらず、
src/regex, src/zlib, src/jpeg, src/tiff にしかない *.h ファイルが見つから
ないエラーとなった。。
そこで、Makfileを直接修整して、CPPFLAGS に -I 指定によって、上記ディレクトリ
を最後尾に追加した。
・make には成功した。
・/xxx/ に大量の *.o ファイルが作られ、*.a は /xxx/lib/ に作られた。
/build/msw から make した場合は、/xxx/lib/gcc_lib に作られるのと対照的
である。
・/xxx/samples/console で make してみたら、成功した。
・「プロシージャエントリポイント _gxx_persolanity_v0 が
ダイナミック リンク ライブラリ libstdc++-6.dll から見つかりませんでした。」
のメッセージボックスが出て起動できず。
・Makefileを書き換えて、LIBS の最後に -lstdc++ を書いても症状は治まらない。
- 722 名前：デフォルトの名無しさん mailto:sage [2014/09/02(火) 16:41:02.66 ID:TmMSlGm8.net]
- console.cpp の中身を printf() だけを使う4行の main() 関数だけに
書き換えてみたら問題なく起動して普通に文字列が表示された。
なので、MinGW 環境の問題ではなさそう。
- 723 名前：デフォルトの名無しさん mailto:sage [2014/09/02(火) 17:12:10.67 ID:TmMSlGm8.net]
- wxPrintf()だけを使った console 版 hello world が、static link
で 96,468 bytes で済んだ。
ところが、wxString を使った場合、作成した exe を実行しようとすると
>>721 後半で書いたメッセージ・ボックスが出て起動できない。
- 724 名前：デフォルトの名無しさん mailto:sage [2014/09/02(火) 17:17:49.98 ID:DoCZo715.net]
- libstdc++がダイナミックリンクになってるだけだろ。
- 725 名前：デフォルトの名無しさん mailto:sage [2014/09/02(火) 17:44:29.48 ID:TmMSlGm8.net]
- >>724
ダイナミックライブラリであるところの
libstdc++-6.dll
は既に読み込めているんですわ。
「libstdc++-6.dll から見つかりませんでした。」
の「から」がそれを表している。
なお、configureを使わずに、build/msw から build したライブラリだと
wxStringとwxPrintfだけを使ったconsoleアプリは、静的リンクでも
451,584 バイトで済むことが判明。こちらはちゃんと起動できる。
- 726 名前：デフォルトの名無しさん mailto:sage [2014/09/02(火) 19:04:52.66 ID:DoCZo715.net]
- パスが通ったところに互換性のない別バージョンのdllがあるんだろ。
mingwだとsjljとdw2の２種類あるから。
- 727 名前：デフォルトの名無しさん mailto:sage [2014/09/02(火) 19:56:42.14 ID:TmMSlGm8.net]
- MinGW/bin を
i686-pc-mingw32-g++ と MinGW/bin/g++ は別物らしくコンパイラのサイズ
（作ったプログラムのサイズではなく変換機のサイズ）がそもそも違う。
また、前者では、リンク段階で何もエラーを出さないが、
後者では、ちゃんと、_gxx_persolanity_v0 や _Unwind_Resume が
undefined reference というエラーになる。
- 728 名前：デフォルトの名無しさん mailto:sage [2014/09/02(火) 20:00:33.47 ID:TmMSlGm8.net]
- >>726
最初、xxx dw2 yyy.dll が見つからない、と言うメッセージ・ボックス
が出たのだが、そのdllを検索すると MinGW/bin にある事が分かって、
そこにパスを通したらそのメッセージ・ボックスは出なくなった。
その代わりに >>721 のメッセージ・ボックスが出るようになった。
- 729 名前：デフォルトの名無しさん mailto:sage [2014/09/02(火) 20:55:48.58 ID:TmMSlGm8.net]
- 結論的に言うと、自分のローカルにMinGW32 の別バージョンが沢山あった。
サンプルのコンパイルに使われたのと同じMinGW32のbinだけをパスに
設定してからサンプルを起動すると実行できるようになった。
実行結果も問題ない。実行ファイルはstripするとサイズが小さくなったが、
>>691のライブラリをリンクした物よりも大きくなってしまった。
[wxStringを使った最小な cui program のサイズ]
・>>691 のwxライブラリ使用時 : 451,584 bytes
コンパイラは CodeBlocks付属のMinGW
・configureしたwxライブラリ使用時 : 547,342 bytes
コンパイラは cygwinにインストールしたMinGW
[wxFrameを使った最小な gui program のサイズ]
・>>691 のwxライブラリ使用時 : 1,611,264 bytes
コンパイラは CodeBlocks付属のMinGW
なお、今回は、>>719-720 のような不具合を回避するため、RegExや、png,jpeg,tiff,zlib
などはconfigureで有効にしておいた。そうすると>>720の最初のヘッダファイル問題は
消えたので、何か良いことがあるかと思ったから。ただし、様子を見るとそれは必要なかった
かも知れない。サイズ縮小のためには disable にすべきかも。
- 730 名前：デフォルトの名無しさん mailto:sage [2014/09/02(火) 21:12:01.59 ID:WV3CuJcS.net]
- よかったな
-Wl,-Bstatic -lstdc++ -Wl,-Bdynamic
にすればlibstdc++とスタティックリンクできるかもな
- 731 名前：デフォルトの名無しさん mailto:sage [2014/09/02(火) 22:46:11.97 ID:TmMSlGm8.net]
- 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" のパスが探せなかったり
する。
build, host, target の指定は、全て mingw を指定していたのだから、
cygwinが入り込む余地は無かったはず。これは、configure.inか、
Makefileのどちらかを自前で修整する必要がありそう。
さらに、makeが(？)
process_begin: CreateProcess(NULL, sh xxxxxx, ...) failed.
というエラーを出すことがあり、その原因を探る必要もある。
- 732 名前：デフォルトの名無しさん mailto:sage [2014/09/02(火) 22:56:33.59 ID:RsSqk3ed.net]
- もう完璧にスレ違いだな
- 733 名前：デフォルトの名無しさん mailto:sage [2014/09/02(火) 22:56:38.09 ID:TmMSlGm8.net]
- 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" のパスが探せなかったり
する。
build, host, target の指定は、全て mingw を指定していたのだから、
cygwinが入り込む余地は無かったはず。これは、configure.inか、
Makefileのどちらかを自前で修整する必要がありそう。
Makfileの / を \ で置換して、/cygdrive/x/ を x:/ にしてみたら結構
行ける。途中、pch でファイルにアクセス拒否で書き込めないと言われるが、
もう一度 make すると、何事も無かったように続行する。
- 734 名前：デフォルトの名無しさん mailto:sage [2014/09/02(火) 22:57:58.06 ID:TmMSlGm8.net]
- >>732
wx アプリのサイズダウンの仕方関連なんだけど。
- 735 名前：デフォルトの名無しさん mailto:sage [2014/09/02(火) 23:40:17.26 ID:wgXgojMH.net]
- 作ったバイナリのサイズなんてwxWidgetsのビルド方法によって大きく変わるうえ、
最終的に使い物にならないライブラリの出来上がりとなるのが目に見えている
本当に必要なものだけを炙り出すつもりなら止めはしないが、どう考えても徒労でしかないと思うぞ
- 736 名前：デフォルトの名無しさん [2014/09/02(火) 23:47:28.37 ID:r9jqoPj2.net]
- 正直wxWidgetsのバイナリサイズの話以外はほとんど既出だし
CygwinとMinGWの仕様の違い、クロスコンパイラのターゲット、configureの基本
それらの件に関しては自分のブログにでも書いていてほしい
- 737 名前：デフォルトの名無しさん [2014/09/02(火) 23:54:47.98 ID:r9jqoPj2.net]
- まあ一応上から目線でコメントしとくと
>>725
libgccの存在に関して勉強不足、>>726の言うとおりdllの種別が２種類ある
DLLにするよりもlibgccだけスタティックリンクしたほうがいいが、libtoolにかませるのが
割と面倒なので一緒に配布したほうが楽、まぜこぜにするとか初心者くさい
>>727
クロスコンパイラとネイティブコンパイラを混同している
>>731
もうネット上で一万回は言及されたであろうCygwinとMinGWのファイルパスについて
述べているが無駄なのでやめてほしい、てか環境を混ぜるな
- 738 名前：デフォルトの名無しさん mailto:sage [2014/09/03(水) 00:12:32.54 ID:RSu3l9Ti.net]
- >>737
最後の段落について。
・cygwin版のMinGW ---> ファイル名はUnixライクな /cygdrive/c/xxx/yyy/zzz 形式だが、
出来た実行ファイルはcygwinが無くても動作する。
ユーザー・プログラムからは主にWin32 APIを使う。
・cmd.exe版のMinGW ---> 何もかも Windows 用。ファイル名もDOS式、
出来た実行ファイルは Windows のみで動作。
ユーザー・プログラムからは Win32 API を使う。
・cygwinのgcc ---> cygwin環境で動く実行ファイルを作成する。
ユーザー・プログラムからはUnix系関数を使う。
- 739 名前：デフォルトの名無しさん [2014/09/03(水) 00:20:01.40 ID:qMd+w6/O.net]
- >>738
スレ違いだ、こっちでやれ
Cygwin + MinGW + GCC 相談室 Part 7
peace.2ch.net/test/read.cgi/tech/1357019230/
あとMinGWはcmd.exeではなくminttyから使うべきだ
さっさとネットで資料を探す作業に戻るんだな
- 740 名前：デフォルトの名無しさん mailto:sage [2014/09/03(水) 00:37:00.57 ID:kYvXCnau.net]
- ちなみに c:\cygwin\bin と c:\cygwin\usr\local\bin にパスを通せば、
cmd.exe からでも cygwin のコマンドが実行できるようになる。
gccもlsもmakeも。ここでbashを起動すればcygwin環境になる。
- 741 名前：デフォルトの名無しさん mailto:sage [2014/09/03(水) 08:47:34.91 ID:VnTCGwbS.net]
- 久しぶりに２ちゃん観に来たら
wxのスレめっちゃ野比てて嬉しい
- 742 名前：デフォルトの名無しさん mailto:sage [2014/09/03(水) 14:50:56.74 ID:kYvXCnau.net]
- wx のソースを修正したら、wxString() を使った最小サンプルが、
静的リンクしても 70KB で済むようになった。
PATHには、MInGW/bin しか設定せずにテストしているので、wx の DLL
がリンクされている可能性は無く、間違いなくスタンド・アローンの
プログラム。
ちなみに、wx のソースを修正しなければ、451,584 バイトになってしまう。
>>729 に書いたものとほぼ同じプログラムだから。
- 743 名前：デフォルトの名無しさん mailto:sage [2014/09/03(水) 15:05:09.35 ID:SXoWEkGr.net]
- wxというよりgccとライブラリのお話で伸びている
- 744 名前：デフォルトの名無しさん mailto:sage [2014/09/03(水) 16:58:33.04 ID:3zk9T5qQ.net]
- >>742
dllの依存関係すらまともに調べられないのか
dependency walkerとかobjdumpとか使え
- 745 名前：デフォルトの名無しさん mailto:sage [2014/09/03(水) 17:02:39.87 ID:SXoWEkGr.net]
- mingw入ってるならlddコマンドでもいける＞依存動的ライブラリ
- 746 名前：デフォルトの名無しさん mailto:sage [2014/09/03(水) 18:30:34.52 ID:kYvXCnau.net]
- ただ、パス設定を空にして起動できるかどうか見るのも1つの確実な方法。
- 747 名前：デフォルトの名無しさん mailto:sage [2014/09/04(木) 03:37:02.91 ID:FQO1vG1R.net]
- 性格悪いな。
コンピュータ・ソフト関連の人って。
- 748 名前：デフォルトの名無しさん mailto:sage [2014/09/04(木) 17:23:39.03 ID:FQO1vG1R.net]
- GUIアプリのサイズ縮小を試みていたが、断念するかも知れない。
- 749 名前：デフォルトの名無しさん mailto:sage [2014/09/04(木) 18:46:24.22 ID:Sd68Xi30.net]
- △性格が悪い
○無駄が嫌い
◎無駄な事をしてる奴が嫌い
- 750 名前：デフォルトの名無しさん mailto:sage [2014/09/05(金) 15:14:57.29 ID:PbioWCRT.net]
- >>749
何も悪いことをせず、自分にも害を与えない人を嫌うのが性格が悪いんだよ。
- 751 名前：デフォルトの名無しさん mailto:sage [2014/09/05(金) 15:46:20.79 ID:JjYqHkIR.net]
- 公園の蚊を駆除するのに外側からじゃなくて内側から始めるとかが無駄
自分にも危害が及ぶので嫌
- 752 名前：デフォルトの名無しさん mailto:sage [2014/09/05(金) 17:37:07.79 ID:MynIP2yf.net]
- >>749>>750
言われた側が一方的に立場が悪くなるという効能は興味深いと思う
言ったもん勝ちという現象は絶対にあるのだ
>>751
生死にかかわる難しい判断を
「無駄なこと」に無理やりおしこめた詭弁
物事を矮小化させる効果もある
- 753 名前：デフォルトの名無しさん mailto:sage [2014/09/05(金) 18:18:43.88 ID:NH0YjWIH.net]
- >>751
正直言って、今回のこととの関連も分からない。
それ以前に外側から、内側から、ということの意味が全く分からない。
まるで会話ロボットが生成した文書のようだ。
>>752
この文書も意味不明。人間が書いたとは思えない全く理解できない文書だ。
- 754 名前：デフォルトの名無しさん [2014/09/05(金) 22:33:12.96 ID:Mt1E1+r6.net]
- 俺の大好きなwxWidgetsスレがめちゃんこ糞スレになって泣きそう
- 755 名前：デフォルトの名無しさん mailto:sage [2014/09/05(金) 22:52:37.72 ID:rFI2iHSs.net]
- 案の定あらし化したか
これ以上触れないで放っとくの推奨
|
 |
