Ian Campbell <ijc@hellion.org.uk> (2014-08-25): > On Sun, 2014-08-24 at 21:24 +0100, Ian Campbell wrote: > > I've timed out for now, but I'll continue prodding as I have the > > chance... > > I caught up with Adam Conrad a debconf and he pointed out that __aeabi_* > are some weird internal ABI thing which doesn't actually indicate an > unresolved symbol. IOW they should be ignored, dpkg-shlibs does this too > (search for __aeabi_ in /usr/share/perl5/Dpkg/Shlibs/SymbolFile.pm) > > Rebuilding the installer with mklibs patches as below seems to work, in > that I can "chroot tmp/network-console/tree/ /bin/sh" and then in the > chroot "/usb/sbin/sshd --help" runs and produces output. If the symbol > were actually required at runtime then this would have failed with some > sort of dynamic linker error. > > This: > # LD_TRACE_LOADED_OBJECTS=1 /lib/ld-linux-armhf.so.3 /usr/sbin/sshd > libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0xb6ddd000) > libutil.so.1 => /lib/libutil.so.1 (0xb6dcb000) > libz.so.1 => /usr/lib/libz.so.1 (0xb6da9000) > libcrypt.so.1 => /lib/libcrypt.so.1 (0xb6d6c000) > libc.so.6 => /lib/libc.so.6 (0xb6cc1000) > /lib/ld-linux-armhf.so.3 (0xb6f7c000) > libdl.so.2 => /lib/libdl.so.2 (0xb6cb0000) > > indicates that the ssh binary is indeed using those libraries which > appear to depend on the problematic symbol. > > What's not clear is why this is just occurring now. I suppose changes to > gcc/glibc or something have caused it to be exposed. I don't propose to > dig much deeper into that aspect (mostly on the basis that if > dpkg-shlibs does it mklibs should too). > > So I think we should upload a new mklibs and have a new debian-installer > upload which buidld-deps on it. Hi, and many thanks to both of you. Feel free to upload an updated mklibs and bump the build-dep in debian-installer's git. No need to upload it right away IMHO. Mraw, KiBi.
Attachment:
signature.asc
Description: Digital signature