summaryrefslogtreecommitdiffstats
path: root/meta/recipes-devtools/gcc/gcc-crosssdk-initial_4.5.0.bb
AgeCommit message (Collapse)Author
2010-11-18gcc: upgrade from 4.5.0 to 4.5.1Nitin A Kamble
Removed these patches which are not needed anymore. gcc-4.5.0_to_svn_162697.patch.bz2 : All the commits in this patch is part of the 4.5.1 branch. So moving to 4.5.1 makes this patch obsolete gcc_revert_base_version_to_4.5.0.patch: moving to 4.5.1 removes need of this patch gcc-pr43698-arm-rev-instr.patch: upstream has this fix. Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
2010-09-30gcc: fix check for target libc ssp supportKevin Tian
gcc uses hardcoded path "${with-build-sysroot}/usr/include" to check target libc ssp support. Based on GLIBC version strings in features.h in that search path, gcc knows whether target (e)glibc implements stack protector itself. However this breaks meta-toolchain, which actually has target libc headers installed under {with-build-sysroot}/opt/... This way features.h is not found and thus gcc-crosssdk-intermediate thinks that target (e)glibc doesn't support ssp. Later when building eglibc-nativesdk, undefined reference to "__stack_chk_guard" occurs which was caused by: o eglibc do_configure found that gcc-crosssdk-intermediate supports ssp, and thus enable -fstack-protector for nscd o eglibc itself supports stack smash proctection for some architectures such as i386, x86-64, etc. It's expected to use its own method to provide stack protection, instead of relying on gcc. So eglibc rtld.os doesn't export __stack_chk_guard to other modules o then when installing nscd objects, gcc-crosssdk-intermediate sees the flag "-fstack-protector", while it thought this eglibc doesn't implement ssp itself, so gcc turns to the alternative to find a valid __stack_chk_guard exported. eglibc doesn'g export it, while gcc-crosssdk-intermediate itself disables libssp. Then the undefined reference happens. If enabling libssp for gcc-crosssdk- intermediate, it may also work-around this issue. But the ideal fix is still to replace hard coded path with the actual one where target libc gets installed. glibc-nativesdk doesn't encounter this issue because it thinks gcc doesn't support ssp, and thus doesn't enable "-fstack-protector" for nscd. Don't know the reason yet This fix [BUGID #366] Signed-off-by: Dexuan Cui <dexuan.cui@intel.com> Signed-off-by: Kevin Tian <kevin.tian@intel.com>
2010-09-27gcc: enable poison parameters detectionDongxiao Xu
If not configured with --enable-target-optspace, gcc will report errors if there is '-Os' optimization in parameters. This fixes [BUGID #342] Also add "--enable-target-optspace" option to arm gcc configuration. Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
2010-09-17 gcc: upgrade gcc for powerpc to version 4.5.0Dongxiao Xu
Fix one parameter order issue for base_contains function, which impacts glibc build under new gcc. Add new judge code to determine whether <altivec.h> is needed. This fixes the mpeg2dec build failure under new gcc. Use O2 as the optimization flag to tinylogin as it will meet segfault if compiled by gcc-4.5.0 when enable both frename-registers and Os options. Use O2 instead. Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
2010-09-08gcc_4.5.0: add --enable-poison-system-directories option to crossNitin A Kamble
recipes Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
2010-08-27Major layout change to the packages directoryRichard Purdie
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>