Sorry if it's a bit offtopic, but, ¿How the Digia takeover of Qt stuff would affect Necessitas?<div>Wouldn't their resources be able to help?</div><div><br></div><div>Have Digia contacted you Bogdan, or any other major contributor, to offer help (or even hire you full time, if that would be necessary)? Do you plan to contact them?</div><div>Shouldn't Necessitas be an important part of Digia's strategy?</div><div><br></div><div>Thanks in advance for any info regarding this.</div><div><br></div><div>El miércoles, 22 de agosto de 2012 01:32:10 UTC-4, BogDan  escribió:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hello everyone,
<br>
<br>We've faced some big problems which prevent us to release alpha4 SDK,
<br>so, I think we own you some explanations why we delay it that much.
<br>
<br>  First problem we've encountered it was the changes done in QtCreator
<br>(by Nokia guys), which delayed the release with more than 2-3 weeks,
<br>then we had to wait for ssl certificates for Ministro to arrive, then
<br>we've discovered that the official Android NDK had to be rebuilt for
<br>all platforms, then, again, we've found problems in QtCreator, then
<br>the SDK installer keep me busy for a couple of days, then we've face
<br>even more problems with Ministro [1] and now we've found the biggest
<br>one, which might break some apps.
<br>The problem is the C++ support on Android. The default libstdc++
<br>library is useless, it contains only "new", "delete", "type_info"
<br>implementations, so we had to use something else which also comes with
<br>stl support, so I choose to use the static gnu libstdc++.
<br>Shortly after we release alpha3 I found that is not very wise to use
<br>static libstdc++ on more than one library,
<br>android-ndk/docs/STANDALONE-<wbr>TOOLCHAIN.html says that:
<br>
<br>[quote]
<br>The standalone toolchain also comes with a copy of the GNU libstdc++
<br>library, which provides an implementation of the C++ Standard Template
<br>Library. To use it, you however need to link with the proper library:
<br>
<br>  * Use -lstdc++ to link against the _static_ library version. This ensures
<br>    that all required C++ STL code is included into your final binary. This
<br>    is ideal if you are only generating a single shared library or executable.
<br>
<br>    This is the recommended way to do it.
<br>
<br>  * Use -lgnustl_shared to link against the _shared_ library version. This
<br>    is required if you have several related shared libraries or executables
<br>    that need to run in the same address space at runtime (some global variables
<br>    need to be defined uniquely, which is not possible if you link the static
<br>    libstdc++ against each one of your executables).
<br>[/quote]
<br>
<br>Now the question is, how to fix this problem without breaking the ABI?
<br>The answer it seemed to be easy, theoretically just adding the whole
<br>libstdc++ to QtCore should do the job [2], I loved myself for that
<br>idea, but ... not for a long time, because hey, in real life nothing
<br>is that simple, after we shipped the second testing SDK, Marco post an
<br>alarming message [3] on necessitas-devel mailing list. The problem
<br>seems to be easy to fix, because I removed the STL library from the
<br>mkspecs file, the STL test didn't  compile anymore and that it seemed
<br>it  was the reason for the problems, but again, "la vie en rose"
<br>doesn't apply to me, because soon I discover that the --whole-archive
<br>[2] flag is not working as it should, basically it doesn't export all
<br>the symbols from libstdc++ and you can not use only QtCore to link
<br>your STL apps. We (mostly Ray)  tried a lot of different paths but all
<br>of them ended badly, then Ray reported this issue to Google
<br><a href="http://code.google.com/p/android/issues/detail?id=36472" target="_blank">http://code.google.com/p/<wbr>android/issues/detail?id=36472</a><wbr>,  we really
<br>hopped that we did something stupid but ... it seems we didn't.
<br>
<br>Now we must decide what we do next, we see the following solutions:
<br>1 - Release the SDK in a few days, but we must keep it as it is, try
<br>to embed the whole libstdc++ library into QtCore, even it is not
<br>exported all of it,but it seems it fixes the "static libstdc++"
<br>problem described above, but we are not 100% sure.
<br>2 - Delay the release, and fix the bloody linker, make it export
<br>everything it should from libstdc++. The "static libstdc++" problem
<br>will be 100% fixed (at least theoretically).
<br>3 - Delay the release, switch to shared libstdc++ library, but this
<br>move it will break the ABI, because all existing apps will search for
<br>stl and c++ symbols into QtCore not in the shared libstdc++. Of course
<br>we can not afford to break all existing apps, so we Ministro will need
<br>more love to handle multiple ABI versions.
<br>4. Is a combination between first and the seconds solution: we ship
<br>the SDK now (1), but we (actually Ray is doing this tremendous job,
<br>I'm just  the assistant)  keep working on (2).
<br>
<br>Please let us know your opinions on this matter.
<br>
<br>Any help with (2) will be very appreciated.
<br>
<br>Cheers,
<br>BogDan.
<br>
<br>
<br>[1] <a href="http://www.omat.nl/2012/08/11/how-necessitas-grew-to-be-a-20tb-of-traffic-a-month-project/" target="_blank">http://www.omat.nl/2012/08/11/<wbr>how-necessitas-grew-to-be-a-<wbr>20tb-of-traffic-a-month-<wbr>project/</a>
<br>[2] <a href="http://quickgit.kde.org/index.php?p=android-qt.git&a=blobdiff&h=348a33a421017d7fd77426dec24736cadec83d1f&hp=d7306e05aca22ba519b7b4d3332197649619779f&hb=8c4c862ee26283d1f4cd698071d002577aff72df&f=src/corelib/corelib.pro" target="_blank">http://quickgit.kde.org/index.<wbr>php?p=android-qt.git&a=<wbr>blobdiff&h=<wbr>348a33a421017d7fd77426dec24736<wbr>cadec83d1f&hp=<wbr>d7306e05aca22ba519b7b4d3332197<wbr>649619779f&hb=<wbr>8c4c862ee26283d1f4cd698071d002<wbr>577aff72df&f=src/corelib/<wbr>corelib.pro</a>
<br>[3] <a href="http://mail.kde.org/pipermail/necessitas-devel/2012-August/001123.html" target="_blank">http://mail.kde.org/pipermail/<wbr>necessitas-devel/2012-August/<wbr>001123.html</a>
<br></blockquote></div>