On Fri, 2014-08-22 at 05:26 +0200, Cyril Brulebois wrote:
> Ian Campbell <i...@hellion.org.uk> (2014-08-22):
> > The Internet(tm) seems to think that __aeabi_unwind_cpp_pr0 comes from
> > libunwind, but the wifi in this hotel is making it a rather slow job
> > to figure out what might be depending on that and/or whether there
> > is/should be a udeb for it, I'll try and investigate further though.
> >
> > Interesting that only the network-console flavour is affected....
>
> Comparing netboot and network-console builds before the library
> reduction phase leads to an interesting diff, which I'm not attaching
> because I think that's not really needed, see below.
>
>
> (BTW: There's a similar symbol in the kernel but I'm going to assume the
> *.ko diff is totally irrelevant to the problem in mklibs…)
Yes, I'm sure it is irrelevant.
> Letting netboot go through, and grepping for that symbol, there's no
> match in the resulting tree; on the contrary, network-console still gets
> some:
> | Binary file tmp/network-console/tree/lib/libcrypt.so.1-so-stripped matches
> | Binary file tmp/network-console/tree/lib/libcrypt.so.1-so matches
> | Binary file tmp/network-console/tree/lib/libc.so.6-so matches
>
> Interestingly, grepping for libcrypt.so in netboot shows no match, while
> network-console has:
> | Binary file tmp/network-console/tree/bin/gen-crypt matches
> | Binary file tmp/network-console/tree/lib/libcrypt.so.1-so-stripped matches
> | Binary file tmp/network-console/tree/lib/libcrypt.so.1-so matches
> | Binary file tmp/network-console/tree/usr/sbin/sshd matches
>
> See? Both gen-crypt and sshd are only in the network-console image, and
> apparently pulling libcrypt.so.1, which comes from libc:
> | libc6:armhf: /lib/arm-linux-gnueabihf/libcrypt.so.1
>
> Also in the tree, nm -D shows that this libcrypt.so.1-so* have:
> | U __aeabi_unwind_cpp_pr0
> which is likely what mklibs barfs about.
>
>
> Bottom line: FTBFS vs. non-FTBFS depending on image type is likely
> explained by the differences in binaries included in each image;
Agreed.
> and
> that FTBFS was likely introduced by a toolchain update which mklibs
> doesn't exactly cope nicely with, yet.
Possibly. One thing I'm confused about is that the symbol is apparently
provided by libgcc_s.so.1 but that doesn't appears under
tmp/network-console/ anywhere. But surely some other symbols from
libgcc_s must be being used already.
Running mklibs by hand in verbose mode AFAICT it is never even
considering libgcc_s.so.1.
Copying /lib/arm-linux-gnueabihf/libgcc_s.so.1 to
tmp/network-console/tree/lib/ (which I'm sure is quite wrong...) doesn't
work but it does cause mklibs to spit out some interesting debug:
needed_symbols adding __aeabi_unwind_cpp_pr0, weak: False
[...]
present_symbols adding __aeabi_unwind_cpp_pr0@GCC_3.5@libgcc_s.so.1
[...]
Exception: No library provides non-weak __aeabi_unwind_cpp_pr0
(the middle line is from calling mklibs-readelf
--print-symbols-provided ./tmp/network-console/tree/lib/libgcc_s.so.1)
Which made me wonder if the issue might be to do with symbol versioning
somehow?
> For the record, I'm listing below where the symbol is referenced (T in
> libgcc_s.so.1, U elsewhere).
Was it deliberate that this referenced the host (/lib etc) rather than
the build tree?
I've timed out for now, but I'll continue prodding as I have the
chance...
Ian.
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1408911872.30706.31.ca...@hellion.org.uk
