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

[Raphael Hertzog <hertzog@debian.org>]

On Sat, 20 Jun 2009, Matthias Klose wrote:
> > 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.

No, they do exist in libgcc_s.so as shown by the objdump output sent:
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=15;filename=lib_libgcc_so_1;att=2;bug=533642

> 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.

Direct URLs:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40133
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40134

I think that to properly resolve my issue I have to allow you to export
those blacklisted symbols in the libgcc1.symbols file. I'll cook up
something to that effect but it will require a newer dpkg where symbols
can be individually tagged with special instructions.

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/