Commit Graph

8 Commits

Author SHA1 Message Date
Khem Raj 3916fb9bf4 gcc-configure-sdk, gcc-configure-cross: Dont recompute USE_NLS
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 <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-06-29 13:30:58 +01:00
Khem Raj 9ce94ea4a4 gcc-configure: Render --with-local-prefix harmless
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 <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-04-30 11:37:23 +01:00
Khem Raj f66cc57e72 gcc-configure: Pass distinct target flags
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 <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-04-30 11:37:23 +01:00
Khem Raj af9c75c8f5 gcc-4.6: Let G++ relocate gxx-include-dir when using --sysroot option
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=<blah> then g++ will search
for gxx-headers under <blah>/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 <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-12-19 09:29:18 +00:00
Khem Raj 53f7342562 gcc-configure-sdk: Point sysroot to correct location
(From OE-Core rev: c9883733fed9267b1a936c08500a4caf8dc52d3d)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-24 17:27:13 +01:00
Khem Raj 3909b764b7 recipes: Use -uclibceabi instead of -uclibcgnueabi
(From OE-Core rev: 3aa429406184d27bdb8a771c4c12bde1dcccb95b)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-04-04 14:09:33 +01:00
Kevin Tian f13cb20ed1 gcc-4.5.1: make c++ include path relative to "--sysroot"
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 <kevin.tian@intel.com>
2011-01-02 01:25:40 -08:00
Richard Purdie 29d6678fd5 Major layout change to the packages directory
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 <rpurdie@linux.intel.com>
2010-08-27 15:29:45 +01:00