summaryrefslogtreecommitdiff
path: root/meta/recipes-devtools/gcc/gcc-4.9.inc
AgeCommit message (Collapse)AuthorFiles
2016-05-14gcc 4.9: backport gperf fixesDan McGregor1
From: Daniel McGregor <daniel.mcgregor@vecima.com> gperf was being used in a way that generated files don't conform to the language standard. Backport the fix from upstream. This is required to build these GCC versions when the host compiler is GCC 6. Signed-off-by: Daniel McGregor <daniel.mcgregor@vecima.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-05-11gcc: obey ldflags in the link of libgccChristopher Larson1
Explicitly obey it, the way it should, rather than only relying on --with-linker-hash-style. Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-03-30gcc-5.3/gcc-4.9: -fdebug-prefix-map support to remap relative pathHongxu Jia1
For relative path in DWARF, -fdebug-prefix-map could not remap it, so translate to real path before mapping. [YOCTO #9305] Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-03-20gcc-5.3/gcc-4.9:Reuse -fdebug-prefix-map to replace -ffile-prefix-mapHongxu Jia1
The oe-core may use external toolchain for compiling, which did not support -ffile-prefix-map. Since we use -fdebug-prefix-map to do the same thing, so we could reuse it to replace -ffile-prefix-map. [YOCTO #7058] Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-03-20gcc-5.3/gcc-4.9:replace build path with target path in __FILE__Hongxu Jia1
Similar -fdebug-prefix-map, add option -ffile-prefix-map to map one directory name (old) to another (new) in __FILE__, __BASE_FILE__and __builtin_FILE (). With this patch, it fixes build path issue which caused by __FILE__. We do not need to use relative path to compile any more. [YOCTO #7058] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268 Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-02-18gcc-4.9/5.3: Ignore -fdebug-prefix-map in producer stringHongxu Jia1
Backport from upstream master. The discussion detail: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69821 Compile without this fix: objdump -g packages-split/lib32-glibc-dev/usr/lib/gcrt1.o ... | <5f> DW_AT_producer : (indirect string, offset: 0x1b): GNU C99 5.3.0 -m32-march=core2 -mtune=core2 -msse3 -mfpmath=sse -mpreferred-stack-boundary=4 -g -O2 -std=gnu99 -fgnu89-inline -fdebug-prefix-map=/buildarea/raid0/hjia/buil d-20160127-yocto-buildpath-2/tmp/sysroots/lib32-qemux86-64= -feliminate-unused-debug-types -fmerge-all-constants -frounding-math -ftls-model=initial-exec ... Compile with this fix: objdump -g packages-split/lib32-glibc-dev/usr/lib/gcrt1.o ... | <5f> DW_AT_producer : (indirect string, offset: 0xa1): GNU C99 5.3.0 -m32 -march=core2 -mtune=core2 -msse3 -mfpmath=sse -mpreferred-stack-boundary=4 -g -O2 -std=gnu99 -fgnu89-inline -feliminate-unused-debug-types -fmerge-all-constants -frounding-math -ftls-model=initial-exec ... [YOCTO #7058] Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-29gcc: fix hidden weak symbols by removing buggy gcc patchMathieu Desnoyers1
We are noticing the presence of the following patch in various openembedded gcc versions: 0024-PR-target-32219.patch However, contrarily to its "Backport" status, that patch is not upstream in gcc, and it breaks handling of start/stop automatic weak hidden symbols we use in lttng-ust. We are only experiencing problems on the various openembedded compilers, but on no other distro (with same compiler versions), which led us to suspect a buggy distro-specific gcc patch. We've been testing with openembedded gcc-4.9.2-r0. Rebuilding the gcc compiler with this patch removed fixes the lttng-ust issue. Link: http://lists.openembedded.org/pipermail/openembedded-core/2016-January/116306.html Link: http://lists.lttng.org/pipermail/lttng-dev/2014-May/023112.html Link: https://gcc.gnu.org/ml/gcc-help/2014-05/msg00042.html Link: http://cgit.openembedded.org/openembedded-core/commit/?id=3cb2b003db7371b3a47d02c08352a262e1e419b4 Link: https://sourceware.org/bugzilla/show_bug.cgi?id=15435 Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2015-12-12gcc: Add support for building musl configurationKhem Raj1
Most of these patches are already in gcc 6.0/master but we still need them for older gcc, they have been tested in meta-musl for quite some time Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2015-12-12gcc-4.9: import patch fixing compilation in thumb modeDmitry Eremin-Solenikov1
Import patch fixing a bug that caused ICE when compiling some packages (e.g. ICU) in Thumb-1 model. Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2015-12-08package_regex.inc: split entries which blacklist specific versions to their ↵Alexander Kanavin1
recipes Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2015-11-25gcc-4.9: Fix various _FOR_BUILD and related variablesJuro Bystricky1
This patch is based on the patch for gcc-5.2 (41cbfd7af60f93a4bd496b7b6bf477215a286950) When doing a FOR_BUILD thing, you have to override CFLAGS with CFLAGS_FOR_BUILD. And if you use C++, you also have to override CXXFLAGS with CXXFLAGS_FOR_BUILD. Without this, when building for mingw, you end up trying to use the mingw headers for a host build. The same goes for other variables as well, such as CPPFLAGS, CPP, and GMPINC. Signed-off-by: Juro Bystricky <juro.bystricky@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2015-10-19gcc-4.x: fix wrong warning when using the universal zero initializer {0}Kai Kang1
When I upgrade efivar to 0.21, it fails to compile with error messages: | linux.c:850:9: error: missing braces around initializer [-Werror=missing-braces] | struct ifreq ifr = { 0, }; | ^ It is a known issue of gcc. Backport patch from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119 to fix wrong warning when using the universal zero initializer {0}. Signed-off-by: Kai Kang <kai.kang@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2015-07-31gcc: Add patch to handle on target multilibs betterRichard Purdie1
On target multilibs did not work properly since gcc-cross-canadian was only searching a limited number of sysroot directories to find multilib target binaries. This adds an extra search path to ensure those binaries are found and our gcc-cross-canadian works everywhere we need it to, e.g. with mips trilib configurations. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-07-31gcc: Add support for nativesdk-gccRichard Purdie1
Being able to build a nativesdk gcc is useful, particularly in cases where the host compiler may be of an incompatible version (or a 32 bit compiler is needed). Sadly, building nativesdk-gcc is not straight forward. We install nativesdk-gcc into a relocatable location and this means that its library locations can change. "Normal" sysroot support doesn't help in this case since the values of paths like "libdir" change, not just base root directory of the system. In order to handle this we do two things: a) Add %r into spec file markup which can be used for injected paths such as SYSTEMLIBS_DIR (see gcc_multilib_setup()). b) Add other paths which need relocation into a .gccrelocprefix section which the relocation code will notice and adjust automatically. This patch adds tweaks to the relocation script to handle the new section too. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-07-12gcc: remove EXTRA_OECONF_INTERMEDIATERobert Yang1
The gcc-intermediate had been gone, so remove EXTRA_OECONF_INTERMEDIATE. Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-07-12gcc-4.9: Upgrade to 4.9.3Khem Raj1
Drop upsteamed patch for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66483 which is already in 4.9.3 rename 0063-Use-SYSTEMLIBS_DIR-replacement-instead-of-hardcoding.patch to 0062-Use-SYSTEMLIBS_DIR-replacement-instead-of-hardcoding.patch to keep the sequence Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-05-09gcc-4.9, gcc-5: Use variable SYSTEMLIBS_DIR instead of hardcoding it for aarch64Khem Raj1
Change-Id: I54dc82a569f02d489137d88f16d6b768c4ab779b Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-04-24gcc-4.9: backport from gcc trunk r212178Stefan Müller-Klieser1
When compiling meta-toolchain-qt5 on cortexa8, the compiler throws an internal compiler error: ... qttools-opensource-src-5.3.2/src/linguist/shared/po.cpp: In function 'bool loadPO(Translator&, QIODevice&, ConversionData&)': qttools-opensource-src-5.3.2/src/linguist/shared/po.cpp:717:1: internal compiler error: in add_stores, at var-tracking.c:6000 ... Tracking this down led to https://bugs.linaro.org/show_bug.cgi?id=534 It seems the bug is well know and fixed upstream. So backporting from trunk seems to be the right solution. This fixes the compiler problem on cortexa8 and does not seem to be very invasive. The original commit can be found at: git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@212178 138bc75d-0d04-0410-961f-82ee72b054a4 Signed-off-by: Stefan Müller-Klieser <s.mueller-klieser@phytec.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-02-15gcc: Upgrade 4.9.1 -> 4.9.2Khem Raj1
Delete backported patch which are present in 4.9.2 backport patched from upstream gcc trunk to fix [YOCTO #6824] Change-Id: Ia0067940471d4c5d9d62089bf6f18f3a9c2bfedd Signed-off-by: Khem Raj <raj.khem@gmail.com>
2015-01-28gcc: ensure target gcc headers can be includedPaul Eggleton1
There are a few headers installed as part of gcc-runtime (omp.h, ssp/*.h). Being installed from a recipe built for the target architecture, these are within the target sysroot and not cross/nativesdk; thus they weren't able to be found by gcc with the existing search paths. Add support for picking up these headers under the sysroot supplied on the gcc command line in order to resolve this. Thanks to Richard Purdie for giving me a number of pointers during fixing this issue. Fixes [YOCTO #7141]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2014-12-22gcc: Disable aarch64 multilib optionsMark Hatle1
We want to revert to default gcc behavior to support oe-core's ability to change the libdir. Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-11-06gcc: backport two patches to fix ICE in dwarf2out_var_locationJackie Huang1
The first patch fixes the ICE in dwarf2out_var_location, at dwarf2out.c. r212171: * except.c (emit_note_eh_region_end): New helper function. (convert_to_eh_region_ranges): Use emit_note_eh_region_end to emit EH_REGION_END note. * jump.c (cleanup_barriers): Do not split a call and its corresponding CALL_ARG_LOCATION note. But it introduced a regression issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63348 so backport the fix for the regression as well: r215613: PR rtl-optimization/63348 * emit-rtl.c (try_split): Do not emit extra barrier. Signed-off-by: Jackie Huang <jackie.huang@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2014-10-24gcc: poison default sysroot pathRichard Purdie1
Various pieces of the code assume that the --sysroot option gets passed into the compiler tools. By having a "sane" default, we don't always spot when this occurs and this can later show up as breakage in sstate, or in usage of the external toolchain. We've long since talked about poisoning the default such that it will break unless the correct option is specified. This patch does just that. If this patch causes something to fail to build, it most likely means the various compiler flags and commands are not correctly being passed through to the underlying piece of software and that there is a real problem that needs fixing, its not the fault of this patch. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-10-11gcc: backport patch for gcc bug 61144Saul Wold1
This fixes gcc bug 6144, which in my case exhibited itself as a kernel module that failed to load. This was because static platform_data structures were being corrupted with the optimiser being set to any value other than -O0. Originally-submitted-by: Peter Urbanec <openembedded-devel@urbanec.net> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-15gcc: backport patch affecting Linux kernel buildsPeter A. Bigot1
A long-standing bug in gcc turns out to cause problems with unpatched Linux versions due to improved optimization enabled by gcc 4.9. The upstream fix missed the gcc-4.9.1 cut-off. It's also been applied upstream to the 4.8 branch so is being added for OE's 4.8 as well. Signed-off-by: Peter A. Bigot <pab@pabigot.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-15gcc-4.9: Ensure c++ includes are in /usr/include/c++/${BINV}Peter A. Bigot1
Apply to gcc 4.9 the recent fix to the --with-gxx-include-dir override. Original OE-Core rev: 5a2ff3e8f7cd7a47a5ab4e581847ecc4df87fca Signed-off-by: Peter A. Bigot <pab@pabigot.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-15gcc: remove inappropriate patchPeter A. Bigot1
0037-gcc-4.8-PR56797.patch was originally added as an OE backport during 4.8.0. Upstream merged it in 4.8.1, and it was present in 4.9.0. The original patch still applies to 4.9.1 (and presumably 4.8.2), but now is modifying store_multiple_sequence instead of load_multiple_sequence (the two functions are nearly identical). It may or may not be necessary in store_multiple_sequence, but absent a bug report upstream supporting its application in this case, or a least an updated comment and upstream status in the patch, I think this patch should be dropped. Signed-off-by: Peter A. Bigot <pab@pabigot.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-15gcc: recipe whitespace changesPeter A. Bigot1
Consistent use of whitespace in multi-line assignment, with special focus on OECONF modifications. Quotes on separate lines, four-space indentation, one value per line. Signed-off-by: Peter A. Bigot <pab@pabigot.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-02gcc: Upgrade 4.9.0 -> 4.9.1Khem Raj1
Drop patches which are already available in 4.9.1 Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
2014-07-25gcc-4.9.inc: fix parallel building failureHongxu Jia1
In subdir 'gcc', Most C source files included config.h which was generated by a rule. But no related prerequisites was added to the C source compiling rule. There was potential building failure while makefile enabled parallel. The C source compiling rule used suffix rule '.c.o', but the suffix rule doesn't support prerequisites. https://www.gnu.org/software/make/manual/html_node/Suffix-Rules.html We used the pattern rule '%.o : %.c' to instead, and add the config.h as its prerequisite We also moved the '%.o : %.c' rule down to the 'build/%.o :' rule, which makes '%.o : %.c' rule doesn't override 'build/%.o :'. [YOCTO #6568] Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-29recipes-devtools: fix segfault in lib32-gcc with "." multilib_dirPaul Gortmaker1
When enabling a lib32-gcc in a 64 bit build, without doing any other configuration, the mutilib dir is unspecified, which is represented internally in gcc as "." and as such uncovers an invalid free on a non-malloc'd pointer. As suggested by the gcc folks, simply make sure the "." case is also stored in a malloc'd pointer, so that the intended runtime behaviour of the code remains unchanged. Patch has been accepted by upstream maintainers of gcc. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-01gcc: Clean up configure_prepend and fix for mingwRichard Purdie1
The do_configure_prepend was duplicated in gcc-4.X.inc and gcc-configure-common.inc leading to confusion when reading the resulting do_configure task where the file was processed twice. The only difference was the removal of the include line for gcc 4.8/4.9. On mingw were were seeing two issues, firstly that the if statements meant the values we wanted weren't being set, the second that the include paths were still wrong as there was no header path set. To fix the first issue, the #ifdef conditionals were removed, we want to set these things unconditionally. The second issue is addressed by setting the NATIVE_SYSTEM_HEADER_DIR variable here (it was already set in t-oe). Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29gcc: add patch to fix errors with Decimal64 typeAlexandru-Cezar Sardan1
[OE-core bug #6270] - https://bugzilla.yoctoproject.org/show_bug.cgi?id=6270 Signed-off-by: Alexandru-Cezar Sardan <alexandru.sardan-KZfg59tc24xl57MIdRCFDg@public.gmane.org> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-13gcc: remove usage of FILESPATHPetter Mabäcker1
Fixes [YOCTO #4497] Usage of FILESPATH is discouraged, since it can make recipes harder to bbappend. Instead FILESEXTRAPATHS should be used to extend the path. Signed-off-by: Petter Mabäcker <petter@technux.se> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-05gcc: Add 4.9 recipesKhem Raj1
(From OE-Core rev: f051216ea373f166016b15bbd2a2a6f136430372) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.25.1) at 2025-02-21 17:10:57 +0000