qemu-native build regularly failing

qemu-native build regularly failing

[Marko Lindqvist]

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.


 - ML

Re: qemu-native build regularly failing

[Paul Eggleton]

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?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: qemu-native build regularly failing

[Marko Lindqvist]

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.


 - ML

Re: qemu-native build regularly failing

[Paul Eggleton]

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

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: qemu-native build regularly failing

[Otavio Salvador]

On Tue, Aug 20, 2013 at 6:16 PM, 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?

This floating dependency is  a problem; could it be patches to be x11
/ x11-less?


-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: qemu-native build regularly failing

[Paul Eggleton]

On Tuesday 20 August 2013 18:24:55 Otavio Salvador wrote:
> On Tue, Aug 20, 2013 at 6:16 PM, 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?
>
> This floating dependency is  a problem; could it be patches to be x11
> / x11-less?

How would you propose to handle both use-cases?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: qemu-native build regularly failing

[Marko Lindqvist]

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.


 - ML

Re: qemu-native build regularly failing

[Marko Lindqvist]

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.


 - ML

Re: qemu-native build regularly failing

[Marko Lindqvist]

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.


 - ML

Re: qemu-native build regularly failing

[Paul Eggleton]

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...

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: qemu-native build regularly failing

[Saul Wold]

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
>

Re: qemu-native build regularly failing

[Marko Lindqvist]

On 22 August 2013 17:27, Saul Wold <sgw@linux.intel.com> wrote:
> 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?

 That issue has been bothering me on Debian Testing/Jessie.

>  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.

libX11:
Version: 2:1.6.1-1

>
> Check out the patches.
>
> Sau!
>
>> Cheers,
>> Paul
>>


 - ML