On Apr 16, 2011, at 1:57 PM, Jeff Johnson wrote: > > On Apr 16, 2011, at 1:49 PM, Per Øyvind Karlsen wrote: > >>> >> No, for uClibc there's a complete toolchain for it living under >> /usr/uclibc, which >> has it's own elf interpreter > > There's the answer: > A dependency on a separate interpreter (presumably > you mean loader) is needed. > and stop with this uClibC(...) namespace fiction through symlinks. > >
Is adding a dependency on the uClibc ELF interpreter
an acceptable engineeering decision or not?
In fact RPM used to separately track the ELF interpreteras wll
as SONAMES through package dependency assertions.
Because linux users perceived
Requires: /lib/ld-linux.ao.2
present in ELF headers like this:
$ readelf -a /bin/ls
...
INTERP 0x000154 0x08048154 0x08048154 0x00013 0x00013 R 0x1
[Requesting program interpreter: /lib/ld-linux.so.2]
as "bloat" (because Requires: libc.so.6 implies the other dependency),
the dependency was actually removed.
But there most definitely is a clear semantic need for the EFL
interpreter/loader
that SHOULD be tracked in dependency assertions if/when there are multiple ELF
interpreters present.
hth
73 de Jeff
smime.p7s
Description: S/MIME cryptographic signature
