openembedded-devel.lists.openembedded.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Vinokurov <df6.626@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: canadian-cross sdk?
Date: Mon, 12 Jul 2010 11:05:06 +0600	[thread overview]
Message-ID: <4C3AA282.3030006@gmail.com> (raw)
In-Reply-To: <AANLkTinadOzl08k8hENqZJf9fMzcHHCnpUP1DfmatDj7@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]

This question is important for me to. I'm running OE on linux-x86_64 
machine and want to build ARM toolchain for linux-x86 machine. I've 
asked about it on #irc and CruX| gave me config for building mingw32 
toolchain, it's in attachment and maybe it'll be helpful for you. 
Unfortunately, I couldn't adapt this config for my task, OE tries to 
build mingw all the same.

It would be great if someone explain how to build canadian cross SDK. I 
haven't found nothing helpful about it neither in documentation nor in 
ML archives but it is very important question I think.

On 06.07.2010 09:29 Angus Lees wrote:
> I have an SDK built for my OS using dev-OE - and it works well.  I'd like to
> build an SDK for another host OS (in particular cygwin if that is possible),
> but I'm lost in a twisty maze of canadian-sdk classes that all seem to be
> deprecated and/or unused.
>
> Which of the canadian-cross options is the recommended approach atm?  How do
> I use it?
>
>   - Gus
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>    


[-- Attachment #2: canadianconfexample.txt --]
[-- Type: text/plain, Size: 8093 bytes --]

#
# OpenEmbedded local configuration file (sample)
#
# Please visit the Wiki at http://openembedded.org/ for more info.
#
#
# Be SURE to read this file in its entirety and the GettingStarted page on the
# wiki before proceeding.
#
# Once you have done that, remove the line at the end of this
# file and build away.
# 
# WARNING: lines starting with a space (' ') will result in parse failures.
# Remove '# ' from commented lines to activate them.
#
# NOTE: Do NOT use $HOME in your paths, BitBake does NOT expand ~ for you.  If you
# must have paths relative to your homedir use ${HOME} (note the {}'s there
# you MUST have them for the variable expansion to be done by BitBake).  Your
# paths should all be absolute paths (They should all start with a / after
# expansion.  Stuff like starting with ${HOME} or ${TOPDIR} is ok).

# Use this to specify where BitBake should place the downloaded sources into
DL_DIR = "/stuff/sources"

# Uncomment this if you want to use a prebuilt toolchain. You will need to
# provide packages for toolchain and additional libraries yourself. You also
# have to set PATH in your environment to make sure BitBake finds additional binaries.
# ASSUME_PROVIDED += "virtual/${TARGET_PREFIX}gcc virtual/libc"

# Uncomment this if you're building for an arch that uses emulated locale 
# generation under qemu (mainly arm glibc) and have an external gcc 3.x compiler
# that OE recognises. This will mean the gcc-native build is skipped, speeding 
# builds up.
# ASSUME_PROVIDED += "gcc3-native"

# Uncomment this if you are building Linux 2.4 Embedix kernels.
# i.e. openzaurus-sa-2.4.18 and openzaurus-pxa-2.4.18 - and don't forget
# to rename the binaries as instructed in the Wiki.
# Most users do not need this anymore thankfully!
# ASSUME_PROVIDED += "virtual/arm-linux-gcc-2.95"

# Select between multiple alternative providers, if more than one is eligible.
PREFERRED_PROVIDERS = "virtual/qte:qte virtual/libqpe:libqpe-opie"
PREFERRED_PROVIDERS += " virtual/libsdl:libsdl-x11"
PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}gcc-initial:gcc-cross-initial"
PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}gcc-intermediate:gcc-cross-intermediate"
PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}gcc:gcc-cross"
PREFERRED_PROVIDERS += " virtual/${TARGET_PREFIX}g++:gcc-cross"

# Uncomment this to specify where BitBake should create its temporary files.
# Note that a full build of everything in OpenEmbedded will take GigaBytes of hard
# disk space, so make sure to free enough space. The default TMPDIR is
# <build directory>/tmp
# Don't use symlinks in in the path to avoid problems
TMPDIR = "/stuff/tmp-oe"

# Use this to specify the target architecture. Note that this is only
# needed when building for a machine not known to OpenEmbedded. Better use
# the MACHINE attribute (see above)
# TARGET_ARCH = "arm"

# Use this to specify the target operating system.  The default is "linux",
# for a normal linux system with glibc. Set this to "linux-uclibc" if you want
# to build a uclibc based system.
# Normally the DISTRO of your choosing will take care of this 
# TARGET_OS = "linux"
# TARGET_OS = "linux-uclibc"

# Uncomment this to select a distribution policy. See the conf directory
# for distributions currently known to OpenEmbedded.
# Although it no longer contain version number in the (file-)name
# openzaurus-unstable is a so called "versioned"  distro, i.e. they 
# explicitely select specific versions of various packages.
# Stay away from unversioned distros unless you really know what you are doing
# DISTRO = "angstrom-2008.1"

# So far, angstrom.conf sets ENABLE_BINARY_LOCALE_GENERATION
# to generate binary locale packages at build time using qemu-native and
# thereby guarantee i18n support on all devices. If your build breaks on 
# qemu-native consider disabling ENABLE_BINARY_LOCALE_GENERATION (note that
# this breaks i18n on devices with less than 128MB RAM) or installing
# a working third-party qemu (e.g. provided by your distribution) and
# adding qemu-native to ASSUME_PROVIDED. Caveat emptor, since third-party
# qemus lack patches needed to work with various OE targets.
# ENABLE_BINARY_LOCALE_GENERATION = "0"
# ASSUME_PROVIDED += "qemu-native"

