| |||||||||||||
|
| |||||||||||||
Welte: Android Mythbusters (Matt Porter)Welte: Android Mythbusters (Matt Porter)Posted Nov 5, 2009 18:19 UTC (Thu) by nix (subscriber, #2304)In reply to: Welte: Android Mythbusters (Matt Porter) by jgg Parent article: Welte: Android Mythbusters (Matt Porter)
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.
(Log in to post comments)
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.
|
|
||||||||||||