Re: [PATCH 0/5] automake-1.13 and upstream version updates

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

On 02/25/2013 03:40 AM, Marko Lindqvist wrote:
> On 20 February 2013 16:32, Marko Lindqvist <cazfi74@gmail.com> wrote:
>> On 19 February 2013 19:12, Saul Wold <sgw@linux.intel.com> wrote:
>>> On 02/17/2013 01:00 AM, Marko Lindqvist wrote:
>>>>     libffi: update to upstream version 3.0.12
>>>
>>> Not sure what's going on but I saw a batch of failures with glib-2.0, take a
>>> look at the autobuilder failure:
>>>
>>> http://autobuilder.yoctoproject.org:8010/builders/nightly-ppc/builds/808/steps/shell_29/logs/stdio
>>>
>>>   or
>>>
>>> http://autobuilder.yoctoproject.org:8010/builders/nightly-x86/builds/931/steps/shell_29/logs/stdio
>>>
>>> Not sure why, but glib-2.0 is not finding the libffi library, but it seems
>>> to exist in the sysroot.
>>
>>   I should be able to take a brief look next weekend, but tonight and
>> tomorrow I'm busy with other things.
>
>   I've found no way to reproduce this on my own computer no matter how
> I've tried to invalidate parts of the cache etc. but I wonder if it
> could be that for some reason libffi didn't exist in sysroot already
> at the time it was needed, only later when you checked for it. I see
> no problem with glib-2.0-native dependencies, though.
>
I found a way to reproduce it and fix it, I believe!

Just curious, what's your build host arch?  and what does gcc 
-print-multi-os-directory return on your host?

It returns lib64 on my host and it causes the libs to be installed in 
the <WORKDIR>/image/usr/lib64 dir and not get picked up by the 
populate_sysroot() code.

I commented out some code in configure.ac and that seems to have solved 
the problem, but I am not sure if we need to start adding lib64 to 
populate_sysroot or tweaking configure code!

Sau!


>   Note that in the log there's:
> NOTE: Running noexec task 5283 of 7886 (ID: 3244,
> virtual:native:/srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/meta/recipes-gnome/libffi/libffi_3.0.12.bb,
> do_build)
>   AFTER glib2.0-native build has failed.
>
>   One thing that may play a role here is that libffi does not depend on
> anything, not even libffi-native. Libffi seems to be built already
> before libffi-native.
>
>
>   - ML
>