On Thu, Apr 28, 2011 at 11:25:06AM +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. > > > > > > > shows nothing at all, and in particular no reason for the > > > > > > reassignment. > > > > > > > > > > Another data point that I gave before: 3.5.17-1 built just fine, but > > > > > 3.5.18-1 didn't. And attached here is the diff between both versions, > > > > > since you don't trust the maintainer telling you that the switch in > > > > > the > > > > > toolchain is the likely culprit. > > > > > > > > > > But, yeah, it's just easier to dismiss toolchain bugs. > > > > The R_PPC_REL24 relocations may happen to work sometimes (possibly most > > of the time). > > > > > > > > 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. > > Now, for something interesting, LD_DEBUG=all says this: > binding file ./libxul.so [0] to /usr/lib/libstartup-notification-1.so.0 [0]: > normal symbol `_restgpr_29_x' > > just before failing, and it (obviously) fails on the first of these > relocations.
Actually, it doesn't fail on the first one. libxul.so is loaded at 0x0f007000. The failure is at 0x0f9f0148, which makes the relocation for offset 0x009e9148, which makes it the 3963th. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
