Re: Bug#533642: dpkg-dev: dpkg-shlibdeps fails on symbols exported by libgcc_s
Paul Brook schrieb:
>> Now it seems that the irrlicht library depends on those symbols
>> provided by libgcc_s.so.1 (and does not define them locally contrary to
>> what was seen by Aurélien in libvorbis in #462318) and of course
>> dpkg-shlibdeps complains because they can't be found in the symbols file.
>> ...
>> So should I revert the blacklist entirely? Or should I revert the
>> blacklist partially? In that case, which symbols must be blacklisted?
>
> Under normal curcumstances, I'd expect every shared library and application to
> require __aeabi_* from libgcc. Under normal circumstances these will come from
> libgcc_s.so, but if you link with --static-libgcc then you'll get your own
> copy.
these are not defined in libgcc_s.so, but only in libgcc.a. So when building a
shared library, you should link with both -lgcc_s and -lgcc (which current
libtool doesn't seem to support). I didn't get any feedback on what should be
the correct way to link libraries on armel. there are open reports PR40133 (the
report where I did see the problem first) and PR40134 (no feedback yet). The SH
port does use a linker script to link with both -lgcc_s and -lgcc.
Matthias
> These symbols are defined by the EABI and the runtime must supply in some
> form. The EABI is deliberately vague about exactly where/how, but on Linux it
> is normal for these for come from libgcc. However use of these functions is
> entirely optional, hence building them into your library instead of using
> libgcc_s.so is ok (though obviously has the same undesirable consequences as
> any sort of static library).
>
> I'm afraid I have no clue how dpkg-shlibdeps works, so can't really guess what
> the right answer to your blacklist question is.
>
> Paul
>
>
Reply to: