[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#624354: 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 Mit, 2011-08-31 at 07:35 +0200, Mike Hommey wrote: 
> On Wed, Aug 31, 2011 at 07:26:10AM +0200, Mike Hommey wrote:
> > On Wed, Aug 31, 2011 at 07:05:04AM +0200, Mike Hommey wrote:
> > > On Wed, Aug 31, 2011 at 06:35:09AM +0200, Mike Hommey wrote:
> > > > Interestingly, according to bug #639851, 6.0-2 didn't have the problem.
> > > > Which suggests something else broke.
> > > 
> > > Actually, it must have worked by luck in 6.0-2 for that user, because
> > > the binary is affected the same way.

Yeah, 6.0-2 also worked for me originally, but it no longer did after
downgrading to it from 6.0-4.

Again, R_PPC_REL24 relocations in shared objects are ticking time bombs,
which may happen to work most of the time... but they're always a bug.


> > > So, it would be interesting to find what particular library is exporting
> > > the _rest* symbols this time, since libstartup-notification doesn't
> > > anymore.
> > 
> > And the winner is libevent.
> 
> iceweasel built against 1.4.13-stable-1 which was built a long time ago,
> like libstartup-notification had, and 1.4.14b-stable-1 currently in
> unstable doesn't export the symbols. Same conclusion as with
> libstartup-notification: old toolchain bug.
> 
> Still, I think it's wrong that a random library can highjack symbols
> that gcc uses to call its own stuff from libgcc. Are there actual
> legitimate uses of that "feature"?

I don't know, and I agree this seems like a toolchain bug. But why not
build with -O2 and stay out of the mess?


-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer



Reply to: