openembedded-core.git/meta/classes/cross-canadian.bbclass, branch uninative-1.0

gcc-runtime, libgcc: Symlink c++ header and startup files in target_triplet for SDK use

2016-05-13T12:40:53+00:00

We build SDKs such that gcc-cross-candian is built for only one
target *-*-linux and then use -muclibc or -mmusl to let it compile
code for other libc variants. This works fine when libc = glibc
however it does not work for c++ programs when libc != glibc since
there are c++ headers installed under ${includedir}/c++/${BINV}/${TARGET_SYS}
which is fine when gcc-runtime and gcc-cross-candian uses same --target options
gxx includedir searches in right triplet, but it fails with musl/uclibc
since gcc will look for glibc based triplet but gcc-runtime will install
them under musl/uclibc triplet.

This patch symlinks the musl/uclibc triplet to glibc triplet when libc != glibc

This fixes SDKs for musl/uclibc

Signed-off-by: Khem Raj 
Signed-off-by: Richard Purdie

package_deb.bbclass, cross-canadian.bbclass: DPKG_ARCH mapping function

2016-01-11T23:23:17+00:00

Have DPKG_ARCH set by directly invoking a mapping function, rather
than using an anonymous Python function modify the variable under
the hood, so we can have proper handling of overrides.

Also bring in some additional mappings to Debian architecture names
that weren't being handled.

Signed-off-by: Matt Madison 
Signed-off-by: Aníbal Limón 
Signed-off-by: Ross Burton

meta: Drop now pointless manual -dbg packaging

2015-12-16T11:56:06+00:00

With the autodebug package generation logic, specifically setting FILES_${PN}-dbg
isn't needed in most cases, we can remove them.

Signed-off-by: Richard Purdie

cross-canadian.bbclass: big-endian ARM is also gnueabi.

2015-09-29T14:15:48+00:00

If building for a BE8 ARM target, arch is "armeb" rather than
"arm", but ABI should still be "gnueabi". Otherwise gcc won't
build.

Signed-off-by: Peter Seebach 
Signed-off-by: Richard Purdie

cross-canadian.bbclass: typo fix in comments (s/repsonsible/responsible/)

2015-09-06T14:24:27+00:00

Signed-off-by: Mario Domenech Goulart 
Signed-off-by: Richard Purdie

cross-canadian.bbclass: support for TCLIBC="baremetal"

2015-08-30T11:34:11+00:00

Allow "baremetal" builds.

(From OE-Core rev: 0cd3121058ea620c74622f1200c8040696b4d1d8)

Signed-off-by: Juro Bystricky 
Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie

cross-canadian/gcc: Various mips64 fixes

2015-07-31T14:15:13+00:00

"n32" is a mips64 variant we need to consider when processing the TARGET_OS
extensions. Also add the multilib extensions for mips64.

Signed-off-by: Richard Purdie

cross-canadian: Add symlinks for multilib cases

2015-07-31T14:15:12+00:00

In the same way we map various TARGET_OS options back to the single
cross-canadian compiler, add mappings for the TARGET_VENDOR cases we
know about in the multilib case.

Signed-off-by: Richard Purdie

cross-canadian: Put links in place for uclibc and musl

2015-07-27T22:28:22+00:00

gcc-cross-canadian- is only built once. It needs to target all the
different libcs, not just the currently selected one. This change
ensures that if another libc is used, symlinks are present such that the
compiler can be found. The base version is always assumed to be "glibc"
with symlinks from musl and uclibc compiler names.

This means gcc-cross-canadian is consistent regardless of which libc is
selected when its build in multimachine builds.

[YOCTO #8025]

(From OE-Core rev: 83ead626c0da75edec2833ffb1a29011ec7b83d2)

Signed-off-by: Richard Purdie

cross-canadian/meta-environment: Allow modification of TARGET_OS to be optional

2015-01-16T09:13:44+00:00

There are some cases we want the manipulation cross-canadian performance
on TARGET_OS, there are also cases like meta-environment where we do not
want this manipulation.

We did try and use immediate expansion to avoid this problem and it
works in the non multilib case. If we have a multilib that used an
extension, like for example:

require conf/multilib.conf
MULTILIBS = "multilib:lib32 multilib:lib64"
DEFAULTTUNE = "mips32r2"
DEFAULTTUNE_virtclass-multilib-lib32 = "mips64-n32"
DEFAULTTUNE_virtclass-multilib-lib64 = "mips64"

then the n32 extension case will be misconfigured.

It turns out saving an unexpanded variable is hard. The best I could
come up with was:

SAVEDTOS := "${@d.getVar('TARGET_OS', False).replace("{", "*")}"

and then

localdata.setVar("TARGET_OS", d.getVar("SAVEDOS", False).replace('*','{'))

which is rather evil, I'd challenge someone to come up with a nicer way
of making it work though!

Rather than the above madness, we modify cross-canadian to make the
problamtic code conditional.

This fixes the original issue (where a linux-gnuspe target was seeing
'linux') of
http://cgit.openembedded.org/openembedded-core/commit/?id=0038634ee6e2b6035c023a2702547f20f67c103a
but also fixes the multilib one.

Signed-off-by: Richard Purdie