linux/poky.git/meta/recipes-devtools/gcc/gcc-configure-sdk.inc, branch uninative-3.2

gcc-cross-canadian: Fold configure-sdk and package-sdk into the main .inc

2013-08-23T15:20:13+00:00

This also has the advantage of removing the confusing sdk naming which has been purged everywhere else in favour of cross-canadian. (From OE-Core rev: cbb63ca9e7e6d397198808e862f812f1012c74a7) Signed-off-by: Richard Purdie

gcc-configure-sdk.inc: Don't build target-libgcc

2013-08-23T15:20:11+00:00

I don't understand why we're building the target libgcc in the canadian-cross build since it should have been built elsewhere. The compiler configuration isn't correct to build a working target libgcc in all cases anyway. To avoid various weird build errors, stop building it. (From OE-Core rev: b0d1ab6242b6ce2bcdd0e4e3e61600344fcd2907) Signed-off-by: Richard Purdie

gcc-configure-sdk, gcc-configure-cross: Dont recompute USE_NLS

2012-06-29T12:30:58+00:00

This was needed because on eglibc based builds we did not define USE_NLS but now we define it in default config to have a valid value so we do not need this here. Moreover it was wrong and was not covering all cases of uclibc triplets (From OE-Core rev: fc9492654aab2a6e3f46977193b5a5f388e4ee85) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

gcc-configure: Render --with-local-prefix harmless

2012-04-30T10:37:23+00:00

this option by default points to /usr/local no matter what so we cant let it sit on sidelines otherwise it will access host machine's /usr/local which may not be desired. So disable this option. This also helps in making gcc's shared state more consistent (From OE-Core rev: eee3658366e1ae9d3e429b3d3c968938d8d0f00e) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

gcc-configure: Pass distinct target flags

2012-04-30T10:37:23+00:00

When building gcc-cross-canadian libgcc is built using headers from gcc-crosssdk and not the target sysroot because we do not pass proper CFLAGS for target bits so it ends up using CFLAGS that were meant for compiling canadian gcc itself. It does not show up as a problem when building SDK with eglibc because eglibc-nativesdk and eglibc have identical headers. The problem shows up clearly when you try to build uclibc based meta-toolchain since then nativesdk libc and target libc are different (From OE-Core rev: 0e904103e9bd7fdb31bfcc129067511f9f45701b) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

gcc-4.6: Let G++ relocate gxx-include-dir when using --sysroot option

2011-12-19T09:29:18+00:00

Currently we have a problem in our cross compiler since we use /usr/include/c++ to be default gxx-include-dir and then expect the patch we did to do the relocation w.r.t. sysroot however it does not quite work so and we end up gxx-include-dirs not respecting sysroot. A small test case would be tst-unique4.cc and it would fails like tst-unique4.cc:1:18: fatal error: cstdio: No such file or directory compilation terminated. weather we use --sysroot or not it does not matter arm-oe-linux-gnueabi-g++ -S tst-unique4.cc --sysroot=/home/kraj/work/angstrom/sources/openembedded-core/build/tmp-eglibc/sysroots/qemuarm failed in same way. so we redo the GPLUSPLUS_INCLUDE_DIR_with_sysroot.patch based on upstream submitted patch which tries to relocate the gxx-include-dir and to achieve the relocation it has to be specified w.r.t to --with-sysroot directory. e.g. --with-sysroot=${SYSROOT} --with-gxx-include-dir=${SYSROOT}/usr/include/c++ if we configure gcc like above then it becomes relocatable when we run the compiler and specify --sysroot= then g++ will search for gxx-headers under /usr/include/c++ if sysroot is not defined then it will use the default sysroot and gxx-include-dir will be w.r.t. default sysroot. Tested on qemuarm /arm-oe-linux-gnueabi-g++ -S tst-unique4.cc --sysroot=/home/kraj/work/angstrom/sources/openembedded-core/build/tmp-eglibc/sysroots/qemuarm -v ... /home/kraj/work/angstrom/sources/openembedded-core/build/tmp-eglibc/sysroots/qemuarm/usr/include/c++ /home/kraj/work/angstrom/sources/openembedded-core/build/tmp-eglibc/sysroots/qemuarm/usr/include/c++/arm-oe-linux-gnueabi /home/kraj/work/angstrom/sources/openembedded-core/build/tmp-eglibc/sysroots/qemuarm/usr/include/c++/backward ... and if I now change --sysroot to something else /arm-oe-linux-gnueabi-g++ -S tst-unique4.cc --sysroot=/home/kraj/work/angstrom/sources/openembedded-core/build/tmp-eglibc/sysroots/qemuarm4 -v ... ignoring nonexistent directory "/home/kraj/work/angstrom/sources/openembedded-core/build/tmp-eglibc/sysroots/qemuarm4/usr/include/c++" ignoring nonexistent directory "/home/kraj/work/angstrom/sources/openembedded-core/build/tmp-eglibc/sysroots/qemuarm4/usr/include/c++/arm-oe-linux-gnueabi" ignoring nonexistent directory "/home/kraj/work/angstrom/sources/openembedded-core/build/tmp-eglibc/sysroots/qemuarm4/usr/include/c++/backward" ... See now its looking for them in 'qemuarm4' sysroot (From OE-Core rev: 28b772e42a20faebe1b4f415d28b42b7e0a424fb) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

gcc-configure-sdk: Point sysroot to correct location

2011-10-24T16:27:13+00:00

(From OE-Core rev: c9883733fed9267b1a936c08500a4caf8dc52d3d) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

recipes: Use -uclibceabi instead of -uclibcgnueabi

2011-04-04T13:09:33+00:00

(From OE-Core rev: 3aa429406184d27bdb8a771c4c12bde1dcccb95b) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

gcc-4.5.1: make c++ include path relative to "--sysroot"

2011-01-02T09:25:40+00:00

So far c++ include path is not relative to "--sysroot", which brings trouble if we want to use the toolchain in a new environment where the original build directory generating that toolchain is not available. It's firstly exposed in multiple SDK sysroots support, and then in the case when sstate packages are used, where c++ standard headers are missing because gcc tries to search original build dir. This patch makes c++ include path now relative to "--sysroot", and then once "--sysroot" is assigned correctly in new environment, c++ include paths can be searched as expected. Signed-off-by: Kevin Tian

Major layout change to the packages directory

2010-08-27T14:29:45+00:00

Having one monolithic packages directory makes it hard to find things and is generally overwhelming. This commit splits it into several logical sections roughly based on function, recipes.txt gives more information about the classifications used. The opportunity is also used to switch from "packages" to "recipes" as used in OpenEmbedded as the term "packages" can be confusing to people and has many different meanings. Not all recipes have been classified yet, this is just a first pass at separating things out. Some packages are moved to meta-extras as they're no longer actively used or maintained. Signed-off-by: Richard Purdie