Re: Bug#758581: debian-installer: FTBFS on armhf/network-console: No library provides non-weak __aeabi_unwind_cpp_pr0

[Ian Campbell <ijc@hellion.org.uk>]

On Fri, 2014-08-22 at 05:26 +0200, Cyril Brulebois wrote:
> Ian Campbell <ijc@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.