From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: Bryan Evenson <bevenson@melinkcorp.com>
Cc: yocto@yoctoproject.org
Subject: Re: Compile on recipe works the second time
Date: Tue, 19 Nov 2013 15:47:15 +0000 [thread overview]
Message-ID: <1458984.Xc2zfu3l73@helios> (raw)
In-Reply-To: <91586D499ADFD74FBCFB8425266A5DE40153BB2BE35F@pluto.melinkcorp.local>
Hi Bryan,
On Tuesday 19 November 2013 08:57:40 Bryan Evenson wrote:
> I'm on poky/dylan-9.0.1 and I've created a layer for a separate open source
> project to include in my image. The layer is at
> https://github.com/evensonbryan/meta-bacnet for those of you who want to
> try and duplicate my results. Just add this layer to your setup and build
> the recipe "bacnet-stack".
>
> I have a very odd build issue. The first time I build the recipe, the build
> fails during the compile step. However, if I then build the recipe again,
> the compile completes without errors. For example:
>
> 1. bitbake -c clean bacnet-stack
> 2. bitbake bacnet-stack (compile fails)
> 3. bitbake bacnet-stack (compile succeeds, rest of image packaging works)
>
> Additionally, the following order compiles without error:
> 1. bitbake -c clean bacnet-stack
> 2. bitbake -c devshell bacnet-stack
> 3. (from devshell) make all (compile succeeds)
>
> This project is divided into a static library and multiple demo
> applications. The static library needs to be built first, and then the
> demo applications include the static library in their build. I suspect I
> have an issue with either populating the static library or the related
> include files in the sysroot which causes the demo applications to fail to
> build the first time but work the second. However, I can't figure out how
> to fix the issue. Any pointers on what is setup wrong with this recipe?
From bacnet-stack.inc:
> do_install () {
> install -d ${D}${bindir} ${D}${datadir} ${D}${libdir} >
${STAGING_INCDIR}/${PN}
> ...
> install -m 0644 ${S}/include/* ${STAGING_INCDIR}/${PN}
> }
Don't poke files directly into the sysroot like this. Install the headers to
${D}${incdir} instead, and they will be staged to the sysroot for you.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
next prev parent reply other threads:[~2013-11-19 15:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-19 13:57 Compile on recipe works the second time Bryan Evenson
2013-11-19 15:47 ` Paul Eggleton [this message]
2013-11-19 16:19 ` Bryan Evenson
2013-11-21 15:33 ` Michael Fainstein
2013-11-25 13:48 ` Bryan Evenson
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=1458984.Xc2zfu3l73@helios \
--to=paul.eggleton@linux.intel.com \
--cc=bevenson@melinkcorp.com \
--cc=yocto@yoctoproject.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.