Binary size doubled with recent version of Wt
I would like to ask, if using Wt on embedded systems is still taken in concern?
I have noticed rise of the size of the target binary (almost doubled) with recent version of Wt.
I have compiled simple program (just some WText) with gcc 4.6.4 for armv7 architecture using static libraries of Wt, boost, openssl and zlib.
I was unable to use the same version of boost (compile errors) and I can't test Wt4 (compiler without support for c++11).
See size comparison in the table:
Wt | 3.3.6 | 3.2.3 | boost | 1.58 | 1.51 | ------------+-------+-------+ test | 9,2M | 4,9M | test.tgz | 2,5M | 1,7M | libwt.a | 337M | 108M | libwthttp.a | 23M | 12M |
Wt is compiled with -fvisibility=hidden -fvisibility-inlines-hidden -ffunction-sections -fdata-sections -DHAVE_GNU_REGEX
test is compiled and linked with folowing commands and finaly stripped.
arm-linux-gnueabi-g++ -march=armv7-a -mtune=cortex-a9 -mcpu=marvell-pj4b -mthumb-interwork -mfloat-abi=softfp -mfpu=vfpv3-d16 -mlittle-endian -pipe -O2 -Wwrite-strings -Wcast-align -Wall -fPIC -Iinclude -I../wt/staging/include -c src/test.cpp -o test.o arm-linux-gnueabi-gcc test.o wtmain.o -L../wt/staging/lib -lwthttp -lwt -lboost_regex -lboost_signals -lboost_system -lboost_thread -lboost_filesystem -lboost_program_options -lboost_date_time -lboost_random -lboost_chrono -lssl -lcrypto -lz -Wl,-Bstatic -lcrypt -Wl,-Bdynamic -pthread -lrt -lm -lstdc++ -ldl -o test
Updated by Wim Dumon over 5 years ago
I must admit that we don't always check the binary size of Wt. There are many more features in Wt now than in 3.2.3, but 4.3MB of extra binary size seems quite a bit. We'll do a short check to see if anything is out of the ordinary.
Maybe you can take a look at your binary too? Something like
arm-linux-gnueabi-nm --print-size --size-sort --radix=d test.wt usually gives a lot of useful information...
Updated by Roel Standaert over 5 years ago
I did a size comparison with a little test program (one WText that says "Hello!") between 3.2.3 and the latest master, not cross-compiled but just for x86_64, and the size difference wasn't as dramatic.
If I use Boost 1.58.0, it's 3.4 MiB for Wt 3.2.3 and 4 MiB for the latest master (3.8 MiB if I use Boost.Signals instead of Boost.Signals2).
Did you compile both versions of Boost in the same way? Maybe some difference in compiler options could account for this large difference. Also, you could maybe reduce the size of your binary more if you use the
--gc-sections linker option (see http://redmine.webtoolkit.eu/projects/wt/wiki/Wt_embedded).
By the way, you can get Wt 3.3.6 to compile with Boost 1.51 if in
src/Wt/Chart/WAxis.C you replace
boost::unordered_map<AxisValue, LabelTransform > with
boost::unordered_map<int, LabelTransform >.
Updated by Jan Hrubeš over 5 years ago
I tested more combinations on x86_64 (gcc 6.2.0, without openssl, zlib) and armv7 (gcc 4.6.4, with openssl, zlib):
armv7 x86_64 Wt boost 4.9M 4,2M 3.2.3 1.51 6.9M 6,3M 3.3.6 1.51 9.2M 8,9M 3.3.6 1.58 - 6,2M wt4 1.51 - 6,2M wt4 1.58
Binary made with Wt 3.3.6 and boost 1.58 is as twice large as binary with Wt 3.2.3 and boost 1.51. With wt4, the binary size was in the middle and was not dependant on the boost (wt4 branch from git, boost libraries system, thread, filesystem and program_options was needed). Binaries for armv7 was slightly larger because of static linking with the openssl and zlib libraries.
Wt 3.3.6 compile with boost 1.51 using patch you mentioned, Wt 3.2.3 failed to compile with boost 1.58 with
src/Wt/Json/Parser.C:27:57: fatal error: boost/spirit/home/phoenix/statement/throw.hpp: No such file or directory
Have you achieved the size around 4M using static libraries of Wt and boost? Please take a look at linking options in the first post.