On Don, 2011-04-28 at 12:04 +0200, Mike Hommey wrote: > On Thu, Apr 28, 2011 at 12:01:04PM +0200, Michel Dänzer wrote: > > On Don, 2011-04-28 at 11:55 +0200, Mike Hommey wrote: > > > On Thu, Apr 28, 2011 at 11:40:48AM +0200, Mike Hommey wrote: > > > > On Thu, Apr 28, 2011 at 11:32:16AM +0200, Mike Hommey wrote: > > > > > > 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. > > > > > > > > (easier to find the relocation when you have the base of the library in > > > > memory, really odd alignment, by the way) > > > > > > > > All in all, it looks to me like it used to work by mere luck, but > > > > somehow now fails because the lib containing the _restgpr_29_x symbol > > > > is too far, which libgcc_s.so would likely be as well. So using a > > > > R_PPC_REL24 relocation for these undefined symbols looks like a big > > > > stretch. > > > > > > FWIW, taking a look at where these relocations take place show that the > > > corresponding symbols (from the -dbg package) are in functions coming > > > from objects that *are* built -fPIC. > > > > > > It also happens that, in libnss3-1d, the libcrmf.a file contains the > > > same kind of relocations, and all the files built in that lib *are* > > > built -fPIC. That would help having a smaller testcase than iceweasel. > > > > If libcrmf.a ends up being linked into libxul.so, that would be the > > static library I asked about, and the bug. > > Let me write it again: > - The R_PPC_REL24 relocations are all over libxul.so on objects that are > built -fPIC. > - libcrmf.a is also linked into libxul.so, and it also contains > R_PPC_REL24 relocations, but all the objects it contains are built > -fPIC.
I asked about linking static libraries into shared objects because that *cannot work* in general. If there are still other R_PPC_REL24 relocations in libxul.so after you've fixed that, please provide more details about those. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
