All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Conroy <Chris.Conroy@hillcrestlabs.com>
To: Gary Thomas <gary@mlbassoc.com>
Cc: openembedded-devel@lists.openembedded.org
Subject: Re: Prebuilt toolchains
Date: Wed, 11 Nov 2009 16:29:42 -0500	[thread overview]
Message-ID: <1257974982.4924.56.camel@conroy-linux> (raw)
In-Reply-To: <4AFB27AD.1010602@mlbassoc.com>

On Wed, 2009-11-11 at 14:07 -0700, Gary Thomas wrote:
> 
> Thanks for the pointer.  Given that I'm really new with OE, can you
> give me a clue as to how to use that recipe?  Can I just add some
> magic to my local.conf to make this work (instead of the lines quoted above)?
> 

Sure thing. Sadly the snapshot of OE that we're working with internally
had some issues which required us to pull a few changes from poky and
make some local changes which I haven't been able to push upstream yet.
Long story short, I'm not 100% in sync with trunk here so you may need
to change a couple of things, but this will get you most of the way
there. Most of my issues were in the creation, not in the sourcing of
the toolchain.

We allow developers to choose between an "external" or "scratch" (let OE
build it) toolchain and use a paradigm similar to the pokymode. In my
local.conf I have

> TOOLCHAIN="external"

In my distro conf I have:

> #Default to build the toolchain if no external one is selected
> TOOLCHAIN ?= "scratch"
> require conf/toolchain-${TOOLCHAIN}.conf

My toolchain-external.conf looks like:
> PREFERRED_PROVIDER_linux-libc-headers = "external-toolchain"
> PREFERRED_PROVIDER_glibc-thread-db = "external-toolchain"
> PREFERRED_PROVIDER_libstdc++-dev = "external-toolchain"
> PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc = "external-toolchain"
> PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}g++ = "external-toolchain"
> PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc-initial = "external-toolchain"
> PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc-intermediate =  "external-toolchain"
> PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}binutils = "external-toolchain"
> PREFERRED_PROVIDER_virtual/binutils = "external-toolchain"
> PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}libc-for-gcc =  "external-toolchain" 
> PREFERRED_PROVIDER_virtual/libc =  "external-toolchain" 
> PREFERRED_PROVIDER_virtual/libintl =  "external-toolchain" 
> PREFERRED_PROVIDER_virtual/libiconv =  "external-toolchain" 
> 
> 
> TOOLCHAIN_OPTIONS = " --sysroot=${STAGING_DIR_HOST}"
> PATH =. "${SDK_PREFIX}/bin:"

I believe the SDK_PREFIX is a pokyism. I also pulled in the BUILDSDK_CPPFLAGS and friends from poky.

in bitbake.conf...
> export BUILDSDK_CPPFLAGS = "-isystem${STAGING_INCDIR}"
> export BUILDSDK_CFLAGS = "${BUILDSDK_CPPFLAGS} ${BUILD_OPTIMIZATION}"
> export BUILDSDK_LDFLAGS = "-L${STAGING_LIBDIR} \
>                     -Wl,-rpath-link,${STAGING_LIBDIR} \
>                     -Wl,-rpath,${libdir} -Wl,-O1"

in sdk.bbclass...
> CPPFLAGS = "${BUILDSDK_CPPFLAGS}"
> CFLAGS = "${BUILDSDK_CFLAGS}"
> CXXFLAGS = "${BUILDSDK_CFLAGS}"
> LDFLAGS = "${BUILDSDK_LDFLAGS}"


Hopefully that helps. Ideally this stuff would just work out of the box, but it sounds like the toolchain setup is going to get a major makeover soon.

--Chris Conroy



  reply	other threads:[~2009-11-11 21:31 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-11 17:00 Prebuilt toolchains Gary Thomas
2009-11-11 20:39 ` Chris Conroy
2009-11-11 21:07   ` Gary Thomas
2009-11-11 21:29     ` Chris Conroy [this message]
2009-11-13 14:06       ` Gary Thomas
2009-11-13 15:57         ` Chris Conroy
2009-11-13 17:25           ` Gary Thomas
2009-11-13 18:41             ` Chris Conroy
2009-11-13 23:00               ` Gary Thomas
2009-11-16 22:40                 ` Gary Thomas
2009-11-17  3:12                   ` Mike Turquette
2009-11-17  7:34 ` Koen Kooi
2009-11-18 13:40   ` Gary Thomas
2009-11-18 15:29     ` Gary Thomas
2009-11-18 23:24   ` Gary Thomas

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=1257974982.4924.56.camel@conroy-linux \
    --to=chris.conroy@hillcrestlabs.com \
    --cc=gary@mlbassoc.com \
    --cc=openembedded-devel@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.