Re: Bug#533642: dpkg-dev: dpkg-shlibdeps fails on symbols exported by libgcc_s
On Fri, 19 Jun 2009, Christoph Egger wrote:
> Building the NEW package I'm working on (irrlicht [3]) on my
> ARM(el)[4] box (up-to-date sid pbuilder) causes dpkg-shlibdeps to
> complain about missing symbols [0]. These symbols seem to be some gcc
> internals that should be covered by libgcc_s.so which is reported as
> unused.
Ok, this is getting tricky.
In http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=462318 Aurélien Jarno
requested all __aeabi_* symbols to be blacklisted as they were supposed
to be internal symbols created by gcc that should not be exported to
symbols files.
As a result of this, libgcc1.symbols does not list all those symbols
even though they are properly exported by the library.
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?
For reference the symbols blacklisted are:
# Many armel-specific symbols
$blacklist{"__aeabi_$_"} = 1 foreach (qw(cdcmpeq cdcmple cdrcmple cfcmpeq
cfcmple cfrcmple d2f d2iz d2lz d2uiz d2ulz dadd dcmpeq dcmpge dcmpgt
dcmple dcmplt dcmpun ddiv dmul dneg drsub dsub f2d f2iz f2lz f2uiz f2ulz
fadd fcmpeq fcmpge fcmpgt fcmple fcmplt fcmpun fdiv fmul fneg frsub fsub
i2d i2f idiv idivmod l2d l2f lasr lcmp ldivmod llsl llsr lmul ui2d ui2f
uidiv uidivmod ul2d ul2f ulcmp uldivmod unwind_cpp_pr0 unwind_cpp_pr1
unwind_cpp_pr2 uread4 uread8 uwrite4 uwrite8));
I'm not familiar at all with the armel toolchain so I need assistance
here. That's why I put porters, gcc maintainers and -devel in copy.
Did something change in the toolchain so that binaries start using the
libgcc_s version of those symbols instead of duplicating them in every
binary ?
There's a slight chance that the problem lies in the build options
used by irrlicht but I am unable to verify this possibility. People that
would like to verify this can grab the source package here:
> [3] git://git.debian.org/git/pkg-games/irrlicht.git
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/
Reply to: