Re: Not just a dpkg bug
At Wed, 17 Aug 2005 17:00:23 +0100,
Scott James Remnant wrote:
> I don't think this is just a dpkg-dev bug, these "bi-arch" systems need
> to provide ldd or an equivalent that can read either form of shared
> library that it would support.
>
> objdump isn't a solution either, while it sometimes can read the other
> shared library, it doesn't provide the linker search patch which is of
> critical importance to get this stuff right.
>
> So I'm including libc6-dev (for want of a better package) in this bug,
> as we first need ldd on these bi-arch systems (or something similar) for
> dpkg-shlibdeps to use before we can fix that!
ldd is very hard to handle 64bit binaries on 32bit systems without
breaking glibc, kernel and various technical beautiful concepts.
Please look at /usr/bin/ldd. It just passes LD_* variable to dynamic
linker. When dynamic linker is invoked from kernel elf module, it
parses LD_* environment variable and put the library path message to
stdout. So ldd is just wrapper to take notice to dynamic linker.
The actual dynamic linker path is specified in each binaries. For
example, do "strings /bin/ls |grep ld" on both i386 and amd64. You'll
find 64bit binaries designate 64bit dynamic loader that is placed in
/lib64. And, dynamic loader itself is built with "64bit code" - so we
cannot invoke even dynamic loader.
OK, now back to the discussion. The above means "we cannot use ldd to
search pathes". OTOH, Ryan suggested me to look at dpkg-shlibdeps in
dpkg-cross package as I described. It's something adhoc fix, but I
think we have no other way to support biarch nicely.
Regards,
-- gotom
Reply to: