Re: Processed: Re: Bug#624354: ./xpcshell: error while loading shared libraries: ./libxul.so: R_PPC_REL24 relocation at 0x0f9f0148 for symbol `_restgpr_29_x' out of range
On Thu, Apr 28, 2011 at 11:43:12AM +0200, Michel Dänzer wrote:
> On Don, 2011-04-28 at 11:25 +0200, Mike Hommey wrote:
> > On Thu, Apr 28, 2011 at 11:17:34AM +0200, Michel Dänzer wrote:
> > > On Don, 2011-04-28 at 10:45 +0200, Mike Hommey wrote:
> > > > On Thu, Apr 28, 2011 at 10:15:00AM +0200, Mike Hommey wrote:
> > > > > On Thu, Apr 28, 2011 at 10:06:01AM +0200, Mike Hommey wrote:
> > > > > > On Thu, Apr 28, 2011 at 10:00:09AM +0200, Matthias Klose wrote:
> > > > > > > On 04/28/2011 09:57 AM, Mike Hommey wrote:
> > > > > > > >Take the build log, remove all lines without -fPIC, you'll only get
> > > > > > > >lines for building binaries and objects that aren't linked into
> > > > > > > >libxul.so. QED.
> > >
> > > No possibility of e.g. a static library being linked into a shared
> > > object?
> >
> > None from the iceweasel source, at least.
>
> I think so far the most likely origin of the R_PPC_REL24 relocations
> seems libgcc.a. Matthias, do you concur? If so, any ideas what the
> iceweasel build might be doing wrong? Or otherwise, any ideas for
> isolating where they're coming from?
See my other message.
> > > > > I'll also add that the symbol for which the relocation is failing,
> > > > > _restgpr_29_x, comes from gcc, in gcc/config/rs6000/crtresxgpr.asm.
> > > > > But you're right, it's most probably not a toolchain problem.
> > > >
> > > > Even better, if I download xulrunner-1.9.1_1.9.1.18-1_powerpc.deb and
> > > > take a look at the relocations in libxul.so, I can't even find the
> > > > relocation ld.so is complaining about.
> > >
> > > How did you look?
> > >
> > > daenzer@thor|11:11:06> objdump -R /usr/lib/xulrunner-1.9.1/libxul.so|grep R_PPC_REL24
> > > 0033faa0 R_PPC_REL24 _restgpr_29_x
> > > 0033fdc0 R_PPC_REL24 _restgpr_29_x
> > > 0033fea0 R_PPC_REL24 _restgpr_29_x
> > > [...]
> > >
> > > 47132 hits.
> >
> > And none of the offsets match the end of the relocation address ld.so is
> > talking about.
>
> Not sure that matters at all. A R_PPC_REL24 relocation in a shared
> object is a bug.
>
>
> P.S. /usr/lib/xulrunner-2.0/libxul.so seems contaminated as well.
... but somehow worked during the test suite.
Mike
Reply to: