canadian-cross sdk?

canadian-cross sdk?

[Angus Lees]

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

Re: canadian-cross sdk?

[Dmitry Vinokurov]

[-- 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"

Re: canadian-cross sdk?

[Richard Purdie]

On Mon, 2010-07-12 at 11:05 +0600, Dmitry Vinokurov wrote:
> 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.

The canadian toolchain bits in OE are still in need to some attention to
fully enable the case where the build machine is not the same as the
machine you want to run the SDK on.

In Poky this works already, you'd set SDKMACHINE=i586 and then
"MACHINE=qemuarm bitbake meta-toolchain".

Cheers,

Richard

Re: canadian-cross sdk?

[Tom Rini]

Richard Purdie wrote:
> On Mon, 2010-07-12 at 11:05 +0600, Dmitry Vinokurov wrote:
>> 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.
> 
> The canadian toolchain bits in OE are still in need to some attention to
> fully enable the case where the build machine is not the same as the
> machine you want to run the SDK on.
> 
> In Poky this works already, you'd set SDKMACHINE=i586 and then
> "MACHINE=qemuarm bitbake meta-toolchain".

So, if one wanted to update oe.dev again, is what's in poky's master 
what works for you guys now?

-- 
Tom Rini
Mentor Graphics Corporation

Re: canadian-cross sdk?

[Richard Purdie]

On Mon, 2010-07-12 at 10:48 -0700, Tom Rini wrote:
> Richard Purdie wrote:
> > On Mon, 2010-07-12 at 11:05 +0600, Dmitry Vinokurov wrote:
> >> 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.
> > 
> > The canadian toolchain bits in OE are still in need to some attention to
> > fully enable the case where the build machine is not the same as the
> > machine you want to run the SDK on.
> > 
> > In Poky this works already, you'd set SDKMACHINE=i586 and then
> > "MACHINE=qemuarm bitbake meta-toolchain".
> 
> So, if one wanted to update oe.dev again, is what's in poky's master 
> what works for you guys now?

Yes, absolutely. This is getting a lot of testing atm.

Cheers,

Richard