I looked at some android stuff too for a bit, I was interested if their prelink could be used for PPC without a huge problem. Didn't seem like it. Not only was it quite ARM specific but it was tied into how their libc worked.. Ended up using normal prelink and some haxoring for cross compiling..
I've done a lot of embedded stuff too and I don't use udev or HAL or really much of the Linux user space beyond a few core libraries glibc, openssl, etc. So it is hard to fault Android for that.
But chucking glibc and replacing it with something so vastly inferior is not going to work for a lot of people. For instance last I looked there is no IPv6 support at all in their libc.
Basically, it seems a great way to run some kinds of Java apps on a ARM, and some phone specific brickabrack surrounding that but it isn't going to take the embedded Linux world by storm any time soon.
Posted Nov 5, 2009 18:19 UTC (Thu) by nix (subscriber, #2304)
[Link]
Er, *every* prelink implementation is tied to a libc (or at least to the
dynamic linker). It has to be, because ld.so has to know 'this has been
prelinked, the prelinking isn't out of date, do not relocate this'. A
prelinker that didn't affect the behaviour of the dynamic linker would be
useless.
Welte: Android Mythbusters (Matt Porter)
Posted Nov 5, 2009 23:43 UTC (Thu) by jgg (guest, #55211)
[Link]
Sort of - the bulk of prelinking work is entirely fixed - you apply the relocations in advance the way the ELF standard says. Knowing that the relocations are OK is what .gnu.liblist does and I can't see how that isn't entirely sufficient for pretty much any prelinking implementation.
The main thing that could vary is the symbol resolution order, there are pretty good ELF standard conventions for this but glibc has some unique behavior in some corner cases. Overall not a big issue.
The android prelinker is one of a kind, cross-compile prelinking is something almost every embedded dev would be interested in, IMHO.