Age | Commit message (Collapse) | Author |
|
Backport a patch to fix miscompilation on mips64.
We've observed strange behaviour of `systemctl status <xxx> on qemumips64.
The output of the command is like `systemctl show <xxx>', which is incorrect.
The problem is due to the miscompilation of gcc for mips64 platform, thus
backporting patch from upstream to fix this problem.
[YOCTO #12266]
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
This reverts commit b656fd9267b1f36d46ca20a1c0bcfaedbf7df438.
|
|
Backport
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82445
Fixes [YOCTO 12297]
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
We've observed strange behaviour of `systemctl status <xxx> on qemumips64.
The output of the command is like `systemctl show <xxx>', which is incorrect.
This patch is from gcc bugzilla's attachment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81803
The patch hasn't been merged into gcc. But it does solve the above problem.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
seen during kernel compile
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Fixes
internal compiler error: Max. number of generated reload insns per insn is achieved (90)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Use ucontext_t not struct ucontext in linux-unwind.h files.
Current glibc no longer gives the ucontext_t type the tag struct
ucontext, to conform with POSIX namespace rules. This requires
various linux-unwind.h files in libgcc, that were previously using
struct ucontext, to be fixed to use ucontext_t instead. This is
similar to the removal of the struct siginfo tag from siginfo_t some
years ago.
Backport of patches by Joseph Myers, taken from
https://gcc.gnu.org/viewcvs/gcc?limit_changes=0&view=revision&revision=249957
[YOCTO #12083]
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Drop upstreamed patches
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Under some rare circumstances we may end up with GCC segmentation fault.
This was observed with versions of sysmacros.h, which contain macros
with embedded warning messages :
When trying to actually display the warning, we may end up with a segmentation
fault instead. The reason is the actual warning message gets parsed (the text is
unquoted) and words in the message such as "not", "and" etc. are interpreted as
operators CPP_NOT, CPP_AND. When the time comes to display the warning, the code
uses wrong structure to access the "name" corresponding to the operators.
[YOCTO #11738]
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
All recipes which include this are using gcc as product name in NVD like
https://nvd.nist.gov/vuln/detail/CVE-2015-5276
Signed-off-by: Mikko Rapeli <mikko.rapeli@bmw.de>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
If we used -fuse-ld gcc option, then it does not work
ending in
collect2: fatal error: cannot find 'ld' compilation terminated.
This is because we are not creating proper symlinks for BFD
and Gold linker in gcc installation
Secondly, we end up with dangling fortran compiler symlinks
if fortran is not enabled when confguring gcc, therefore
create these symlinks only when fortran support is enabled
in gcc
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
The change to link libssp_nonshared.a only for musl was to move
spec file changes to config/linux.h under a conditional when
DEFAULT_LIBC == LIBC_MUSL which worked fine for all but ppc
since gcc for ppc provided its own linux.h overrides which are
used. This patch duplicates the change in those headers too
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
glibc 2.26 does not expose struct ucontext anymore
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
sigaltstack is no more exposed by glibc see (bug 21517)
therefore adjust to use stack_t instead
Use res_state typedef instead of referring to __res_state struct
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
glibc already provides the content for libssp_nonshared
in libc_nonshared.a therefore we dont need to make it
universal.
This also fixed build issues on glibc when linking statically
and using -fstack-protector
Fixed errors like
/mnt/a/oe/build/tmp/work/i586-bec-linux/aufs-util/3.14+gitAUTOINC+bdfcc0dcfc-r0/recipe-sysroot/usr/lib/../lib/libc.a(stack_chk_fail.o): In function `__stack_chk_fail': /usr/src/debug/glibc/2.26-r0/git/debug/stack_chk_fail.c:27: multiple definition of `__stack_chk_fail_local' /mnt/a/oe/build/tmp/work/i586-bec-linux/aufs-util/3.14+gitAUTOINC+bdfcc0dcfc-r0/recipe-sysroot/usr/lib/../lib/libssp_nonshared.a(libssp_nonshared_la-ssp-local.o):/usr/src/debug/gcc-runtime/7.1.0-r0/gcc-7.1.0/build.i586-bec-linux.i586-bec-linux/i586-bec-linux/libssp/../../../../../../../../work-shared/gcc-7.1.0-r0/gcc-7.1.0/libssp/ssp-local.c:47: first defined here collect2: error: ld returned 1 exit status
Signed-off-by: Khem Raj <raj.khem@gmail.com>
|
|
Signed-off-by: Khem Raj <raj.khem@gmail.com>
|
|
GCCPIE flag which is empty by default adds "--enable-default-pie"
configure option for harderned distros
We do not require to add -fpie -pie flag externally anymore
Signed-off-by: Khem Raj <raj.khem@gmail.com>
|
|
ERROR: libgfortran-6.3.0-r0 do_package: QA Issue: libgfortran:
Files/directories were installed but not shipped in any package:
/usr/lib/gcc/x86_64-poky-linux/6.3.0/finclude
/usr/lib/gcc/x86_64-poky-linux/6.3.0/finclude/ieee_features.mod
/usr/lib/gcc/x86_64-poky-linux/6.3.0/finclude/ieee_arithmetic.mod
/usr/lib/gcc/x86_64-poky-linux/6.3.0/finclude/ieee_exceptions.mod
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Due to the fact that the recipe uses INHIBIT_DEFAULT_DEPS, we need to
manually add the cross compiler as a dependency.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
This adds or fixes the Upstream-Status for all remaining patches missing it
in OE-Core.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Fix a variety of spelling and format mistakes to improve the ease of reading the
tags programatically.
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Some of these are clearly dead, e.g. one binutils patch reverts the effects
of the earlier one.
This also removes the uclibc site files. We now have mechanisms to allow these
to be extended from another layer should someone ever wish to do that.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
We now have gcc 6 and gcc 7 recipes, the gcc 5 series can be dropped
as we're no longer going to support it for targets.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
uclibc support was removed a while ago and musl works much better. Start to
remove the various overrides and patches related to uclibc which are no longer
needed.
uclibc support in a layer would still be possible. I have strong reasons to
believe nobody is still using uclibc since patches are missing and I doubt
the metadata even parses anymore.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It results in same link errors like armv4t
Signed-off-by: Khem Raj <raj.khem@gmail.com>
|
|
Switch default compiler to gcc 7
Signed-off-by: Khem Raj <raj.khem@gmail.com>
|
|
meta-micro puts headers in /include rather than /usr/include in the
sysroot. ${target_includedir} means that the correct path will be used
automatically.
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Acked-by: Phil Blundell <pb@pbcl.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
We only build one gcc-cross per architecture and having target specific
flags means gcc-cross would rebuild. These flags are really for the
on target case, so they should be set in gcc-target only.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The path to where to install and find the sysroot components is used
in many places. This warrants it to get its own variable.
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
"yocto-compat-layer.py --machines" showed that shared packages like
gcc-cross-powerpc64 have a sstate signature that depends on
TUNEFLAGS. As a result, there are unnecessary rebuilds and potential
conflicts in a multiconfig.
That's due to the way how TARGET_ARCH is set. Richard Purdie suggested
setting TARGET_ARCH[vardepvalue] as fix, which works. It would be
shorter to do that in cross.bbclass instead of repeating the relevant
line in different recipes, but Richard was concerned about potential
side-effects in other usages of cross.bbclass.
TARGET_GOARM as used in go.inc is still causing signature differences
for go-cross-powerpc64 and machines b4420qds-64b and p5020ds-64b. This
needs further investigation.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Building gcc-cross-initial with GCC7 on the host fails due to the
comparison of a pointer to an integer in ubsan_use_new_style_p, which
is forbidden by ISO C++:
ubsan.c:1474:23: error: ISO C++ forbids comparison between pointer and
integer [-fpermissive]
|| xloc.file == '\0' || xloc.file[0] == '\xff'
Backport the fix from upstream GCC to enable the build with GCC 7
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
We've had a lot of users running into RSS issues where -initial recipes
were being installed into sysroots alongside their counterparts and
causing overlapping files issues.
In general this was through do_build dependencies. Such dependencies are
bad in general and I'd encourage people to compare the taskgraphs with
using a more specific dependency like do_populate_sysroot, do_image_complete
or do_deploy as often the more specific dependency will result in a much
cleaner build.
Regardless, we don't want -initial dependencies getting in the way like
this and there are cases a do_build dependency could make sense.
Deleting the do_build task in these cases makes sense since this is not
a build "endpoint" we'd ever want a user to use, its a behind the scenes
piece of bootstrappping.
Unfortunately to make this work, we need a newer bitbake version which
has a bitbake bug fixed.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Create symlinks for gcov and gcov-tool and that they can be used trivially
on target.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
The file /usr/libexec/gcc/.../cc1 has been installed in package gcc
instead of package cpp, because FILES statements for both packages match
the cc1 binary. Move the file to package cpp and add cpp to RDEPENDS_gcc
to fix the dependency.
Having the cc1 binary in cpp fixes errors such as: "cpp: error trying to
exec 'cc1': execvp: No such file or directory".
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
CVE-2016-4490 applied to gcc < 6.1.1, our version is 6.3
Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Intel MPX was recently enabled on x86 (_append_x86) but that didn't
enable it on x86-64. Explicitly enable libmpx on x86-64 too.
Signed-off-by: Mikko Ylinen <mikko.ylinen@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
ERROR: gcc-runtime-6.3.0-r0 do_package: QA Issue: gcc-runtime: Files/directories were installed but not shipped in any package:
/usr/lib/libmpxwrappers.la
Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install.
gcc-runtime: 1 installed and not shipped files. [installed-vs-shipped]
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Enabling building the Intel Memory Protection Extension library for x86.
Leave this disabled in musl builds as it doesn't build there yet.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
[NVD] -- https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-6131
The demangler in GNU Libiberty allows remote attackers to cause a denial
of service (infinite loop, stack overflow, and crash) via a cycle in the
references of remembered mangled types.
[BZ #71696] -- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71696
2016-08-04 Marcel Böhme <boehme.marcel@gmail.com>
PR c++/71696
* cplus-dem.c: Prevent infinite recursion when there is a cycle
in the referencing of remembered mangled types.
(work_stuff): New stack to keep track of the remembered mangled
types that are currently being processed.
(push_processed_type): New method to push currently processed
remembered type onto the stack.
(pop_processed_type): New method to pop currently processed
remembered type from the stack.
(work_stuff_copy_to_from): Copy values of new variables.
(delete_non_B_K_work_stuff): Free stack memory.
(demangle_args): Push/Pop currently processed remembered type.
(do_type): Do not demangle a cyclic reference and push/pop
referenced remembered type.
cherry-picked from commit of
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@239143 138bc75d-0d04-0410-961f-82ee72b054a4
(From OE-Core rev: 3c288b181a4cfecc80b48994f4dd2df285e4d1d0)
Signed-off-by: Yuanjie Huang <yuanjie.huang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Fixes build on hardened PAX host with gcc-5 (linker error on relocs).
Completes no-PIE config by adding to ALL_* flags variables.
Borrowed from Gentoo gcc patches, tested on 2 hardened amd64 hosts.
Upstream-Status: Inappropriate [configuration]
Commited by: Gentoo Toolchain Project <toolchain@gentoo.org>
(From OE-Core rev: c178791cd78d5a9ebc4d7b7790e647a9bafe9cf2)
Signed-off-by: Stephen Arnold <stephen.arnold42@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Its sad we need to do this but do_install and do_populate_sysroot appear
to change the files in ${B} and this breaks if something works in parallel
like gcc_stash_builddir. We've seen a few too many race errors on the
autobuilder which appear to be from this so make things run in sequence
deterministically for now.
An example failure was this from do_populate_sysroot whilst stash_builddir was running
in parallel:
ERROR: gcc-cross-initial-arm-6.3.0-r0 do_populate_sysroot: split_and_strip_files: 'file
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-arm-lsb/build/build/tmp/work/x86_64-linux/
gcc-cross-initial-arm/6.3.0-r0/sysroot-destdir/home/pokybuild/yocto-autobuilder/yocto-worker/
nightly-arm-lsb/build/build/tmp/work/x86_64-linux/gcc-cross-initial-arm/6.3.0-r0/recipe-sysroot-native/
usr/bin/arm-poky-linux-gnueabi.gcc-cross-initial-arm/arm-poky-linux-gnueabi-gcov' failed
Exception: subprocess.CalledProcessError: Command '('patchelf-uninative', '--set-interpreter',
'/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-arm-lsb/build/build/tmp/sysroots-uninative/
x86_64-linux/lib/ld-linux-x86-64.so.2', '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-arm-lsb/
build/build/tmp/work/x86_64-linux/gcc-cross-initial-arm/6.3.0-r0/sstate-build-populate_sysroot/
recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi.gcc-cross-initial-arm/arm-poky-linux-gnueabi-gcov')' returned non-zero exit status 1
Subprocess output:
missing section headers
(From OE-Core rev: 75b76eb08c7e344142f0326605aeb6b24e61e38e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Now that the datastore works dynamically we don't need the update_data calls
so we can just remove them. They're not actually done anything at all for
a while.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
We used to need to build gcc-cross-initial against a bare sysroot to avoid
contamination. With RSS, we no longer need to do this since the recipe sysroot
is already bare. We can therefore simply point at that and drop this code.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
GCC provides some of std* headers including stddef.h
and it syncs with glibc definitions via __needed* defines
to find which datatypes are expected to be defined on top
of glibc. we need same for musl.
Drop unused 0048-ARM-PR-target-71056-Don-t-use-vectorized-builtins-wh.patch
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
If we don't do this, things break with rm_work which removes things
before the task completes causing task failures.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
SDKPKGSUFFIX could only really be "nativesdk" and TARGET_SYS never contains
that so the code manipulating TARGET_SYS is pointless. I suspect this once
worked against MULTIMACH_TARGET_SYS which would be a different question but
it no longer does. Its been cut and pasted everywhere.
This patch cleans up the variable references to make things a little more
readable.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|