Re: qemu-native build regularly failing

[Saul Wold <sgw@linux.intel.com>]

On 08/22/2013 06:03 AM, Paul Eggleton wrote:
> On Thursday 22 August 2013 15:56:39 Marko Lindqvist wrote:
>> On 21 August 2013 19:33, Marko Lindqvist <cazfi74@gmail.com> wrote:
>>> On 21 August 2013 01:15, Marko Lindqvist <cazfi74@gmail.com> wrote:
>>>> On 21 August 2013 00:16, Paul Eggleton <paul.eggleton@linux.intel.com>
> wrote:
>>>>> On Tuesday 20 August 2013 23:26:44 Marko Lindqvist wrote:
>>>>>> On 20 August 2013 16:32, Paul Eggleton <paul.eggleton@linux.intel.com>
>>>>>>
>>>>>> wrote:
>>>>>>> On Tuesday 20 August 2013 15:51:21 Marko Lindqvist wrote:
>>>>>>>> Build of qemu-native regularly fails with:
>>>>>>>> |   LINK  sh4-softmmu/qemu-system-sh4
>>>>>>>> |
>>>>>>>> | /usr/lib/x86_64-linux-gnu/libXext.so.6: undefined reference to
>>>>>>>>
>>>>>>>> `_XEatDataWords'
>>>>>>>>
>>>>>>>> | collect2: error: ld returned 1 exit status
>>>>>>>>
>>>>>>>> This might be some dependency missing, as building first some
>>>>>>>> packets
>>>>>>>> (+ more importantly their dependencies) that do not depend on qemu
>>>>>>>> and
>>>>>>>> only then qemu dependant image success.
>>>>>>>
>>>>>>> Do you have something else causing libxext-native to be built by any
>>>>>>> chance?
>>>>>>
>>>>>>   Yes, it seems to be difference between the tree where build fails and
>>>>>>
>>>>>> the one where build success that former has no libxext-native built.
>>>>>> Further, I tested just building libxext-native before building
>>>>>> qemu-native, and then the build succeded.
>>>>>
>>>>> The problem is we want qemu-native to be buildable both on systems
>>>>> without X11 and systems with X11, so the dependency has to be floating,
>>>>> and this is more or less acceptable for a native recipe - there's only
>>>>> a problem when libxext- native needs to be built. I can't see a lot of
>>>>> value in building libxext- native in any case - what is causing it to
>>>>> be built on your system?
>>>>>
>>>>> Cheers,
>>>>> Paul
>>>>>
>>>>   I'm still running more tests - this seems to be complicated matter.
>>>>
>>>> For one, I just got successful build from empty tree by building
>>>> qemu-native directly. That was build targeted to arm, while failing
>>>> builds have been for x86 (native is amd64). Also, I think (but cannot
>>>> be 100% sure any more) build has succeeded on trees where nothing
>>>> depends on libxext-native but still *something* was needed to be built
>>>> before qemu-native.
>>>>
>>>   It seems libxext-native is not needed. Rather this seems like problem
>>>
>>> with build parallelism.
>>>
>>>   - Sometimes "bitbake qemu-native" to empty tree success at once
>>>   - When it first fails (but other tasks get executed while it tries to
>>>
>>> build), it then success by forcing configure rerun & building  (
>>> "bitbake qemu-native -c configure -f && bitbake qemu-native" )
>>>
>>>   I think next step is to get config.log of the succesful and failed
>>>
>>> build to compare.
>>
>> --- success-qemu/qemu-1.5.0/config-host.h       2013-08-22
>> 15:45:10.323126880 +0300
>> +++ failed-qemu/qemu-1.5.0/config-host.h        2013-08-22
>> 15:32:23.515101072 +0300
>> @@ -26,6 +26,7 @@
>>   #define CONFIG_UUID 1
>>   #define QEMU_VERSION "1.5.0"
>>   #define QEMU_PKGVERSION ""
>> +#define CONFIG_SDL 1
>>   #define CONFIG_CURSES 1
>>   #define CONFIG_ATFILE 1
>>   #define CONFIG_UTIMENSAT 1
>> @@ -55,6 +56,7 @@
>>   #define CONFIG_MADVISE 1
>>   #define CONFIG_POSIX_MADVISE 1
>>   #define CONFIG_SIGEV_THREAD_ID 1
>> +#define CONFIG_GLX 1
>>   #define CONFIG_UNAME_RELEASE ""
>>   #define CONFIG_ZERO_MALLOC 1
>>   #define CONFIG_QOM_CAST_DEBUG 1
>>
>>
>> As this diff is success -> failed, CONFIG_GLX and CONFIG_SDL are
>> defined on first build ending to failure, but not on forced
>> reconfigure that then build succesfully.
>
> You'd probably need to dig into the actual configure check that enables these
> automatically. I was about to suggest maybe libsdl-native was present in the
> failing case, but then the current libsdl recipe in OE-Core doesn't provide
> libsdl-native so that probably isn't it...
>
Something that we did not ask here, is what is your host OS?  We just 
had a very similar issue Fedora 19, since qemu had a floating dependency 
on some X libraries specifically libX11 and libXext and X11 is newer on 
F19, it was causing problems if you happen to have libX11-native built. 
  We just updated libX11 and in our testing it seems to have fix this issue.

Check out the patches.

Sau!

> Cheers,
> Paul
>