Necessitas alpha4 delays

Wed Aug 22 13:24:16 UTC 2012

Sorry if it's a bit offtopic, but, ¿How the Digia takeover of Qt stuff 
would affect Necessitas?
Wouldn't their resources be able to help?

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?
Shouldn't Necessitas be an important part of Digia's strategy?

Thanks in advance for any info regarding this.

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