I found some stuff online which I think may be possible for upgrading libc from 2.5 to (at least) 2.10 keeping ABI compatibility with rest of the system. I posted it in other thread previously, but I'm moving it in here now to gain a bit more attention and will just replace the old post with a link to this one instead. Here is the post (about libc):

Just wanted to let you know guys that I contacted Alexey Khoroshilov from ispras.ru (who seems to be responsible for at least this part of linuxtesting.org) and he brought back the link I posted earlier and reported as not anymore online. The link is http://linuxtesting.org/compatibilit...at_report.html by the way look for part libc.so.6 - it looks like there are 42 new symbols added (which should not be a problem for being compatible with existing software...?), no removed symbols (which is also good I suppose) and their software detected 8 serious problems with ABI compatibility and 25 low-severity problems. If you (or anyone else) is up to bringing libc 2.10 (or newer) to Maemo 5 providing 100% backwards ABI compatibility, these 33 (8 severe + 25 less-severe-but-still-to-be-considered) problems are to be looked at (we would need e.g. a patch to restore abi compatibility for these ones). I could make a bet that one of these problems causes e.g. Calendar application to fail Sometimes I wish I had more time for pursuing this kind of stuff :/

A bit of technical talk (I'm copying and summarizing it here if the site goes offline again in the future):

• alphasort64(...), alphasort(...), versionsort64(...) and versionsort(...): "The library function may try to access unallocated memory by the dereferencing of old parameter value and therefore cause a crash of applications." (looks like a great cause to crash, maybe simple check inside to allocate memory if it was not allocated would be enough for the beginning... and then adding something to deallocate the memory where needed to avoid memory leackages). These functions also have argument types changed from void const* to "dirent const**" or "dirent64 const**" (depending on function name) - I guess it might cause some problems...? libc 2.5 should be investigated if it accepted any other types of arguments or they were always dirent(64)s only casted to voids.
• struct printf_info has new member - affects also functions printf_size(...) and printf_size_info(...), shouldn't be much of a problem unless used externally explicitly (comment states it should be ok if only used inside libc)
• struct sockaddr_storage has changed type of one member from __uint32_t to unsigned long - isn't uint32_t typedefed as "unsigned long" on ARM? Could this be any problem anyhow (under either stock compiler or thumb upgraded gcc)? By the way, comment states it affects mainly functions getsourcefilter(...) and setsourcefilter(...).
• typedef __gnuc_va_list was changed from void* to __va_list - comment states that mainly functions _IO_vfscanf(...), obstack_vprintf(...), vasprintf(...), vdprintf(...), vfwprintf(...), vfwscanf(...), vprintf(...), vscanf(...), vswprintf(...), vswscanf(...), vsyslog(...), vwprintf(...), vwscanf(...) are affected (seems like a lot, but aren't they somehow internal for printf/scanf/syslog functions used from "outside" of libc?)
• union anon-union-wchar.h-80 has changed type of one member from wint_t to unsigned int - which I think should not be a problem as ARM has wint_t typedefed to unsigned int anyway?
• scandir(...) and scandir64(...) have one of arguments (comparator for sorting) changed - see alphasort(64) and versionsort(64) functions above, it's the same change
• splice(...), tee(...) and vmsplice(...) functions' return type was changed from int to ssize_t - I guess it shouldn't be a problem as ssize_t is typedefed as int anyway?
• inotify_rm_watch(...) has one of parameters changed from uint32_t to int - maybe it could also be a problem? Type changed from unsigned to signed...
• NCARGS value changed from ARG_MAX to 131072 - this is compiled into external applications, so, as the comment states: "Applications will pass an old value of this constant as the parameter to the new-version library functions, that expect a new one. This may result in crash of incorrect behavior of applications." - possible application killer here
• AF_MAX and PF_MAX changed value from 32 to 37. Comment states the same as for NCARGS, but is it really that bad in this case? However, it should be restored if possible... amirite?
• _POSIX2_C_BIND, _POSIX2_C_DEV, _POSIX2_LOCALEDEF and _POSIX2_SW_DEV have all value changed 200112L to 200809L (they all had the same value and now all have the same value) - maybe it causes some problems with locale (I remember there were some problems when upgrading)...? Or other problems, I don't know really

Anyway, I copied this technical stuff summary because maybe it could be useful (I hope so!) for anyone who will want to upgrade libc in Fremantle anyway (well, who wouldn't want to?! ) and it will save some time for this person. Guys from linuxtesting.org also wrote about the methodology they made these test, so one could set up the same tools and make analysis of libc-2.5 vs libc-current even and it should help with pursuing the possible ABI-incompatibilities. I'm not an author of these useful tests, guys from linuxtesting.org made them, I only found them

The first link is broken:
Fixed link here

Edit: Took the effort to save this (I think) valuable information using scrapbook firefox extension.
To view it yourself download this folder and import it in scrapbook.

Thank you mr_pingu! Copy-pasting from old post to new one seems to not always work as expected