Re: binutils error? (autobuilder failure)
On Fri, Feb 07, 2003 at 07:32:46AM -0600, Stephen R Marenka wrote:
> I've started seeing the following error on a number of builds, on two
> different machines now.
> | dh_shlibdeps
> | objdump: error while loading shared libraries: unexpected PLT reloc type 0x00
> | dpkg-shlibdeps: failure: objdump on `debian/tmp/usr/bin/fbi' gave error exit status 127
> | dh_shlibdeps: command returned error code 32512
> It looks like a problem in binutils. Anyone else seen this? Do we need
> to push for the patch (see below) in glibc?
Are you sure that this would really fix anything? dpkg-shlibdeps uses
objdump these days, not ldd, so I expect that this will need to be fixed
Btw. I was going to take a quick look at this, but I can't seem to get
into the unstable chroot on crest. I thought those were supposed to be
public? Or maybe I just haven't found the right command...
> On Wed, Feb 05, 2003 at 12:28:20PM +0100, Richard Zidlicky wrote:
> > On Wed, Feb 05, 2003 at 09:06:42AM +0100, Rene Engelhard wrote:
> > >
> > > Hi,
> > >
> > > [ please Cc: me, as I am not subscribed to -68k ]
> > >
> > > anyone of you know what causes the follwing build failure and what to do?
> > > Versions till -3 built successfully; but binutils got updated
> > > recently...
> > >
> > > http://buildd.debian.org/fetch.php?&pkg=firestarter&ver=0.9.1-4&arch=m68k&stamp=1044431895&file=log&as=raw
> > known problem in binutils. Temporary workaround is to patch glibc
> > like this:
> > --- glibc-2.2.90/sysdeps/m68k/dl-machine.h.rz Mon Aug 26 11:44:44 2002
> > +++ glibc-2.2.90/sysdeps/m68k/dl-machine.h Mon Aug 26 11:45:31 2002
> > @@ -311,6 +311,8 @@
> > Elf32_Addr *const reloc_addr = (void *) (l_addr + reloc->r_offset);
> > if (ELF32_R_TYPE (reloc->r_info) == R_68K_JMP_SLOT)
> > *reloc_addr += l_addr;
> > + else if (ELF32_R_TYPE (reloc->r_info) == R_68K_NONE)
> > + return;
> > else
> > _dl_reloc_bad_type (map, ELF32_R_TYPE (reloc->r_info), 1);
> > }
> > No idea if it is fixed or going to be fixed in some newer binutils.
> > The inefficiency introduced by this patch is minimal so it won´t
> > hurt if it stays in glibc for a while.
> > Richard