Re: Bug#533642: dpkg-dev: dpkg-shlibdeps fails on symbols exported by libgcc_s

[Raphael Hertzog <hertzog@debian.org>]

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/