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

【GUI】wxWidgets(旧wxWindows) その5【サイザー】 (960ﾚｽ)
上下前次1-新
抽出解除必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞あぼーん

ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡

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にもなる
のか。

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 のリンク結果には影響を
及ぼさない事が基本なので、元々当たり前なことなのだが。

[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: 2014/09/01(月)07:31 ID:X69OanmZ(4/10)調 AAS
誤：>>591
正：>>691

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
C:/WINDOWS/system32/comctl32.dll　　　　 # 617,472 bytes

のように、windows/system32 の comctrl32.dll を動的リンクするための
呼び出し部分だけを提供する小さなライブラリ。

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 \
　　$(____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: 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の時に作られる。

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 のサイズ
が変わって来ても不思議は無い。これは驚くべきことである。

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

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

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

また、最終EXEが大きくなる理由として、アプリが使ってないオブジェクトを
非常に基本的なライブラリの一部が参照している可能性がある。
そしてそのオブジェクトが別のオブジェクトを勝手に参照して・・・という
事が続いて最終EXEのサイズが肥大化してしまっているのかも知れない。

715: 2014/09/01(月)16:33 ID:X69OanmZ(9/10)調 AAS
http://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 にするな、と
書かれている・・・。

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

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

ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.027s