Needed because the equality check was failing here even though upon
printing the LHS and RHS were the same.
As per http://stackoverflow.com/a/2987975/64537, using "is" compares the
memory addresses of the two objects which is not what we want here. We
just want to compare the values.
(From OE-Core rev: 7fd82cc90a48302ed42b6bfa962bb0de2c652b45)
Signed-off-by: Kartik Mohta <kartikmohta@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We added the autoconf cache line a while back to ensure that configure doesn't
poke into some hardcoded host paths looking for things it shouldn't. Applying
it as part of do_configure wasn't getting it to the do_compile tasks
where much of the configure scripts are run by gcc. This changes it to a simple
export to ensure it reaches the places it needs to and truly gets rid of
the cross compile badness messages from the logs.
(From OE-Core rev: af58d5c3a5c5e632aa20b1d007d47dbbfb4ed6e6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
Fixes build warnings like below
WARNING: For recipe libgcc, the following files/directories were installed but not shipped in any package:
WARNING: /usr/lib/arm-oe-linux-gnueabi/4.7.2/include
WARNING: /usr/lib/arm-oe-linux-gnueabi/4.7.2/include/unwind.h
(From OE-Core rev: f7ec6ea2b32207993e7fc92ed67c08f542007953)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
sourcery toolchain is available as external pluggable toolchain
if needed.
(From OE-Core rev: 7d0c7a759c29669b2b5828fd75837926506acd87)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If anyone wants it add toolchain-layer from meta-openembedded
repo to your setup
(From OE-Core rev: a78260d8d041e606ce4d10c0bb52f196dd27832e)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
when using --with-sysroot=/ and --with-gxx-headers=/usr/include/c++
configure eats up one leading / from gxx include dir
fixed thusly
(From OE-Core rev: 51064de5fb92c53c99b21487c0ebcafeaf3cc3ad)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There would be an "Argument list too long" error when the length of
tmpdir is longer than 190, this is caused by:
headers=`echo $(PLUGIN_HEADERS) | tr ' ' '\012' | sort -u`
The PLUGIN_HEADERS is too long before sort, so the "echo" can't handle
it, use the $(sort list) of GNU make which can handle the too long list
would fix the problem, the header would be short enough after sorted.
The "tr ' ' '\012'" was used for translating the space to "\n", the
$(sort list) doesn't need this.
This doesn't impact the output, so it doesn't need the PR bump.
[YOCTO #2591]
(From OE-Core rev: b9b75e6cf31991c046713194f75bc61027558464)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Otherwise it assumes / as sysroot on build host and starts
searching for directories in there.
[RP: Tweak to add missing = for consistent syntax]
(From OE-Core rev: d132bcc41d9956f8cc171e34232d991e2b444689)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
TARGET_ARCH is poured into TRANSLATED_TARGET_ARCH
for gcc-cross family or gcc-crosssdk family
of recipes we have to check for TRANSLATED_TARGET_ARCH
(From OE-Core rev: 03f7322b1f4e1b1cf465a46cba3b82573384ab9e)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need to check target to be arm before enabling hard-float
ABI. There are crossdk targets or candian-cross targets built
for arm and we should not enable it for those class of recipes.
(From OE-Core rev: f48bb903218e14ba15dab452e8bb43ba25b9ea44)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If callconvention-hard is set then we build gcc defaulting
to hard-float ABI
(From OE-Core rev: 88dee5cf5265d3ea26fc9d471fc6155e48935dc7)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Backported from 523df15bcc21e1749771cca757613f3520243b8e
as suggested by Khem.
* Original commit message:
If build system has those libraries installed
gcc configure will pick them up. We want
consistent builds so we disable them since we
do not (yet) support them
(From OE-Core rev: 9de1de7c2c4e9f5accb4dd082fe819a711defbfb)
Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Fixes the following error after a system library upgrade
| .../mipsel-oe-linux/4.6.4/cc1: error while loading shared libraries: libppl.so.10: cannot open shared object file: No such file or directory
(From OE-Core rev: 2c0fb8265d4876db537850f4b20c898dde3a0f4c)
Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes:
ERROR: For recipe gcc, the following files/directories were installed but not shipped in any package:
ERROR: /usr/libexec/gcc/i586-poky-linux/4.7.1/plugin/gengtype
(From OE-Core rev: 0be64cda0a20ca3aab75ee0cc360236d2dc40c95)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
shift the cmdline argument after determining
there is atleast 1 argument to shift otherwise
it ends up in error when no argument is specified
(From OE-Core rev: 4cd306ab0c9404a31f38c7e5fb67fe32fdca3d4b)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This will help in meta-linaro where it will be able
to utilize maximum recipes from OE-Core and thereby
keep close compatibility with OE-Core gcc recipes
(From OE-Core rev: 3c9f7eb2e2d70869a71a584eb1ba670b50a88379)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This should help in speeding up compilation at the expense
of a bit less info when gcc ICEs but we dont get many gcc
ICEs and therefore using --enable-checking=release is
right balance
(From OE-Core rev: a84c097cc7c52a856601e546880440d9375b0e30)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If build system has those libraries installed
gcc configure will pick them up. We want
consistent builds so we disable them since we
do not (yet) support them
(From OE-Core rev: 523df15bcc21e1749771cca757613f3520243b8e)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
create a new package to have lto dev packages bundled
(From OE-Core rev: b98fb95c594117d165a31795b6fa7b6cb583d598)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
--with-native-system-header-dir is relative to sysroot which
is what we want --with-headers is deprecated anyway
(From OE-Core rev: 2f7ac32b57e047cdaf01e0b6f77509117dbbd14c)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need -isystem=${target_includedir} in there
(From OE-Core rev: 573949096d51bde4961b2301c20c966c324a66bd)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add new recipes for gcc-4_7-branch right now gcc 4.7.0
is latest release from this branch
(From OE-Core rev: 3f8fee75e598ad0994acc5da0a612e6eca4f35f6)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Its better than duplicating the overrides
(From OE-Core rev: 7159dad19f8cfd3e7e95523da63e91370744da7f)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is needed for adjusting meta-linaro where linaro
gcc recipes leverage the core recipe infrastructure and
modifies minimal to keep compatibility with OE-Core
so that any changes in OE-Core gcc recipes does not
trigger changes in meta-linaro.
(From OE-Core rev: cb01b2a4fc82e62eacc4441fddc3fdfb04a3acf3)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
Currently we stash the libgcc install tree and then reuse that
to populate libgcc recipe later. This mechanism does not work
for gcc 4.7/trunk since now libstdc++ needs access to build tree
of libgcc. This patch stashes the gcc-cross build tree
and then reuses this in libgcc as well as in gcc-runtime
recipe builds.
Now we build libgcc in the libgcc recipe instead of just
using the prebuilt install tree
core-image-minimal build/run tested on all qemu machines
(From OE-Core rev: 7cf9f0597648c0bdaa080976d74acfbfc4c8443d)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
WARNING: For recipe gcc, the following files/directories were installed but not shipped in any package:
WARNING: /usr/include
WARNING: /usr/lib/gcc/arm-poky-linux-gnueabi/4.6.4/plugin/libgcc
WARNING: /usr/lib/gcc/arm-poky-linux-gnueabi/4.6.4/plugin/libgcc/config
WARNING: /usr/lib/gcc/arm-poky-linux-gnueabi/4.6.4/plugin/libgcc/config/arm
WARNING: /usr/lib/gcc/arm-poky-linux-gnueabi/4.6.4/plugin/libgcc/config/arm/bpabi-lib.h
(From OE-Core rev: aff48c514174ba5fa3bb1e5df5293376b567da09)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
WARNING: For recipe libgcc, the following files/directories were installed but not shipped in any package:
WARNING: /usr/lib/powerpc-poky-linux/4.6.4/ecrti.o
WARNING: /usr/lib/powerpc-poky-linux/4.6.4/ncrti.o
WARNING: /usr/lib/powerpc-poky-linux/4.6.4/ecrtn.o
WARNING: /usr/lib/powerpc-poky-linux/4.6.4/ncrtn.o
(From OE-Core rev: b17c02d223455680324227f8de17feb8ab3e7b68)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There were puzzling failures when you make a force recompile of any gcc
component. The error was in do_configure with cross-compilation badness
being detected in config.log files.
gcc is different in that many of the config.log files are generated during
the do_compile phase. This means this host contamination issue has always
been present but only shows up on a rebuild.
The fix is to force the appropriate configuration variable to "none required"
then gcc won't look in the bad locations.
[YOCTO #2279]
(From OE-Core rev: e7135f14f3ef37f93f5c28b319464f3d6dd9b8da)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the toolchain is reused from sstate and ccache is installed, build failures
were occuring due to gcc trying to access the original sysroot rather than the
new one, particularly if the old sysroot existed but was not readable by the
current user.
This turns out of the an issue inside gcc to do with preservation of the sysroot
option. See the gcc patch for more details. It only triggers when preprocessed
sources are used which happens when ccache is used.
The same issue occurs with c++ and c++-cpp-output so the same fix is applied there.
[YOCTO #2074]
(From OE-Core rev: d3a3e81869631ba69874f6fc172240e3aac388f5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This Fixes [Ycoto #2223] bug.
The gcc osdir is obtained in the do_install by invocation of
command "gcc -print-multi-os-directory". For x32 it returns gcc
osdir for the default abi which is x86_64. Fix this by adding
target abi parameter to the gcc command line to get correct gcc
osdir with invocation of command "gcc -mx32 -print-multi-os-directory"
(From OE-Core rev: e65b6a4282d5c4882d0565b79ccba99db90161ff)
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This fixes multilib issues if you try for example to use a BASELIB of /lib32
which wouldn't work without this change since the compiler install location
is taken from gcc -print-multi-os-directory which can still turn out to be
"/lib".
The reason is that a 32 bit gcc has no multilib code enabled and will always
return "." as that value rather than "../${base_libdir}" which our changes
to gcc enable and return in 64 bit mode.
(From OE-Core rev: cc953e2259bf77e9e1f7a1e3d0dbe1509c79477e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Cleaning up non shipped empty directories.
(From OE-Core rev: e2fd32919e1d96136528c61677bdfeee2b064320)
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit 7893e74311e53882d8f93ecb95a6bd9f5b14651e since it breaks
the builds.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are several invalid symlinks in gcc-cross-initial,
gcc-cross-intermediate and gcc-cross, these cause the error:(56 errors)
tmp/work/i586-poky-linux/gcc-cross-initial-4.6.3+svnr184847-r23/temp/log.do_populate_sysroot:
log.do_populate_sysroot:grep: /path/to/invalid/symlink: No such file or directory
Avoid creating invalid symlinks would fix this problem.
Use the:
[ ! -e file ] || do_something
But not use:
[ -e file ] && do_something
is because that if the "file" doesn't exist, then the whole statement
would return false, and bitbake treats this an error, so use the "||" to
let it always be true.
[YOCTO #2095]
(From OE-Core rev: 7893e74311e53882d8f93ecb95a6bd9f5b14651e)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
core-image-sato/core-image-minimal builds and boots
on all qemu machines
(From OE-Core rev: 40d7a4b70d342f75e13de7872fb62e2b9d6d40bf)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using "1" with getVar is bad coding style and "True" is preferred.
This patch is a sed over the meta directory of the form:
sed \
-e 's:\(\.getVar([^,()]*, \)1 *):\1True):g' \
-e 's:\(\.getVarFlag([^,()]*, [^,()]*, \)1 *):\1True):g' \
-i `grep -ril getVar *`
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
dash does not like >& so be explicit and say 2>&1
(From OE-Core rev: 1d262630853e65be9167d904b934b581acf64182)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We have various variables which are either not quoted at all or are half
quoted. This patch fixes the bad exmaples so everything is consistent.
(From OE-Core rev: 30253358f5e76fb7b25be27198b4c125e0dbdf2c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Corrected the error introduced by commit afb400e of dropping
DATE/SRCDATE out of the vardepsexlude list of do_patch.
(From OE-Core rev: 6546096d068b51cc9cf4557cdb35aee6f62838d5)
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ensure do_patch have the same sstate hashes for nativesdk variants of
gcc family recipes, since they share the same source directory.
(From OE-Core rev: afb400e9c3ddac604906bde44df5da29a6c134d9)
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
a) Use the system zlib to avoid building it for each gcc.
b) -initial and -intermediate don't need plugins or lto-plugin
so disable them.
(From OE-Core rev: a124a0883507caf4ffb7e25be666f6781b30abdd)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Dont use -q to grep we pipe to /dev/null anyway all we
care is the return status of grep
(From OE-Core rev: 9c575b5f37ee53eaf26bfdc468d4cbb661db703f)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Skip the staticdev QA test since the static archives belong
with the -dev.
(From OE-Core rev: 3de810a7f745b253d4b63eea353a31514d64a2e3)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
gcc-cross is installed into a package architecture specific directory
and is not meant to be machine specific. This patch replaces MACHINE_ARCH
with PACKAGE_ARCH to ensure this is really the case.
This was found by examining sstate checksums.
(From OE-Core rev: b3ca57418f47b16ed0a63d3291bf7d31e3ca5a45)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Changes in WORKDIR were changing the do_patch stamps between gcc-crosssdk
and gcc-cross. This excludes the variable since in this case, we don't
need want those changes to affect the signatures.
(From OE-Core rev: 0de85d2ca3bc9674323302a35995dfddb6044a71)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Keep the *_nonshared.a in the libgcc-dev package as
required for linking, moved the other *.a libraries
into their respective packages (libstdc++ and libssp).
(From OE-Core rev: c2838d949ffd15282c72551b40c5fd81d0db1fa0)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
libgcov.a is moved to it's own libgcov-dev package, instead
of being part of libgcc-dev.
(From OE-Core rev: a82a3f8ec55e68a003420549392d638e565562fc)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This was duplicated from the main SRC_URI and was causing incorrect
task signatures. This simply removes the duplication.
(From OE-Core rev: cc8d02c582a72d07fd08c59d14ee5720e01a5cd9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These tasks don't do anything, this just avoids the overhead of forking
to exec them.
(From OE-Core rev: 6708b3e908ae383922703390ac2d39f40348e1b3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The fetch/unpack/patch/headerfix tasks are shared and hence their sstate hashes
should also match. Sadly this is not the case since:
a) gcc-runtime applies an additional patch
b) The do_headerfix task was missing from libgcc
c) The do_headerfix task is a shell task and hence depends
on all exported variables which can vary between cross and target
recipes.
To fix this, the patch moves the patch to the common code, adds
the headerfix task to a common include file and disabled shell
dependencies on the do_headerfix task since its clear in this case
we don't need thsoe dependencies since we just call sed.
With this patch applied, all these recipes now share common sstate checksums.
(From OE-Core rev: 2c4569801a710f34a695b8d2a0ee7fc127fb34e4)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some patches were missing Upstream-Status informantion,
this commit adds that in those patches.
(From OE-Core rev: 01c3669856538eb34d329780e03df2dc7fb985f2)
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
This script will be generated into the build directory of gcc-cross
It should be testing gcc and g++. libstdc++ tests are not run since
we build them as part of gcc-runtime but we can test them here by
building them with 'make all' and then running the tests
The script expects passwordless ssh access to target and is used
in form
./arm-oe-linux-gnueabi-testgcc kraj@192.168.7.2
inside the builddir of gcc-cross
(From OE-Core rev: 130b534fdb0b292158981a12d7d5f01c1a14cb2a)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Right now for cross recipes e.g. gcc-cross and binutils-cross
we specify --disable-nls .... --enable-nls on configure cmdline
the --enable-nls coming from gettext bbclass.
So we disable nls for all cross inheriting recipes in gettext
bbclass and then we remove the extra --disable-nls in gcc-cross
and binutils-cross
This patch needs testing. Please help
(From OE-Core rev: d66b379f809b9c75981848fcc71ed5de13382bf7)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch is a backport of http://patchwork.ozlabs.org/patch/110517/
(From OE-Core rev: 048c31c4e19d1bb060c79011cb25dfeff51c3ef1)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make get_gcc_multiarch_setting more elegant. Use a dictionnary
to store the config options and replace bb.data.getVar with d.getVar.
Remove i686 from the architecture list because it doesn't seem
to be a valid TARGET_ARCH any more in OE.
Configure gdb (gdb and gdb-cross) with --enable-64-bit-bfd if
multiarch DISTRO_FEATURE is present
(From OE-Core rev: 0b42b2fc118bef8ce0d1473b146673182f5d1f78)
Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch introduces a distro feature which enables gcc to produce
both 32bit and 64bit code, and enables binutils to operate on both
32bit and 64bit binaries. It differs from multilib toolchains in
that it does not require to compile a version of the libc for each
architecture variant. However, the code produced for the secondary
architecture will not be linkable against the libc.
v2: - Renamed the feature name from "biarch" to "multiarch". The GCC
installation manual claims that the mips-linux can be made a tri-arch
compiler (http://gcc.gnu.org/install/configure.html)
- For x86_64, the compiler is made bi-arch by default, so nothing
has to be done in particular.
- I analyzed the gcc/config.gcc from GCC sources and added in this
patch all the architectures that could be made biarch with the version
of gcc currently used in OE, which are powerpc, and sparc, in addition
to x86. mips and s390 will probably be supported in future versions of
gcc. For x86 and sparc, only the --enable-targets=all option is valid
to make this work (this option doesn't have any other side effects than
making the compiler bi-arch). For powerpc, I used the
--enable-targets=powerpc64 option (although 'all' also works).
Note: - Untested on powerpc and sparc. But I believe it works the same
as with x86.
- gcc in meta-toolchain is also made multiarch.
(From OE-Core rev: 99e295ef30ba02db3966c66619807c037ef5089f)
Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When I was trying self-hosted-image, eglibc's do_install failed in the target:
ERROR: cannot stat bootparam_prot.h:
the cause is: rpcgen doesn't work properly: rpcgen can't exec /lib/cpp since
it doesn't exist.
According to http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/lib.html:
"if a C preprocessor is installed, /lib/cpp must be a reference to it, for
historical reasons. The usual placement of this binary is /usr/bin/cpp".
Typical distros, like Ubuntu, openSuSE, Fedora and RHEL, all comply with
the rule.
Actually in meta/recipes-devtools/gcc/gcc-package-target.inc, we do try to
package ${base_libdir}/cpp:
FILES_cpp = "\
${bindir}/${TARGET_PREFIX}cpp \
${base_libdir}/cpp \
${libexecdir}/gcc/${TARGET_SYS}/${BINV}/cc1"
But unluckily we didn't create a symbol link in do_install.
This patch adds the symbol link.
(From OE-Core rev: 58fb9fbce2af05a469691390e75aebb2de16ca96)
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Backport fix for PR 47551 fixes the ICE seen on armv7-a/qt4-x11-free
Bump up SRCREV past gcc 4.6.2 release
(From OE-Core rev: dd2fdf9f5a3923c37e4ea2e46e347bb0657c2f5b)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(From OE-Core rev: da7bf75bcdd5759a0f551dcb7a0326aa2f40921c)
Signed-off-by: Michael Brown <Michael_E_Brown@dell.com>
Port patch from base openembedded. Since 4.6 already has fixes for config.gcc,
the fix only requires a one line change to gcc-cross4.inc.
The patch was imported from the OpenEmbedded git server
(git://git.openembedded.org/openembedded) as of commit id
3aa8afe97e9cf1340feb9c4442a6ed88b7e32c96.
gcc-4.5: Fix toolchain builds for SH4/SH3
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This fix is needed for gold to work. Otherwise
connman fails to build since it used hidden weak
symbols.
See
http://gcc.gnu.org/bugzilla/PR32219http://www.cygwin.com/ml/binutils/2008-02/msg00239.html
The fix proposed to gcc had reviews which were not addressed hence the
patch is not yet
applied to gcc upstream.
connman can also have workaround by changing the visibility of these
symbols to be default
__attribute__ ((weak, visibility("hidden")))
to
__attribute__ ((weak, visibility("default")))
in include/plugin.h
(From OE-Core rev: 3cb2b003db7371b3a47d02c08352a262e1e419b4)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We force the C locale when running builds for determinstic error messages. We
therefore have no need to NLS support in binutils cross or gcc cross.
We also don't need the standard base/autotools dependencies for our
toolchain components since we don't autoreconf these.
This patch turns off nls and cleans up some of the dependencies resulting
in a slightly less convoluted set of build dependencies.
(From OE-Core rev: 54a3e2ee37003fc56af0339f857b0b6442790c26)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Depending upon what hash style is in use this uses
the right flag for setting the hash style type. This
fixes the QA errors about missing GNU hash style reported
in gcc-runtime build particularly libgcc
(From OE-Core rev: f8edd9b872bcf14da037bd0b501ccc8c6fcc79bf)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
a) There is a QA warning from a .so being present in a main package.
In the case of the plugin library for gcc, this is allowed.
b) Remove the unwanted libiberty.a file with the strange path. We
don't need/want this and this removes an unpackaged file warning.
(From OE-Core rev: ca36a3edf9cede9fa0d73ba1a9538ab467cb5e3c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
First, this lib is usefull for coverage analysis-enabled building.
Second, this fixes the warning about unpackaged files in libgcc recipe.
(From OE-Core rev: 2a807a98d8be3f486e703321773db32657c71d9e)
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Long time ago a066e7ca90a28d5681c5fa895a29e999ed7c88b was committed to
address possible problems with compilation of nscd during
eglibc-nativesdk build. Problems were related to the way gcc searches
for headers to check if it should enable it's own stack smash protection
bits or it can relay on eglibc for it.
However after 934d38530c9a67562e53d4034aee5531f0f26750 things got
broken, as for gcc-crosssdk-intermediate packages:
1) EXTRA_OECONF is ignored
2) headers are installed in a different location than expected by that
patch.
This results in eglibc-nativesdk build broken on some systems (e.g. mine
Debian x86_64 squeeze). Fix that by providing with-headers options to
crosssdk-intermediate gcc configuration.
(From OE-Core rev: 63494d638b7a9b88a5b7d7a02d2afcb3aa0fa064)
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #1381]
This patch came from from GCC Bugzilla via Khem
Cc: Khem Raj <raj.khem@gmail.com>
(From OE-Core rev: 61dac2f6f68bc46d8f3f6f7a8757924f103c7c54)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Commit 35fa8dc5f7 changed the gcc recipes to use
baselib for the compiler location. This is fine as long as baselib happens to
match the platform multilib definition which is enabled at the time.
This patch fixes things so that gcc will honour whatever ${base_libdir} is
set to re-allowing suitable customisation of the system layout.
[YOCTO #1362]
(From OE-Core rev: bc5f293b151b9ba0d6660814d88ee5041efce318)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The gcc-poison-parameters was added specifically to deal with an issue
on ppc targets and a bug when we build with -Os -frename-registers.
This bug below reports the issue and is fixed in gcc-4.6.x/mainline:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618
Backport patch to gcc 4.5.1.
(From OE-Core rev: fef385e37e82a0eec743fbd1da11021b9e7158b5)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The gcc-poison-parameters was added specifically to deal with an issue
on ppc targets and a bug when we build with -Os -frename-registers.
This bug below reports the issue and is fixed in gcc-4.6.x:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618
(From OE-Core rev: 0fabe078a31591f41c3fdabe5aa9de1111ef82c7)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes bug [YOCTO #1386]
1) Add the following lines to conf/local.conf:
SDKGCCVERSION="4.5.1"
GCCVERSION="4.5.1"
2) bitbake meta-toolchain
The we will notice the error that sed can't find the directory:
${TMPDIR}/work-shared/gcc-${PV}/gcc-${PV}-${PR}
we had changed the name of S from gcc-${PV} to gcc-${PV}-${PR}, but didn't
update meta/recipes-devtools/gcc/gcc-common.inc, so fix S in gcc-common.inc
would make it work.
(From OE-Core rev: 282773ff3e0f365c08ae7e8fe759029f33e575b1)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some place pnum=1 is used which is removed as well since
striplevel=1 is default
(From OE-Core rev: 4e108857e0d40105f7ecbc55e99bd6c367bb7386)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
libgcc now uses shared work directories so we cannot mark
these tasks as noexec. If we do, the tasks may not run
and hence gcc may not get patched for example which
results in failures.
This patch simple removes the flags since they're unneeded.
(From OE-Core rev: e2c03b2a80efeeea2298bdba385671d0ae208e95)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We ensure that:
* the shared work directory contains PR and ensure PR values are consistent across gcc builds
* the regexp to handle library directories is in a specific task and run once
This avoids breakage that was seen in incremental builds after commit
be1f70d68b where the interpretor could
become corrupted. This was due to the sed expression corrupting
the source directory.
(From OE-Core rev: 970af6b09e1d69041b0d82fa56ace19543405eb1)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rather than tweaking MULTILIB_DIRNAMES & MULTILIB_OSDIRNAMES like is
done for x86-64 via 64bithack.patch. We can just go with gcc defaults
and utilize ${base_lib} for where to find gcc libs.
(From OE-Core rev: cfcc282efef30ea1988ccbe14835254a999584ea)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Implements basic e5500 enablement in gcc, with a scheduler, -mcpu
flag, etc...
(From OE-Core rev: b4f6fb7033d3798cae32d42bce5a0f8402ad57c1)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The sed regex in do_configure_prepend was producing the following result:
#define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR "/lib64/ld-linux-x86-64.so.2"
instead of removing the leading "/lib" or "/lib64".
Now we have it do:
#define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR "ld-linux-x86-64.so.2"
Additionally, with the regex fixed the manipulation of SYSTEMLIBS_DIR
needs to be removed.
(From OE-Core rev: b343436d03fa5690b16ee8ef5d4a738c5194b301)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since we now handle GLIBC_DYNAMIC_LINKER in gcc-configure-common.inc:
's#\(GLIBC_DYNAMIC_LINKER[^ ]*\)\( *"/lib.*\)#\1 SYSTEMLIBS_DIR\2#'
we can drop the patch which changes a hardcoded value for this.
No PR bump since there is no code change resulting from this, its just
a cleanup.
There is still a valid question over the remainder of this patch and its
interaction with multilib configurations.
(From OE-Core rev: 036faf66c3889cd8bf4cd3c9b97c80f008f3c6e2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch adds the core multilib class which can be used along with a
parameter specifying the mutlilib to use in BBCLASSEXTEND.
The MLPREFIX variable is added and can be used in cases where its too
difficult to dynmaically work out where a mutltilib prefix is needed
to be added to a variable.
This includes:
* SHLIBSDIR and PACKAGE_ARCH fixes from Lianhao Lu.
* PACKAGE_DYNAMIC mapping from Yu Ke
* PACKAGE_INSTALL mapping from Yu Ke
* RPROVIDES mapping from Yu Ke
* TARGET_VENDOR fix from Mark Hatle
* Ignorning *-native-runtime dependnecies as well as *-native from Yu Ke
* Map PKG and ALLOW_EMPTY from Dongxiao Xu
* Ensure RCONFLICTS and PKG field dependencies are remapped (from Dongxiao Xu)
* Ensure PN and MLPREFIX are set at the same time to ensure consistent BPN values (Yu Ke)
(From OE-Core rev: 5d9453049915db48ec4b5972e12287417ebb61a2)
Signed-off-by: Yu Ke <ke.yu@intel.com>
Signed-off-by: Xu Dongxiao <dongxiao.xu@intel.com>
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The base gcc package is missing liblto_plugin.so. If we try a simple
hello world compile we get something like:
root@p5020-ds:~# gcc hello.c
gcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
compilation terminated.
We need to include liblto_plugin.so in the base gcc package and not
gcc-dev.
(From OE-Core rev: 282326a188467edf6caef21b07a7e51288674245)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the library is installed without execute permission then package.bbclass
will not consider it for stripping. This is particularly unfortunate because
there seems to be a bug somewhere else which is causing all DSOs to end up with
a NEEDED dependency on libgcc_s, even if they don't actually require it, and
hence it is getting installed in all images (for uclibc on i586 at least).
(From OE-Core rev: b3724a67ad70f509181555e6be98e1eb3b184bb7)
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add fix for PR45886 as proposed in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45886
(From OE-Core rev: d639fad9ce510e0a1c64c66bbda48b4a2436327b)
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add fix for PR45052 as proposed in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45052
(From OE-Core rev: 296b2e7d90f11dc50d8c2e90bd2062733fd3d47c)
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add fix for PR45094 as proposed in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45094
(From OE-Core rev: 2f1f920415dcf7f899d173352bf8924714352158)
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add fix for PR44606 as proposed in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44606
(From OE-Core rev: 5ec03dc1f80e437d5660aa3e0c7db9b561603d49)
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add fix for PR44290 as proposed in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290
(From OE-Core rev: 94311ba57cd95b6b163d162587c6318da8c3b16a)
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add fix for PR43810 as proposed in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43810
Building on powerpc-eabi* with --enable-target-optspace
still fails for me though.
(From OE-Core rev: 7dc3865dd88cec50e4fb0660ea678736ec0eb46c)
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The e500v2 core utilizes a unique floating point programming model / ABI.
We utilize TARGET_FPU = "ppc-efd" to distinguish this choice (Embedded
scalar single-precision floating-point). When building the toolchain for
this ABI we need configure gcc with --enable-e500_double.
(From OE-Core rev: 5136c4ad6279c1593301f6dde9b959ad26a2fd0f)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This fixes:
| rm: cannot remove `/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-4.5-r39.1+svnr175127/image/usr/libexec/gcc/arm-angstrom-linux-gnueabi/4.5.4/*.la': No such file or directory
| ERROR: Function 'do_install' failed (see /OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-4.5-r39.1+svnr175127/temp/log.do_install.19514 for further information)
NOTE: package gcc-4.5-r39.1+svnr175127: task do_install: Failed
(From OE-Core rev: 4db073061bdd1d3361ff90d309049a1621f06704)
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Set SRCREV to match the point at which 4.6.1 was released, update PV appropriately.
(From OE-Core rev: d575031f3bcd7acbc7dae25f17a60f0d493643fb)
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #1233]
This fix directly packages the contents in and adds the lib*.so
correctly to the -dev package.
(From OE-Core rev: d3c5f93714165e5c089ce80194f2be07e31d920c)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
gcc recipes has changed, currently ${PV} is 4.6 and ${BINV} is 4.6.1 version.
Fix these QA warnings.
WARNING: For recipe gcc-runtime, the following files were installed but not shipped in any package:
WARNING: /usr/share/gcc-4.6.1/python/libstdcxx/__init__.py
WARNING: /usr/share/gcc-4.6.1/python/libstdcxx/v6/__init__.py
WARNING: /usr/share/gcc-4.6.1/python/libstdcxx/v6/printers.py
(From OE-Core rev: e29a8601c7b028696527c70aa0d4862157ce2d81)
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, we stash libgcc if PN is gcc-cross or gcc-crosssdk. This patch
changes it to work for *gcc-cross and *-gcc-crosssdk which means it
will patch for multilib extended toolchains.
(From OE-Core rev: a39cbed2ec887fb83335ba93e92d971c84a0f4d8)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This avoids a QA error.
(From OE-Core rev: 6d284d656e129be526e272f61405d1b004fe0ec9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The changes in commit 553a92c442bc3a35d1520a22e640a3a0e377b8f7 were not applying correctly
due to the error: "find: paths must precede expression"
This patch corrects the find syntax.
[YOCTO #1199]
(From OE-Core rev: b8d72e3af93ff9e2808fef4fe7b9d00b68bf9715)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
But ensure that gcc-cross-intermediate always uses ld.bfd since
(e)glibc won't build with gold.
(From OE-Core rev: 207a9013670560d62c793a66f01e19f4760a71a8)
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Fix configure and Makefile to read the defaults.h and t-oe from ${B},
so that the ${S} can be shared.
* Change ${S} to the shared source directory.
(From OE-Core rev: c1ec5100da76d35afb91de7353599564e5b653dc)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix configure and Makefile to read the defaults.h and t-oe from ${B},
so that the ${S} can be shared.
(From OE-Core rev: d8c6f6e01421455db30eeb4b0882720874dcb31b)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patched is derived from Richard, make gcc use the shared source
directory during the different building:
1) Make gcc-cross, gcc-cross-initial, gcc-cross-intermediate and
gcc-runtime share the same source directory.
2) The source directory is ${TMPDIR}/work-shared/gcc-${PV}, for example:
tmp/work-shared/gcc-4.5.1
3) Fix do_clean to clean the shared source directory and stamps
4) gcc uses sed and creates config files against ${S} which means the
directory should not be shared. Change the way to make it work:
* The configure option --with-headers=${STAGING_DIR_TARGET}${SYSTEMHEADERS}
can replace the sed command, see the code in configure:
if test "x$with_headers" != x; then
glibc_header_dir=$with_headers
This has the same effect as the sed command:
sed -i 's:^\([ ]*\)glibc_header_dir=\"${with_build_sysroot}/usr/include\": ...
so add the --with-headers=${STAGING_DIR_TARGET}${SYSTEMHEADERS} to
gcc-configure-cross.inc( not add to gcc-configure-common.inc, since
not all the gcc building need this, the one which has its own do_configure
doesn't need it).
* Move t-oe from ${T} to ${B}/gcc, so that the patched Makefile.in
can read it easily, please see the commit for gcc-4.5.1 and
gcc-4.6.0.
* Use the defaults.h in ${B}/gcc instead of ${S}/gcc, and the patched
configure.ac(configure) can read it correctly, please see the
commit for gcc-4.5.1 and gcc-4.6.0.
* The gcc-crosssdk.inc used sed to edit ${S}/config/*/linux*.h
to change the GLIBC_DYNAMIC_LINKER, which made the source
incompatible. To make the source compatible:
- Use:
sed -i ${S}/gcc/config/*/linux*.h -e \
's#\(GLIBC_DYNAMIC_LINKER[^ ]*\)\( *"/lib.*\)#\1 SYSTEMLIBS_DIR\2#'
so entries in the files that look like:
#define GLIBC_DYNAMIC_LINKER64 "/lib64/ld-linux-x86-64.so.2"
would become
#define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR"/ld-linux-x86-64.so.2"
and we define SYSTEMLIBS_DIR in defaults.h.
NOTE:
#define GLIBC_DYNAMIC_LINKER64 (SYSTEMLIBS_DIR "/ld-linux-x86-64.so.2")
doesn't work in in the following define:
#define LINUX_DYNAMIC_LINKER \
CHOOSE_DYNAMIC_LINKER (GLIBC_DYNAMIC_LINKER, UCLIBC_DYNAMIC_LINKER)
so use
#define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR"/ld-linux-x86-64.so.2"
5) Add do_configure_prepend to gcc-configure-common.inc and remove the
one in gcc-crosssdk.inc, this makes it easy to share the source,
otherwise we need do extra changes in gcc-configure-sdk.inc.
6) Use "cat > file <_EOF" to replace the "echo > file"
(From OE-Core rev: 934d38530c9a67562e53d4034aee5531f0f26750)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The versioned gcc binary gets installed and the needed binutils symlinks are made.
To make it fully work again the following is needed in kernel recipes/classes:
PATH_prepend = "${STAGING_BINDIR_TOOLCHAIN}.gcc-cross-kernel:"
(From OE-Core rev: 3f0ee65462acf199b69ed18897ca65755907340e)
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Most of the files that end up in the gcc include dir and other
misc files scattered throughout the install get the build users
uid and gid.
(From OE-Core rev: db99a65b3e93dfacc27ea821c788f15b5de3a497)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I've added more licenses from SPDX and corrected the gcc license
so that it is a. parsable and b. accurate to the SPDX standard.
I've also done some cleanup of license text and gdb's LICENSE
field.
(From OE-Core rev: e47343d12ee571281238bbf5663b074c0e32049f)
Signed-off-by: Beth Flanagan <elizabeth.flanagan@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This brings in new patches from 4.6 release branch
updates the comment section of existing branch to not
contain patch numbers.
Tested build on qemu for arm ppc mips x86 and x86_64
(From OE-Core rev: 3968f33b6542cf20cf63cf49bfbc033bd2486295)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit c553b3934f45db8a6e77cfc7673787db3cc64f85.
This change clearly breaks builds since subsequent patches
depend on changes this patch removes. Not sure what's going
on here but this change isn't correct.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
.. since this is where collect2 seems to look for them. This seems like
it is really a bug in collect2, but installing the symlinks is an easy
workaround. Without this you get "could not find ld" errors when using -flto.
(From OE-Core rev: d69561d80a995a52f3c7abfdbfd183fc7846046d)
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #1130]
This patch brings in a patch from gcc for the following issue:
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01477.html
(From OE-Core rev: 347c30801b6f935a6aefa5578d723a8afcf52790)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
python: update upstream-status for patches
binutils: update upstream-status for patches
gcc 4.5.1 4.6.0: update upstream-status for patches
autoconf: update upstream-status for patches
automake: update upstream-status for patches
bison: update upstream-status for patches
distcc: update upstream-status of patches
fstests: update upstream-status for patches
gdb: update upstream-status of patches
intltool: update upstream-status of patches
libtool: update upstream status of patches
linux-libc-headers: update upstream-status for patches
make: update upstream-status for patches
perl: update upstream-status for patches
python-pycurl: update upstream-status for patches
python-pygobject: update upstream status for patches
python-pyrex: update upstream-status for patches
quilt: update upstream-status of patches
tcl: update upstream-status for patches
gnu-config: update upstream-status for patches
gmp: update upstream-status for patches
(From OE-Core rev: a62fa9b213b09bf48c48499d2e3c66a9ee306deb)
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The liblto_plugin.so file is not packages for the target recipe causing this
gcc failure on the target.
gcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
(From OE-Core rev: a121494f9bdebb940e3f2f121040988be6dca592)
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When TARGET_PREFIX and TARGET_SYS didn't match up, the symlinks we made
were invalid. TARGET_PREFIX is what we use when configuring so it's what we
should be using here.
This is 05143e9b5d0a42e32ee0dd3c7fde482ff8d63f63 from OE.
(From OE-Core rev: c0d6ba1ead3e68509718bea09d0b4d5a49a5f73e)
Signed-off-by: Tom Rini <tom_rini@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is set of bugfixes that has been done on
FSF gcc-4_2-branch since 4.6.0 was released
They will roll into 4.6.1 release once that
happens in coming approx 6 months time then
we can simply remove them thats the reason
so use a separate .inc file to define the
SRC_URI additions
(From OE-Core rev: b0d5b9f12adbce2c4a0df6059f5671188cd32293)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Matthew McClintock
Kartik Mohta
Richard Purdie
Khem Raj
Robert Yang
Saul Wold
Andreas Oberritter
Nitin A Kamble
Lianhao Lu
Dmitry Eremin-Solenikov
Julian Pidancet
Dexuan Cui
Michael Brown
Kumar Gala
Phil Blundell
Ilya Yanok
Koen Kooi
Phil Blundell
Mark Hatle
Beth Flanagan
Tom Rini