Alpha4 release status

BogDan Vatra taipanromania at gmail.com
Mon Jun 18 16:52:31 UTC 2012


Yes, but sadly after QtCS :( !

I just ping kde guys moments ago, I hope they finished !

BogDan.

2012/6/18 Marco Bernasocchi <marco at bernawebdesign.ch>:
> So where are the bad news? :D sounds great! and sounds like alpha 4 might
> come soon :)
> enjoy QCS.
>
> thanks a lot Marco
>
> PS, let me know when you hear from kde.
> ciao
>
>
>
> On 06/17/2012 12:58 PM, BogDan Vatra wrote:
>>
>> Hello everyone,
>>
>> I have some good and bad news.
>>
>> I changed the atomics in order to make the safe, I chose the fifth
>> approach and it seems they are just a little bit slower, because it
>> has to do an extra function call. The good news are there is no ABI
>> break, so I can still play my favorite GPLv3 Qt game which I bought it
>> a few months ago :). No, I'm not crazy :)! I bought a GPLv3 game
>> because I like it! It also helped me a lot to test alpha4 branch. The
>> bad news is that the application start up is still slower comparing
>> with alpha3, this is because I've done a little hack in android assets
>> implementation to keep the compatibility with alpha3. But if the
>> assets access will be updated to alpha4, the start up is almost the
>> same. I'm not going to fix this problem now, because I don't have
>> enough time, after alpha4 is out, we'll focus on performance and
>> bugfixes only.
>>
>>
>> Cheers,
>> BogDan.
>>
>>
>> 2012/6/15 Tyler Mandry<tmandry at gmail.com>:
>>>
>>> I say try 5) and benchmark it.
>>>
>>> I understand that you're trying to keep backward compatibility, but for
>>> such
>>> fundamental and important changes, IMO it is far better to break the ABI
>>> now
>>> than to pay for it in the future. Besides, we are still in alpha,
>>> breaking
>>> the ABI should be considered a regular occurrence ;)
>>>
>>>
>>> On Sunday, June 10, 2012 12:15:12 PM UTC-7, BogDan 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...
>>>>>
>>>>>
>


More information about the Necessitas-devel mailing list