[Interest] static build for android and ios

[Thiago Macieira]

On Tuesday 14 July 2015 09:35:51 Gian Maxera wrote:
> The advantage on mobile is the size of the App.
> Qt is made of module, if you compile it statically, you don’t have a giant
> big library, but a lot of static modules. So, every module link against (at
> least) QtCore … that means you have a lot of duplication of static code to
> link against it and the result will be a bigger app full of duplication of
> object code.

Your understanding of static libraries is incorrect. There is no duplication 
of QtCore: there would be only one copy of it in the final binary. More than 
one copy would result in a crash very early on when one module's concept of a 
null QString didn't match another.

The linker will include all of your .o files, then select only the .o from the 
libraries that are needed to resolve symbols that weren't resolved yet (that's 
also the reason why the order of static libraries is important).

> Another advantage is the startup time. A static app is a big .exe to put
> fully on the memory before to start the app. That means if your app is
> bigger of 40Mb at startup your mobile device need to fully load it into
> memory before start the app. If it’s dynamic link, the library are loaded
> only when needed. That means, if your app is only 2Mb of code, you load at
> startup only 2Mb and then when some features are needed the corresponding
> library is loaded.

Again, incorrect understanding.

First of all, if loading everything were necessary, then all the .so would 
need to be fully loaded and usually that's a bigger size than a static binary.

Second, the files are always mmap()ed to memory, so only the pages actually 
used will be loaded. There's no reason why a static binary would need to run 
more code at an earlier stage than a comparable dynamic binary.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center