<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div>> For example, I've seen way too many<br>
projects screw up with Brew because they fail to ship a binary that<br>
can work on a clean user system who is not going to install Brew.<br><br></div>I must be lucky then, because just using macdeployqt copies all the dependencies for me and <br></div>updates all the install paths correctly whether I use Qt's own build or brew's.<br><br>> It pulls a new version of gcc instead of using Xcode/clang on<br>
your system and builds an entire dependency chain based on GNU tools.<br><br></div>this is false. brew uses xcode & clang on your system.<br><br>> Similar problem for Windows...Visual Studio is the requirement.<br><br></div>I don't know if you are talking about Chocolatey or Qt but neither require Visual Studio on windows.<br></div>Qt even comes with MinGW if you wish.<br><br>> And Mac doesn't have configure/autotools by defaul.<br></div><br>but... "configure" has nothing to do with autotools. <br></div><div>It's just a shell script (which is sometimes generated *from* autotools; this is not the case with Qt AFAIK). <br><br>> and I never figured why Qt's RAM consumption footprint is so high...based on all the DLL binary code it<br>
has to load, or something more intrinsic to its implementation.<br><br></div>science can help us here :p two tools are very nice for this : <br></div><div><br></div>* bloaty mcbloatface for binary bloat<br> <br></div><div> <span style="font-family:monospace,monospace">for file in /usr/lib/libQt5*.so ; do (echo $file; bloaty $file| grep -A3 'text') ; done</span><br><br></div>tells us stuff like</div><div><span style="font-family:monospace,monospace"><br></span></div><div><span style="font-family:monospace,monospace">/usr/lib/libQt5Core.so<br> 55.4% 2.75Mi .text 2.75Mi 55.5%<br> 23.5% 1.16Mi .rodata 1.16Mi 23.5%<br> 7.3% 372Ki .eh_frame 372Ki 7.4%<br> 4.1% 210Ki .dynstr 210Ki 4.2%<br>/usr/lib/libQt5Gui.so<br> 70.0% 3.82Mi .text 3.82Mi 70.2%<br> 7.8% 438Ki .eh_frame 438Ki 7.9%<br> 6.1% 342Ki .dynstr 342Ki 6.1%<br> 5.1% 286Ki .rodata 286Ki 5.1%</span><br></div><div><br></div>A bit surprising to see .eh_frame; I thought Qt was compiled with -fno-exceptions but maybe that's just my distro.<br></div>Quite a bunch of .rodata in Qt5Core too, I wonder why.<br></div>Further examination through <br> <span style="font-family:monospace,monospace">readelf -x .rodata /usr/lib/libQt5Core.so | less</span><br></div>seems to show up a lot of locale-specific calendar text & such, e.g. names of the months in twenty languages, currencies, time zones, etc<br><div><br><div><div><div><div><div><div><div><div>* And then, runtime examination: for this I tried making a minimal gui program:</div><div><span style="font-family:monospace,monospace">#include <QApplication><br>#include <QMainWindow><br>int main(int argc, char**argv)<br>{<br> QApplication app(argc, argv);<br> QMainWindow w;<br> w.show();<br> return app.exec();<br>}</span></div><div><br></div><div>compiled with<span style="font-family:monospace,monospace"><br></span></div><div><span style="font-family:monospace,monospace">g++ -DQT_NO_DEBUG -fPIC -I/usr/include/qt/ -I/usr/include/qt/QtCore -I/usr/include/qt/QtWidgets -I/usr/include/qt/QtGui main.cpp -lQt5Core -lQt5Widgets </span><br></div><div><br></div><div>and then use the wonderful Heaptrack (<a href="https://github.com/KDE/heaptrack">https://github.com/KDE/heaptrack</a>) : <br></div><div><span style="font-family:monospace,monospace"><br></span></div><div><span style="font-family:monospace,monospace">heaptrack ./a.out</span></div><div><br></div><div>which then greets us with <a href="http://imgur.com/a/eYjaL">http://imgur.com/a/eYjaL</a></div><div><br></div><div>As you can see, "peak heap memory consumption" is at a bit less than 400 <i>kilobytes</i>. So the Qt memory usage that you see is clearly due only to binary bloat. <br></div><div>And indeed (sorry for shitty bash skills):<br></div><div><br></div><div><span style="font-family:monospace,monospace">$ ldd a.out | cut -d '=' -f1 | awk '{print "/usr/lib/" $1;}' | xargs readlink | awk '{print "/usr/lib/" $1;}' | xargs du -csh | sort -h <br>16K /usr/lib/<a href="http://libdl-2.25.so">libdl-2.25.so</a><br>16K /usr/lib/libXau.so.6.0.0<br>24K /usr/lib/libXdmcp.so.6.0.0<br>32K /usr/lib/<a href="http://librt-2.25.so">librt-2.25.so</a><br>64K /usr/lib/libdouble-conversion.so.1.0.0<br>68K /usr/lib/libbz2.so.1.0.6<br>72K /usr/lib/libGLX.so.0.0.0<br>72K /usr/lib/libXext.so.6.4.0<br>80K /usr/lib/liblz4.so.1.7.5<br>84K /usr/lib/libgpg-error.so.0.22.0<br>92K /usr/lib/libz.so.1.2.11<br>144K /usr/lib/<a href="http://libpthread-2.25.so">libpthread-2.25.so</a><br>152K /usr/lib/liblzma.so.5.2.3<br>164K /usr/lib/libxcb.so.1.1.0<br>176K /usr/lib/libgraphite2.so.3.0.1<br>216K /usr/lib/libpng16.so.16.31.0<br>444K /usr/lib/libpcre2-16.so.0.5.0<br>460K /usr/lib/libpcre.so.1.2.9<br>536K /usr/lib/libsystemd.so.0.19.0<br>548K /usr/lib/libharfbuzz.so.0.10400.5<br>552K /usr/lib/libGL.so.1.0.0<br>600K /usr/lib/libGLdispatch.so.0.0.0<br>796K /usr/lib/libfreetype.so.6.14.0<br>1,1M /usr/lib/libglib-2.0.so.0.5200.3<br>1,1M /usr/lib/<a href="http://libm-2.25.so">libm-2.25.so</a><br>1,2M /usr/lib/libgcrypt.so.20.2.0<br>1,3M /usr/lib/libX11.so.6.3.0<br>1,7M /usr/lib/libicuuc.so.59.1<br>1,9M /usr/lib/<a href="http://libc-2.25.so">libc-2.25.so</a><br>2,5M /usr/lib/libicui18n.so.59.1<br>5,0M /usr/lib/libQt5Core.so.5.9.1<br>5,5M /usr/lib/libQt5Gui.so.5.9.1<br>6,4M /usr/lib/libQt5Widgets.so.5.9.1<br>12M /usr/lib/libstdc++.so.6.0.24<br>26M /usr/lib/libicudata.so.59.1<br>69M total</span></div><div><br></div><div>So there's 17 megabytes of Qt in here; hopefully the rest would already be loaded by your system. <br></div></div></div></div></div></div></div></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Best,</div><div class="gmail_extra">Jean-Michaël</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On Thu, Aug 17, 2017 at 3:34 AM, Eric Wing <span dir="ltr"><<a href="mailto:ewmailing@gmail.com" target="_blank">ewmailing@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 8/16/17, Jean-Michaël Celerier <<a href="mailto:jeanmichael.celerier@gmail.com">jeanmichael.celerier@gmail.<wbr>com</a>> wrote:<br>
> @Eric Wing<br>
>> I am not making a strong push for this, but I want to bring it up to<br>
> at least get people thinking about this... I am disturbed by the size<br>
> and complexity of Qt. My past experiences have not been good and I<br>
> find it a massive chore to get an environment setup (especially on Mac<br>
> and Windows...and building Qt on Raspberry Pi is a nightmare).<br>
><br>
> Really ? On mac it's just brew install qt. On windows choco install qt-sdk<br>
> (and it even comes with mingw so that you don't necessarily have to install<br>
> visual studio).<br>
> On Raspberry sudo apt-get install qtbase5-dev.<br>
><br>
<br>
</span>So 3rd party package systems are banned for me. They cause too many<br>
dependency problems themselves. For example, I've seen way too many<br>
projects screw up with Brew because they fail to ship a binary that<br>
can work on a clean user system who is not going to install Brew.<br>
Also, it causes needless redundancy and changes the toolset if I<br>
recall. It pulls a new version of gcc instead of using Xcode/clang on<br>
your system and builds an entire dependency chain based on GNU tools.<br>
Similar problem for Windows...Visual Studio is the requirement.<br>
<br>
As for Pi, I think the problem I had was the Qt available in the repo<br>
at the time was too old for me. (Typical Debian long release cycle<br>
problem.)<br>
<br>
But I still consider it a problem if these things are too hard to<br>
build because (especially for me) there is always a new platform that<br>
needs to be ported to.<br>
<span class=""><br>
<br>
> Building qt itself is a matter of doing (cue errors from typing in a mail<br>
> without checking)<br>
><br>
> git clone <a href="https://github.com/qt/qt5" rel="noreferrer" target="_blank">https://github.com/qt/qt5</a><br>
> cd qt5 ; git submodule update --init qtbase ... # whatever submodules you<br>
> need<br>
> ./configure -open-source -confirm-license -nomake tests -nomake examples<br>
> -prefix /opt/my-qt<br>
> make -j8 && make install<br>
><br>
<br>
</span>My last experience was that there were critical bugs in the Qt Mac<br>
release at the time (and this was the official binary release). And<br>
Mac doesn't have configure/autotools by defaul. Again...no brew for<br>
various reasons like above.<br>
<span class=""><br>
><br>
> Maybe consider a LTCG build (-ltcg) if this really matters ? This way I can<br>
> get a moderately complex GUI app that uses gui, widgets, network, qml,<br>
> etc...<br>
> under ten megabytes, so something like cmake-gui should be way smaller...<br>
> (this also removes any problem related to DLLs).<br>
<br>
</span>I wouldn't be able to say. And I never figured why Qt's RAM<br>
consumption footprint is so high...based on all the DLL binary code it<br>
has to load, or something more intrinsic to its implementation.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
-Eric<br>
</font></span></blockquote></div><br></div></div>