Re: Bug#533642: dpkg-dev: dpkg-shlibdeps fails on symbols exported by libgcc_s
- To: Paul Brook <firstname.lastname@example.org>, email@example.com
- Cc: firstname.lastname@example.org, Christoph Egger <email@example.com>, firstname.lastname@example.org, email@example.com
- Subject: Re: Bug#533642: dpkg-dev: dpkg-shlibdeps fails on symbols exported by libgcc_s
- From: Raphael Hertzog <firstname.lastname@example.org>
- Date: Fri, 19 Jun 2009 22:28:41 +0200
- Message-id: <20090619202841.GH32392@rivendell>
- Mail-followup-to: Paul Brook <email@example.com>, firstname.lastname@example.org, email@example.com, Christoph Egger <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org
- In-reply-to: <email@example.com>
- References: <20090619144522.GA31568@christoph-egger.org> <20090619170627.GD32392@rivendell> <firstname.lastname@example.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
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:
> 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_".
for more examples.
Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :