Necessitas alpha4 delays

Wed Aug 22 09:34:10 UTC 2012

I'd vote for 3 (using shared lib).

This is still an ALPHA, ABI breakages are to be expected, and if someone 
complains - he is missing the point. Better to have a good solution that 
works than a hacky workaround, IMO.

On Wednesday, 22 August 2012 07:32:10 UTC+2, BogDan wrote:
>
> 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/9cfc6432/attachment.html>