Alpha4 release status

BogDan bog_dan_ro at yahoo.com
Mon Jun 11 16:11:53 UTC 2012 

Hi Harri,


> 
> Reading David Turner's mail from [1], it seems that Android atomics are 
> not SMP safe either, so in that sense using those is not any better than 
> Qt atomics?
> 

Last time when I checked their code they were. Indeed armv5 is not SMP safe,
but it doesn't need to be, as I said I know no SMP device which are using arm5
android. The problem is that Qt "exports" the atomics as inline function, which
means that their content will be "copied" into your application, meaning that
your application will uses those atomics everywhere.
My fifth proposal tries to fix this problem by removing the inline and your apps
will use whatever qt comes on that platform.

>
> In your solutions list you refer "fast atomics", but what are those?  
> If I understood you correctly, there are 3 options, Qt, android and 
> gcc.   First two are fast but not SMP safe, last is slow but SMP safe.
> 
> Are you saying that Qt armv7 is SMP safe and fast?
> 

Yes, armv7 is (can be made) SMP safe and is much faster comparing 
with gcc's implementation.

> If so, I'd vote for dropping arm5 support.  It would also make the 
> development/testing cycle faster with one less architecture to 
> support.   Usually arm5 devices are so low end with memory/screen/speed 
> wise that they don't work well in any case.
> 

I can't drop arm5 devices :) ! They are too many to be ignored.

> I'd rather have a Qt that is ready and working well for a subset of 
> devices than none at all.
> 
> I don't care about backward compatibility for my Qt Android apps (yet). 
>    I can always recompile those, and if I don't, the deserve to die.  
> While it is in Alpha this is expected.  Once in beta, backwards 
> compatibility is required.
>

If the ABI break can be avoided, I'll do it !
 
>
> The way I see it, Qt/Necessitas can get lots of new developers 
> interested for new projects if basics and new stuff works well. So I'd 
> worry about new devices, Qt 5/QML, and try to trim down work required on 
> maintenance type activities.   So from my perspective QtWidgets, arm5, 
> backwards compatibility all can be dropped now.
> 

After alpha4 and beta1 will be out I'll focus on Qt 5 and QML. For beta1 I 
wanted a QML implementation which has the same look&feel as any 
Android application, I hope somebody will step up and will do it.

>
> Anyways, keep up the good work!
> 

Thanks for your kind words.

> Just my 2 cents,
> 
> Harri
> 
> 

Cheers,
BogDan.

