clone 533642 -1
reassign -1 libgcc1 1:4.4.0-7
retitle -1 Ensure __aeabi_* symbols are listed in libgcc1.symbols for armel
severity -1 important
thanks
On Sat, 20 Jun 2009, Raphael Hertzog wrote:
> I think that to properly resolve my issue I have to allow you to export
> those blacklisted symbols i
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 ow
Paul Brook schrieb:
>> 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 symbol
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
>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 r
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
6 matches
Mail list logo
