26. jan. 2012 02.25 skrev Hui Zhang <[email protected]>: > Thank you a lot, mingw! > > Why do not google officially move to 4.6.x Linaro toolchains? I think > the reason is following: > (1) Mer don't have a lot of legacy baggage it's forced to carry, So > Mer can move to advanced toolchains easily; > (2) Android is such a huge monster that it is hard for android to move > to advanced toolchains. > Is the above reason right? For any distribution moving to a later toolchain is difficult, as the newer GCC versions has a tendency to complain more about 'bad' code and hence fail builds. In defense of Android, I'm not sure the fact it's a huge monster is what will keep it back.
I think the problem is that the work to fix things has has to be done anyway - with Mer, we can easily adapt new toolchains and fix code right away and release the fixes to make it work with newer toolchains. We can pretty quickly identify where we need to fix as we get a report exactly where things break when we add a new toolchain. Android hasn't invested the time in fixing these bugs and releasing them to the general public (due to their release model), hence vendors can't utilize modern toolchains either as Android simply won't build with it. That said, there is an android linaro project, which has been working on fixing these things with an up to date Linaro GCC, mostly with an ARM focus. They don't have access to the internal releases from Google and hence they have difficulty submitting patches. BR Carsten Munk > > Thanks! > > BR > zhanghui > > On 1/25/12, mingw android <[email protected]> wrote: >> On Wed, Jan 25, 2012 at 8:48 AM, Hui Zhang <[email protected]> wrote: >>> On 1/24/12, Carsten Munk <[email protected]> wrote: >>>> 23. jan. 2012 13.15 skrev Hui Zhang <[email protected]>: >>>>> Hi all, >>>>> I am considering one important question: What is Mer's advantage >>>>> over >>>>> Android? In technical point of view, in marketing point of view, etc... >>>>> Any >>>>> are appreciated:) >>>>> >>>>> In 2012 Q1, an important task for me is to convince TV vendors >>>>> (even >>>>> chip vendors such as MSTAR and MTK) that Mer can replace Android well. >>>>> If I can say something about Mer's advantage, it will do great help. >>>> >>>> A very big question :) On technical point of view, we have advantages >>>> such >>>> as: >>>> >>>> * Our source code is always available and accessible, so you and your >>>> company can see what direction the Mer stack is going in and influence >>>> it. In Android, not even partners in Open Handset Alliance (except >>>> maybe the people doing a lead device) gets to see the source code >>>> before release. In practice, this means that any contributions you may >>>> do to Android will likely never get merged as the source code that >>>> exists externally may have moved on significantly internally. >>>> >>> Agree. As far as openness is concerned, Mer is better than Android. >>> >>>> * Ability to use most open source software and libraries out there >>>> with ease, as we are implementing a full set of POSIX APIs as we use >>>> glibc. Android's bionic only implements a subset and doesn't implement >>>> things like C++ exceptions. >>> Agree. As far as compatibility to linux community is concerned, >>> Mer is better than Android. >>>> >>>> * Mer is designed to be a core for many different kind of mobile >>>> devices, while Android is built with focus of being for handsets - >>>> just remember the difficulties with Honeycomb and enabling tablet >>>> usage. >>> I don't quite catch this. What difficulites with Honeycomb for >>> tablet usage? >>> And as for TV, googleTV was announced May, 2010; And In 2011, >>> Serveral companies such as LG took android TV into account. >>> In this point of view, what does Mer provides? >>>> >>>> * Mer is optimized for ARM using the Linaro GCC 4.6.2 toolchains and >>>> deliverables, giving bleeding edge performance optimizations, while >>>> Android is currently is on 4.4. >>> I think Android can also use Linaro GCC4.6.2(or more advanced >>> toolchains than 4.4). Do you think that there exist some difficulites >>> for android to use Linaro GCC4.6.2 or alike? >> >> I can answer this as I've had a hand in the 4.6.x Linaro toolchains >> used by both Mer and Android (I provide my own version of the NDK >> which I think was the first NDK to move over to using Linaro's >> releases). Yes, both can use Linaro 4.6.x (so long as you follow the >> ABI any code generator can be used - of course with Android, you're >> not using Google officially sanctioned toolchain which is still at >> 4.4.3). The critical difference between Mer and Android in this regard >> is that on Mer, the entire system is built with 4.6.3 whereas on >> Android it's only apps built with the NDK that can take advantage of >> the improvements (should the app developer know about the alternative >> NDKs or care about performance or neon). The manufacturers will be >> using GCC 4.4.3 for the kernel and all the standard Android bits. On a >> tangential point, any Android devs using a 4.4.3 toolchain should also >> avoid using any neon intrinsics as 4.4.3 neon is totally bust. >> >>>> >>>> * Mer is flexible, you can pick and choose what components you'd like >>>> to include in an image - and is meant to be ultraportable to many >>>> different kind of devices. The idea is that you can with ease switch >>>> hardware adaptation, or UX and spread across many kind of different >>>> devices. >>> Maybe android also can do this...? I don't quite understand. >>>> >>>> * Mer supports multiple application stories, C, C++, HTML5, QML, >>>> JavaScript, etc. >>> Yes, If Mer can do well in supporting HTML5 apps, that's very good:) >>>> >>>> * Mer can take full advantage of graphics acceleration through GPU, >>>> especially with Qt5's scenegraph work. As well as multiple graphics >>>> backends, X11, wayland, DirectFB, etc. >>> As for multiple graphics backends, it is Mer's compability advantage; >>> But how to understand "Mer can take full advantage of graphics >>> acceleration through GPU"? I think android's graphics acceleration >>> have already done a good job:) >>>> >>>> * Mer tries to make life easy for vendors wanting to make Mer products >>>> - as well as having a organisation that allows people to work together >>>> without the project giving preferential treatment to certain partners, >>>> or abuse influence to gain preference in the OS to a certain company's >>>> products, both chipset, internet services or phones. We also support >>>> easily ramping up bigger and multiple teams to do parts of Mer-based >>>> products. >>> Yes, agree this:) >>>> >>>> * Mer is a cost-saver, it enables you to take full advantage of a >>>> mobile Linux distribution without having to maintain a big team to >>>> have it maintained for you - just share the work with others. >>> Yes, it's right:) >>>> >>>> Some might say that it not being Android is an technical advantage - >>>> but I think it's also useful to look at the disadvantages. >>>> >>>> Things that are good about Android but at same time bad for the >>>> ecosystem in general: >>>> >>>> * Low footprint due to bionic libc usage, but it makes it incompatible >>>> with much of current open source software >>> >>>> * Good hardware integration with many boards, but it makes life >>>> difficult for anyone wanting to do anything besides Android based >>>> products, as it's tied to the special libc >>> >>> Yes. Now a lot of people agree, they need something other than >>> Android, they need a good replacement for Android. >>>> >>>> .. hope that helps a bit. The good thing about Mer is that it's a >>>> quite small stack for running Linux/Qt/HTML5 on a lot of different >>>> devices. And that it allows a lot of flexibility in how you make your >>>> product(s) including how to easily save effort in development as you >>>> can use same methods and cores even if you're making a small STB or a >>>> full smartphone. >>>> >>> >>>> BR >>>> Carsten Munk >>>> >>>> >>>> >>> >>> >> >> >> > >