# If ENABLE_BINARY_LOCALE_GENERATION is set to "1", you can limit locales
# generated to the list provided by GLIBC_GENERATE_LOCALES. This is huge
# time-savior for developmental builds. Format: list of locale.encoding pairs
# with spaces as separators.
GLIBC_GENERATE_LOCALES = "en_GB.UTF-8"

# Uncomment this to select a particular major kernel version if the MACHINE setting
# supports more than one major kernel version. Currently this is suported by the
# following MACHINE types: poodle, tosa and simpad.
# MACHINE_KERNEL_VERSION = "2.6"

# Uncomment one of these to build packages during the build process.
# This is done automatically if you set DISTRO (see above)
# INHERIT = "package_ipk"
# INHERIT = "package_tar"

# Add the required image file system types below. Valid are 
# jffs2, tar(.gz|bz2), cpio(.gz), cramfs, ext2(.gz), ext3(.gz)
# squashfs, squashfs-lzma
IMAGE_FSTYPES = "jffs2 tar"

# Uncomment this to disable the parse cache (not recommended).
# CACHE = ""

# Uncomment this if you want BitBake to emit debugging output
# BBDEBUG = "yes"

# Uncomment these two if you want BitBake to build images useful for debugging. 
# Note that INHIBIT_PACKAGE_STRIP needs a package format to be defined.
# Also note that OE now produces -dbg packages which contain debugging symbols.
# DEBUG_BUILD = "1"
# INHIBIT_PACKAGE_STRIP = "1"

# Uncomment these to build a package such that you can use gprof to profile it.
# NOTE: This will only work with 'linux' targets, not
# 'linux-uclibc', as uClibc doesn't provide the necessary
# object files.  Also, don't build glibc itself with these
# flags, or it'll fail to build.
#
# PROFILE_OPTIMIZATION = "-pg"
# SELECTED_OPTIMIZATION = "${PROFILE_OPTIMIZATION}"
# LDFLAGS =+ "-pg"

# Uncomment this to enable parallel make.
# This allows make to spawn mutliple processes to take advantage of multiple 
# processors. Useful on SMP machines. This may break some packages - we're
# in the process of marking these so let us know if you find any.
# PARALLEL_MAKE = "-j 4"

# Uncomment this if you want BitBake to emit the log if a build fails.
BBINCLUDELOGS = "yes"

# Specifies a location to search for pre-generated tarballs when fetching
# a cvs:// URI. Outcomment this, if you always want to pull directly from CVS.
#CVS_TARBALL_STASH = ""

# Uncomment this if you want to install shared libraries directly under their SONAME,
# rather than installing as the full version and symlinking to the SONAME.
# PACKAGE_SNAP_LIB_SYMLINKS = "1"

#BBMASK = "(python-gsmd_svn.bb|dhcdbd_1.14.bb|mingw-gcc*)"

GLIBC_GENERATE_LOCALES = "en_GB.UTF-8"
ENABLE_BINARY_LOCALE_GENERATION = "1"

#ASSUME_PROVIDED += "linux virtual/kernel"

BBFILES = "/stuff/openembedded/recipes/*/*.bb"
OE_ALLOW_INSECURE_DOWNLOADS = "1"
PARALLEL_MAKE = "-j2"

DISTRO = "angstrom-2008.1"

MACHINE = "at91sam9260ek"
#MACHINE = "i686-generic"
#MACHINE = "x86-prescott"
#MACHINE = "efika"


## Canadian SDK
SDK_ARCH        = "i586"
SDK_OS          = "mingw32"
SDK_VENDOR      = ""
SDK_CC_ARCH     = ""
SDK_EXEEXT      = ".exe"
# MinGW canadian providers
PREFERRED_PROVIDER_virtual/${SDK_PREFIX}binutils_sdk-mingw32 ="mingw-binutils-canadian-cross"
PREFERRED_PROVIDER_virtual/${SDK_PREFIX}gcc_sdk-mingw32 = "mingw-gcc-canadian-cross"
PREFERRED_PROVIDER_virtual/${SDK_PREFIX}gcc-initial_sdk-mingw32 = "mingw-gcc-canadian-cross-initial"
PREFERRED_PROVIDER_virtual/${SDK_PREFIX}libc-initial_sdk-mingw32 = "mingw-runtime-headers"
PREFERRED_PROVIDER_virtual/${SDK_PREFIX}libc-for-gcc_sdk-mingw32 = "mingw-runtime"
# gcc
PREFERRED_PROVIDER_virtual/${SDK_PREFIX}gcc = "mingw-gcc-canadian-cross"
PREFERRED_PROVIDER_virtual/${SDK_PREFIX}binutils_sdk-mingw32 = "mingw-binutils-canadian-cross"

  reply	other threads:[~2010-07-12  5:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-06  3:29 canadian-cross sdk? Angus Lees
2010-07-12  5:05 ` Dmitry Vinokurov [this message]
2010-07-12 14:57   ` Richard Purdie
2010-07-12 17:48     ` Tom Rini
2010-07-13 16:37       ` Richard Purdie

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=4C3AA282.3030006@gmail.com \
    --to=df6.626@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).