[OE-core] [PATCH] rpm: update to 4.14.0

Mark Hatle mark.hatle at windriver.com
Mon Nov 6 16:54:11 UTC 2017


On 11/6/17 10:00 AM, Alexander Kanavin wrote:
> On 11/03/2017 07:58 PM, Mark Hatle wrote:
>>> Unfortunately, this also breaks grub and grub-efi:
>>>
>>> x86_64-poky-linux-musl-objcopy:
>>> /home/ak/development/poky/build-64/tmp/work/core2-64-poky-linux-musl/grub-efi/2.02-r0/package/usr/lib/grub/x86_64-efi/lvm.module(.debug_aranges):
>>> relocation 1 has invalid symbol index 2053731167
>>> x86_64-poky-linux-musl-objcopy:
>>> /home/ak/development/poky/build-64/tmp/work/core2-64-poky-linux-musl/grub-efi/2.02-r0/package/usr/lib/grub/x86_64-efi/lvm.module:
>>> invalid relocation type 69
>>> x86_64-poky-linux-musl-objcopy: BFD (GNU Binutils) 2.29.0.20170912
>>> assertion fail ../../bfd/elf64-x86-64.c:351
>>> x86_64-poky-linux-musl-objcopy:
>>> /home/ak/development/poky/build-64/tmp/work/core2-64-poky-linux-musl/grub-efi/2.02-r0/package/usr/lib/grub/x86_64-efi/lvm.module(.debug_info):
>>> relocation 0 has invalid symbol index 1634754402
>>>
>>
>> Look at debugedit.  This is the program used to adjust some of the debug references.
> 
> Thanks, this is the offending commit:
> 
> https://github.com/rpm-software-management/rpm/commit/88989572fff1f31e0c4f972a6895585e4742ef4b
> 
> Looks like they added sophisticated in-place processing/rewriting of the 
> actual binary (that is not possible to switch off). And it fails in case 
> of grub modules.
> 
> We, on the other hand, only need to extract the list of debug source 
> code files. Any hint on how to do that without the use of rpm/debugedit? 
> Perhaps something from binutils/elfutils?

You would need to interpret the dwarf symbols and find all of the referenced
files.  I can certainly be done with the libelf (libdwarf?), but I don't know if
it can be done with binutils or elfutils directly.  They may not have the
necessary translation to be able to assembly the pieces.

(A lot of the filenames are listed related to a directory.. and the entries are
stored in different places and have to be assembled to get a similar output to
what debugedit gave us.)

Writing a small standalone tool to give us this information may be very useful
to us though -- and would let us break the 'rpm' dependency for deb/ipkg
builds.. (probably)

--Mark

> Alex
> 




More information about the Openembedded-core mailing list