thank you, carsten, i think i have got a lot of information from replies of this email subject:) 在 2012-1-26 下午2:28，"Carsten Munk" <[email protected]>写道：
> 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 > >>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > > > > > > >
