On Fri, 19 Jun 2009, Paul Brook wrote: > >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.
Well, it's been some time since armel started and it's the first time I see that people complain about this problem. So it's probably not that frequent that binaries depend on those symbols (or very few people notice dpkg-shlibdeps warnings in armel build logs). > 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). Why do so many library embed them by default? I would have expected that to be the exception. On armel a quick grep on symbols files shows that the following packages have some of those symbols embedded: heartbeat kexi libannodex0 libavcodec1d libavutil1d libbigloo2.8c libchicken0 libcob1 libflac8 libgavl0 libgraphicsmagick1 libgs8 libhamlib2 libhdf5-lam-1.6.5-0 libhdf5-mpich-1.6.5-0 libhdf5-serial-1.6.5-0 libinsighttoolkit3.4 libjack0 libldb0 liblo0ldbl liblo0 libmagick9 libmpcdec3 libmpeg3-1 libmysqlclient15off libparted1.7-1.symbols libpostproc1d libpulsecore5 libqof1 libruby1.8 libruby1.9 libsefs1 libsilc-1.1-2 libsofia-sip-ua0 libtokyocabinet2 libtrace3 libvips12 ntop showimg > 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. The only role of this blacklist is to not pollute symbols files with symbols that are only internal to the toolchain (and that are not used by external binaries). The idea was that those symbols were not used like traditional libraries and were only needed by the code generated by gcc (i.e. some sort of local lookup and not over an external lib). In this list you have symbols like "__bss_end__", "_GLOBAL_OFFSET_TABLE_". See http://git.debian.org/?p=dpkg/dpkg.git;a=blob;f=scripts/Dpkg/Shlibs/SymbolFile.pm;hb=master for more examples. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
