Hi,
ext Cornelius Hald wrote:
The main objective behind the MeeGo compliance is to guarantee
binary compatibility for applications across
multiple MeeGo products. All the rest (definition of the official MeeGo
API, architecture...) is a consequence of this basic goal.
Are you sure about _binary_ compatibility?
That's a good question as there are so many places where it can break.
Like ARM vs. x86.
Or even just ARMv7 or some earlier thing (or even ARMv7 device without
NEON support).
Or GCC upgrade which isn't ABI compatible for C++
(as has happened quite often in the past).
Or ARMv7 with soft-fp ABI (like Fremantle) or ARMv7 with hard-fp ABI
(like Harmattan).
And what about debuggability of optimized code? For example having
frame pointers vs. frame unwiding (I've understood MeeGo is going for
latter).
Then there's the packaging angle to consider. If something is compiled
against newer libraries, the resulting package is normally going to have
a dependency to these newer versions of the libraries and cannot be
installed to release or device with older libraries although their ABI
subset would be compatible to the new versions.
(At least current Maemo doesn't provide function level versioning
information for all the libraries, only library level versioning.)
- Eero
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
