Necessitas alpha4 delays

Wed Aug 22 16:14:33 UTC 2012

It is more than a little bit offtopic :) I can't comment on this topic
because I don't have too much information.
What I can comment is the fact that we are committed to make Qt a the
best C++ framework for Android.
In this moment, I don't know if or how Digia will affect/help
Necessitas, let's wait for the deal to be finished first :)

Thanks for your understanding !

Cheers,
BogDan,

2012/8/22 Cesar Ribera <cribera at gmail.com>:
> 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