> 
> 
> On 06/10/2012 09:15 PM, BogDan Vatra wrote:
>>  Hi,
>> 
>>  Many thanks for kind words !
>> 
>>  Sadly, the magic happened :). The good news is that it was my fault,
>>  the bad news it that my worst nightmare happened ... :(
>>  After I write my first mail I begin to cherry-pick all my changes from
>>  alpha4 and put them on top of alpha3 branch, then I spot a patch which
>>  caught my attention, and I really hoped it's not the cause of this
>>  problem, but it was ...
>>  Some time ago somebody complained on this mailing list about the fact
>>  that he could not be able to compile necessitas anymore using ndk-r7,
>>  soon I discovered that the atomics functions where not exported
>>  anymore in ndk-r7, then my nightmare began, first I post the problem
>>  on android-ndk mailing list[1], then Google suggest me that I should
>>  switch to gcc's built in atomics which I did[2]. I knew that the gcc
>>  built in atomics are not the fastest in the world, but I never thought
>>  that they are that bad. Android atomics support on necessitas is a
>>  long story, which began more than a year ago, I'll try to make it
>>  shorter for you :)
>>  For the very first android atomics implementation, I used Qt's arm
>>  atomics, but I had to switch to gcc built-in atomics (yes, the second
>>  implementation was based on gcc atomics) because Qt's arm5 atomics
>>  where useless for Android, I'll try to explain why: The problem is
>>  that Qt's arm5 atomics are not SMP safe, so, is probable that your app
>>  will crash on a dual-core device. arm5 is very important because it is
>>  supported by all arm android devices, so it must be SMP safe. I
>>  address this problem last year at QCS[3], and somebody offer to help,
>>  but sadly nothing happened. So, I had to find a solution myself, GCC's
>>  implementation is using a sort of memory barrier (a mutext or
>>  something) to make it SMP safe, that why is so slow, then I discover
>>  that google is providing atomics in libc, which they should be SMP
>>  safe, so I switched to android atomics, then google change their mind
>>  and now they are dropping the support, so I had to switch back to gcc.
>> 
>>  To "fix" this problem I see the following "solutions":
>>  1. Ignore Google warning and keep using android atomics.
>>  2. Stay with gcc atomics, but is too slow.
>>  3. Build Qt libs with fast atomics, but find a way to have safe
>>  atomics for arm5.
>>  4. Build Qt libs with fast atomics, but use GCC atomics for apps.
>>  5. Build Qt libs with fast atomics, but don't make qt atomics inline
>>  anymore, this way your apps will use what qt provides for that
>>  platform. They will be a little by slower but they should be safe.
>>  This is my favorite solution, but I afraid that it will break the ABI
>>  ...
>> 
>>  It is safe to build Qt libs with fast atomics for arm5 because arm5
>>  libs will be downloaded Ministro *only* on arm5 devices and AFAIK
>>  there is no SMP arm5 device. The problem is that your apps are not
>>  downloaded by Ministro :) and if they are built only using armv5 they
>>  will be loaded by a SMP device and they will have problems, so arm5
>>  atomics must be SMP safe.
>> 
>>  Anyway we have to address the problem once and for all !
>> 
>>  If any of you has any other Ideas please don't hesitate to share them 
> with us.
>>  Also any comments/feedback will be very appreciated.
>> 
>>  Cheers,
>>  BogDan.
>> 
>> 
>>  [1] 
> https://groups.google.com/group/android-ndk/browse_thread/thread/a792d8392b01f389/ecbad8bb4981ed8d
>>  [2] 
> http://commits.kde.org/android-qt/aa14a65fd29f20adb7aa22b354c975d76266bed1
>>  [3] http://community.kde.org/Necessitas/Meetings/QtCS2011
>> 
>> 
>>  2012/6/10 Bruno Zerbo<bruno.zerbo at gmail.com>:
>>>  Thanks BogDan for your work.
>>>  cheers,
>>>  Bruno
>>> 
>>> 
>>>  2012/6/10 BogDan Vatra<taipanromania at gmail.com>
>>>>  Hello folks,
>>>> 
>>>>    Unfortunately I have more bad news regarding alpha4 release, I
>>>>  manage to fix the OpenGL problem, but I discover another one. The
>>>>  startup of all applications has slowdown a lot (2-4 times), the
>>>>  problem is the difference between alpha3 and alpha4 is huge (1000+
>>>>  patches). Alpha3 is based on Qt 4.8.0-rc and alpha4 is based on Qt
>>>>  4.8.2, to be sure the problem is not caused by me, I have to
>>>>  cherry-pick all my changes and put them on top of alpha3, them, if 
> is
>>>>  not my fault the pain begins, I'll have to merge Qt 4.8.0, 
> check, then
>>>>  Qt 4.8.1, then Qt 4.8.2. This is going to be a very slow and 
> painful
>>>>  process which will take days (even weeks) so, I don't believe 
> alpha4
>>>>  will be out before QCS, unless a miracle happens and I'll found 
> the
>>>>  issue in the next days.
>>>> 
>>>>  Sorry for the bad news ...
>>>> 
>>>>  Cheers,
>>>>  BogDan.
>>>> 
>>>> 
>>>>  2012/6/4 BogDan<taipanromania at gmail.com>:
>>>>>  This 
> http://files.kde.org/necessitas/installer/MinistroActivity.apk is
>>>>>  the link to Ministro.
>>>>> 
>>>>>  BogDan.
>>>>> 
>>>>> 
>>>>>  On Jun 4, 2:02 pm, BogDan Vatra<taipanroma... at gmail.com>  
> wrote:
>>>>>>  Hi everyone,
>>>>>> 
>>>>>>    As you may know the alpha4 release is approaching, the 
> plan is to
>>>>>>  have it ready before Qt Contributors Summit. It is almost 
> completed, I
>>>>>>  need a few days to polish the style plugin and Minitro and 
> another few
>>>>>>  to add support for context menus.
>>>>>> 
>>>>>>     A few days ago I pushed to Minnistro's 
> "unstable" repository the
>>>>>>  current alpha4 branch in order to check if the existing 
> released apps
>>>>>>  are still working. Even we've made some heavy changes 
> and even if I
>>>>>>  warn you that it may break the compatibility with older 
> versions, I
>>>>>>  wanted alpha4 to be backward compatible with alpha3, it is 
> also a test
>>>>>>  for Necessitas developers to see if we can keep our 
> promise: to ship
>>>>>>  releases which are backward compatible!
>>>>>> 
>>>>>>  If you want to try it yourself please follow the next two 
> steps:
>>>>>>    - uninstall official Ministro and use this
>>>>>>  onehttp://files.kde.org/necessitas/MinistroActivity.apk.
>>>>>>    - install and run Ministro configuration tool (from 
> market) and
>>>>>>  choose unstable repository.
>>>>>> 
>>>>>>  Don't forget that Ministro is not stable and it may 
> crash/hang, if you
>>>>>>  encounter any problems please reply on this thread.
>>>>>> 
>>>>>>  Shorty after the repository was ready, I tried a few apps 
> from market
>>>>>>  and two major problems pop up:
>>>>>>  - The first problem was related to some missing symbols and 
> was caused
>>>>>>  by compilation/linking flags.
>>>>>>  - The second one is related to OpenGL and it seems to be 
> caused by the
>>>>>>  merge with Qt 4.8.2.
>>>>>> 
>>>>>>  1. Missing symbols problem: Android comes with almost no 
> support for
>>>>>>  C++, so to compile Qt we used (static) gnu-libstdc++.
>>>>>>  Then I discovered that this was a big mistake (for more 
> information
>>>>>>  check Android NDK docs/CPLUSPLUS-SUPPORT.html "II.3. 
> Static runtimes:"
>>>>>>  section).
>>>>>>  We can not use link libstdc++ statically if we are using 
> more than one
>>>>>>  shared libraries in a project. To fix this problem I had 
> two choices:
>>>>>>    - to use the shared libstdc++ implementation and to 
> change all the
>>>>>>  scripts in order to add it to ministro (1.2M).
>>>>>>    - to "embed" the whole library into QtCore 
> library (it adds and extra
>>>>>>  600K) but this change requires no additional changes.
>>>>>> 
>>>>>>  I choose the second one [1],[2] because it was safe and 
> easy and
>>>>>>  mostly because it didn't needed any other changes.
>>>>>>  If anybody has something against this change speak now or 
> forever hold
>>>>>>  your peace !
>>>>>> 
>>>>>>  I'd like to add exceptions and RTTI by default, if the 
> size and speed
>>>>>>  will not be affected.
>>>>>> 
>>>>>>  2. OpenGL problem: After I merged alpha4 branch with 
> upstream Qt
>>>>>>  4.8.2, most of the OpenGL apps are not working anymore, I 
> tried to fix
>>>>>>  it my self but I end up with a very ugly workarround. It 
> seems that
>>>>>> 
>>>>>> 
> "boolQGLContext::areSharing(constQGLContext*context1,constQGLContext*contex
>>>>>>  t2)"
>>>>>>  always returns false. I tried to trace the problem but with 
> no luck
>>>>>>  and I end up adding a super dirty workarround: on android,
>>>>>>  "QGLContext::areSharing", will always returns 
> true. I really don't
>>>>>>  like it, so until we'll figure out what is wrong the 
> release process
>>>>>>  will stop ...
>>>>>> 
>>>>>>  Any help will on this matter be very appreciated !
>>>>>> 
>>>>>>  I've spot another minor problem with old assets support 
> it was caused
>>>>>>  by "QString 
> QDeclarativeTypeLoader::absoluteFilePath(const QString
>>>>>>  &path)" I fixed it locally but I didn't had 
> time to push the fix to
>>>>>>  Minsitro's repository yet.
>>>>>>  I'll keep you post with the progress and with any 
> Ministro repository
>>>>>>  changes.
>>>>>> 
>>>>>>  Cheers,
>>>>>>  BogDan.
>>>>>> 
>>>>>> 
>>>>>> 
> [1]http://quickgit.kde.org/index.php?p=android-qt.git&a=commit&h=8c4c862...
>>>>>> 
>>>>>> 
> [2]http://quickgit.kde.org/index.php?p=android-qt.git&a=commit&h=abe85f4...
>>> 
>>  _______________________________________________
>>  Necessitas-devel mailing list
>>  Necessitas-devel at kde.org
>>  https://mail.kde.org/mailman/listinfo/necessitas-devel
> 
> _______________________________________________
> Necessitas-devel mailing list
> Necessitas-devel at kde.org
> https://mail.kde.org/mailman/listinfo/necessitas-devel
>

More information about the Necessitas-devel mailing list