[meta-virtualization] [PATCH 1/4] vgabios : extract biossums tool and build it separately, native

[Christopher Clark]

On Wed, Aug 23, 2017 at 5:54 AM, Bruce Ashfield
<bruce.ashfield at gmail.com> wrote:
>
>
> On Wed, Aug 23, 2017 at 2:43 AM, Christopher Clark
> <christopher.w.clark at gmail.com> wrote:
>>
>> On Tue, Aug 22, 2017 at 7:42 PM, Bruce Ashfield
>> <bruce.ashfield at gmail.com> wrote:
>> > On Tue, Aug 22, 2017 at 1:08 AM, <christopher.w.clark at gmail.com> wrote:
>> >> From: Christopher Clark <christopher.clark6 at baesystems.com>
>> >>
>> >> The biossums tool is used to generate the vgabios build product.
>> >>
>> >> This patch:
>> >> * adds a separate recipe "biossums" for the tool
>> >> * makes the vgabios recipe depend upon biossums-native
>> >> * makes the vgabios recipe use the native binary rather than a locally
>> >> built one

>> >> +
>> >> +do_compile() {
>> >> +    oe_runmake clean
>> >
>> >
>> > What actually happens if the clean isn't run before each compile ?
>>
>> It's a good question. Here's where I see different behaviour with and
>> without that clean:
>>
>> bitbake -c cleansstate vgabios biossums-native
>> bitbake vgabios
>>
>> With the clean present, building vgabios will trigger biossums-native
>> to be built to satisfy the dependency, and vgabios's compile will
>> succeed. Without the clean present, biossums-native does get its build
>> triggered, but the vgabios build fails with:
>>
>> "make: execvp: biossums: Accessing a corrupted shared library"
>
>
>
> Interesting. So it sounds like whatever is installed from biossums-native in
> a
> previous build is checked for .. something ... and declared invalid on a
> subsequent run.
>
> .. but since the clean is before the make of biosums-native, I'm at a loss
> to
> understand why on a later build of vgabios it makes a difference. Is it some
> sort of host vs target issue ?

I think yes, something like that is going on, but I don't have a
precise answer yet.

> When that error happens, and you look in the native sysroot, what does
> the .so look like ? What does file say about it ?

It's probably helpful to know that I do not have the 32-bit
compatibility libraries installed on this debian build VM, which I
think is ensuring that things that should break are breaking.

Without the clean:

user at build-vm:tmp$ file
sysroots-components/x86_64/biossums-native/usr/bin/biossums
sysroots-components/x86_64/biossums-native/usr/bin/biossums: ELF
32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically
linked, interpreter
/mnt/build/master/poky/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2,
for GNU/Linux 2.6.4, stripped

user at build-vm:tmp$ ldd
sysroots-components/x86_64/biossums-native/usr/bin/biossums
    not a dynamic executable


With the clean:

user at build-vm:tmp$ file
sysroots-components/x86_64/biossums-native/usr/bin/biossums
sysroots-components/x86_64/biossums-native/usr/bin/biossums: ELF
64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked,
interpreter /mnt/build/master/poky/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2,
for GNU/Linux 2.6.32,
BuildID[sha1]=e47d34032f342f20532a91d95208534e080cdc73, stripped

user at build-vm:tmp$ ldd
sysroots-components/x86_64/biossums-native/usr/bin/biossums
    linux-vdso.so.1 (0x00007fff383ed000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f673ecd5000)
    /mnt/build/master/poky/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2
=> /lib64/ld-linux-x86-64.so.2 (0x00005588ab4c3000)


Just for completeness, I also get these same results directing bitbake
to build biossums-native directly, rather than inferring it from
vgabios's dependencies, with this:
bitbake -c cleansstate vgabios biossums-native && bitbake biossums-native