On Fri, Feb 07, 2003 at 07:32:46AM -0600, Stephen R Marenka wrote: Hi,
> 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 in binutils. 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... -Michael > 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
