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 > > -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
