All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Gerard van den Bosch <gerard@de-haardt.com>
Cc: poky@yoctoproject.org
Subject: Re: compile application header file missing
Date: Wed, 16 Mar 2011 16:08:08 +0000	[thread overview]
Message-ID: <1300291688.30423.1890.camel@rex> (raw)
In-Reply-To: <4D7F7FB4.30007@de-haardt.com>

On Tue, 2011-03-15 at 16:03 +0100, Gerard van den Bosch wrote:
> I am indeed using the Green release.
> 
> The TARGET_CFLAGS are indeed the same as the CFLAGS. The system is
> using the default CC and not the BUILD_CC, thanks for pointing out the
> difference.
> 
> I have added the --sysroot option pointing to the arm sysroot to the
> CFLAGS in my recipe, with compilation it now looks like this:
> arm-poky-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8 -mfpu=neon
> -mfloat-abi=softfp -fno-tree-vectorize -fexpensive-optimizations
> -fomit-frame-pointer -frename-registers -O2 -ggdb
> -feliminate-unused-debug-types
> --sysroot=/home/gerard/green-3.3/build/tmp/sysroots/armv7a-poky-linux-gnueabi/ libxmlpcp.c -o libxmlpcp.o
> 
> This removes the missing SLP.h error.
> 
> Is this problem related to my recipe or did I broke my build
> environment?

To be honest, I don't know. The compiler should have been defaulting to
that already so I don't understand why it wasn't working. We now
explictly set this in master to allow for toolchain relocation and the
machine specific sysroots support. You could try backporting the piece
of code I previously referred to which should also fix the problem.

If that option were missing from the toolchain I'd have expected you to
see other errors rather than just this isolated problem...

> My recipe looks like this:
> DESCRIPTION = "libxmlpcp"
> SECTION = "examples"
> DEPENDS = "openslp libxml2"
> LICENSE = "LGPL"
> 
> SRC_URI = "file://libxmlpcp.tar.gz"
> 
> CFLAGS += --sysroot=/home/gerard/green-3.3/build/tmp/sysroots/armv7a-poky-linux-gnueabi/
> 
> do_install() {
>      install -d ${D}${libdir}
>      install -d ${D}${includedir}
>      oe_runmake 'INSTALLHEADERDIR=${D}${includedir}' 'INSTALLLIBDIR=${D}${libdir}' \
>      install
> }

That all looks reasonable enough...

Cheers,

Richard



  reply	other threads:[~2011-03-16 16:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-15 10:57 compile application header file missing Gerard van den Bosch
2011-03-15 13:38 ` Richard Purdie
2011-03-15 15:03   ` Gerard van den Bosch
2011-03-16 16:08     ` Richard Purdie [this message]
2011-03-17  7:43       ` Gerard van den Bosch
2011-03-17  7:52         ` Khem Raj
2011-03-17  8:00           ` Gerard van den Bosch
2011-03-17  8:22             ` Gerard van den Bosch
2011-03-17 13:54               ` Gerard van den Bosch

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=1300291688.30423.1890.camel@rex \
    --to=richard.purdie@linuxfoundation.org \
    --cc=gerard@de-haardt.com \
    --cc=poky@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.