[OE-core] 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 at gmail.com> wrote:
> > On 21 August 2013 01:15, Marko Lindqvist <cazfi74 at gmail.com> wrote:
> >> On 21 August 2013 00:16, Paul Eggleton <paul.eggleton at 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 at 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