Necessitas alpha4 delays

Wed Aug 22 12:20:12 UTC 2012

Thank you very much for your feedback.

  As I said at (3), the ABI break is out of question, there are more
than 400k *active* devices with Ministro installed, and an ABI break
will be a disaster for the project ! So, if we choose to go with (3),
changing Ministro is the *ONLY* solution.

  (4) is not that hacky as it sounds, actually is not a hack at all :)
Is the recommended way to turn a static library into a shared one
check: http://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_node/ld_3.html
the problems is that is not working as it should, and with some effort
we can fix it. It seems that the libstdc++ is embedded in QtCore, but
some symbols are not exported properly

I'd like to choose (4) because, alpha4 will not land immediately into
Ministro's "stable" repository, first it will go intro "testing"
repository, it will stay there at least one month, to give you all
enough time to test/update your existing apps against it, then, if no
regressions are reported, we'll move it to stable repository.

Cheers,
BogDan.

2012/8/22 Christian Lopes <christian.vrl at gmail.com>:
> I Agree with (3) - break ABI , and maybe launch a new Ministro to
> speed-up the process now.
>
> On Wed, Aug 22, 2012 at 8:24 AM, Adam Pigg <piggz1 at gmail.com> wrote:
>>
>> Agree.  I'd say go with whatever bogdan and the other revs think is the best
>> long term solution.  It's best to get it right now in alpha.  Worst case it
>> only takes a small amount then of time to recompile and publish an updated
>> application for me.
>>
>> Sent from my BlackBerry® PlayBook™
>> www.blackberry.com
>>
>> ________________________________
>> From: "noname" <freekee1 at gmx.de>
>> To: "android-qt at googlegroups.com" <android-qt at googlegroups.com>
>> Sent: August 22, 2012 10:41 AM
>> Subject: Re: Necessitas alpha4 delays
>>
>> I absolutely agree. nobody should expect an alpha ABI to be final and I'd
>> rather wait a little longer for having a nice solution instead of what seems
>> to be kinda hacky.
>> -> anoter vote vor (3)
>>
>> On 22.08.2012 11:34, sierdzio wrote:
>>
>> 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?id6472,  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
>>
>>