From: Saul Wold <sgw@linux.intel.com>
To: Marko Lindqvist <cazfi74@gmail.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 0/5] automake-1.13 and upstream version updates
Date: Mon, 25 Feb 2013 14:34:55 -0800 [thread overview]
Message-ID: <512BE70F.4050707@linux.intel.com> (raw)
In-Reply-To: <CAF6bG8c9BU06uGvuM0ENuyGL4yggQOct620yP18kbkrh_bxbLA@mail.gmail.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
>
next prev parent reply other threads:[~2013-02-25 22:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-17 9:00 [PATCH 0/5] automake-1.13 and upstream version updates Marko Lindqvist
2013-02-19 17:12 ` Saul Wold
2013-02-20 14:32 ` Marko Lindqvist
2013-02-25 11:40 ` Marko Lindqvist
2013-02-25 22:34 ` Saul Wold [this message]
2013-02-26 7:42 ` Marko Lindqvist
2013-02-26 7:52 ` Saul Wold
2013-02-26 8:20 ` Marko Lindqvist
2013-02-26 16:48 ` Trevor Woerner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=512BE70F.4050707@linux.intel.com \
--to=sgw@linux.intel.com \
--cc=cazfi74@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.