Instead of building a shadow libstdc++-v3 directory with symlinks to the sysroot
libstdc++-v3.la, fiddle the Makefiles so that it doesn't attempt to link to a
in-tree library at all.
This fixes builds where .la files are not being installed into the sysroot at
all.
(From OE-Core rev: f0f814a674faef2160fb8a041b63169c74da108e)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In some recipes overly-split -dbg packages were merged into PN-dbg. Unless
there's a very good reason, recipes should have a single -dev and -dbg package.
(From OE-Core rev: a3b000643898d7402b9e57c02e8d10e677cc9722)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With the autodebug package generation logic, specifically setting FILES_${PN}-dbg
isn't needed in most cases, we can remove them.
(From OE-Core rev: 3ab59d49dd7c18e194b58d1248b4b87709b5a738)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It turns out writing the same list of packaging tasks multiple
times in multiple places is error prone. Move this to a new class
'nopackages", migrate existing users and add glibc-initial and
libgcc-initial since we don't want packages for those recipes.
This means the sstate for those recipes won't be installed, saving
small amounts of build time and bandwidth.
A reference to the old package_write task is also dropped.
(From OE-Core rev: cece583d58f82a50c3a4eac876eb326ac3b8f5e5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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
(From OE-Core rev: 30a0cc2ef72399b84da4903e697f258f79852fc9)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Import patch fixing a bug that caused ICE when compiling some packages
(e.g. ICU) in Thumb-1 model.
(From OE-Core rev: 68062674b853af750d0fdafb06090ed2f75fa0a4)
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Import patch fixing a bug that caused ICE when compiling some packages
(e.g. ICU) in Thumb-1 model.
(From OE-Core rev: 3c8ad9e008a1786ff95202f413e267756a5e783f)
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When a project is configure to use sstate cache and has the host tool sysroot
cleaned, gcc-cross-initial may fail to be configured due to lack of
gnu-configize tool.
gcc-cross-initial recipe has autotools dependency inhibited, and the same flag
variable also excludes the gnu-config-native. Though there is an indirect
dependency through libmpc-native, it's not safe with sstate cache being used.
Moreover, gnu-config-native requires a perl package from autoconf-native to
run, otherwise it will fail with "Can't locate Autom4te/ChannelDefs.pm in @INC"
message.
This patch makes both dependencies explicit for gcc-cross-initial's
configuration.
(From OE-Core rev: 18a913e54b40a1654d0967290088be5e7fcdd6f6)
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>
This patch is based on the patch for gcc-5.2 (41cbfd7af6)
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.
(From OE-Core rev: e6dc4b2ac0cc6417c0e0ddcdcbe3f334581af8fc)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We have 5.2 and 4.9, we don't really need 4.8 now and it can be moved
out to other layers if anyone still wants/needs it.
(From OE-Core rev: 6f98c39418c60b7c0b25b30983d2e5257158a6a4)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The gcc default, bss-plt, will cause errors when using the prelinker. All
other distributions that I am aware of are using the the secure-plt. For an
explanation of the differences, the gcc docs:
Current PowerPC GCC accepts a `-msecure-plt' option that generates code
capable of using a newer PLT and GOT layout that has the security
advantage of no executable section ever needing to be writable and no
writable section ever being executable. PowerPC ld will generate this
layout, including stubs to access the PLT, if all input files (including
startup and static libraries) were compiled with `-msecure-plt'.
`--bss-plt' forces the old BSS PLT (and GOT layout) which can give
slightly better performance.
The security of the new PLT and ability to run the prelinker outweigh
any performance penalty.
The secure-plt is enabled by default. The old bss-plt can be enabled by
selecting 'bssplt' in the DISTRO_FEATURES.
(From OE-Core rev: 70c55aada1101a5c687cdaa79f370fa4530b39d9)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In the past GCC has used a wildcard to permit generating executables
that may have a suffix, such as .exe. This wild card was lost in one
of the updates. Adding the wild card back in fixes a number of issues
when generating a mingw gcc.
(From OE-Core rev: 1003e93a1b3359a98fb631eeeda3fda184832288)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: 85ca40c42950315f2783b98f57df16b261d2826e)
Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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}.
(From OE-Core rev: ef16c20e6936218ff96c599cce0200c34f5017dd)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Changing SDKMACHINE (which changes SDK_ARCH) shouldn't cause
target task signatures to change. Exclude the dependency
on SDK_ARCH for this reason. It only affects nativesdk builds
and those already account for SDK_ARCH in the build WORKDIR paths.
(From OE-Core rev: dae7c45fac1d877203f173842d43abc4883b808b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The ccargs obtained from get_tune_parameters may not be fully expanded,
so that the gcc_multilib_setup function can be confused, and generates
invalid MULTILIB_OPTIONS in GCC Makefile fragment, which will break the
multilib feature of target gcc.
To address problems above, this patch modifies gcc_multilib_setup
function to expand ccargs before use.
Upstream-Status: Inappropriate [configuration]
(From OE-Core rev: 02eddf9a0b89b0cbe0c83d95cedb3431899197d0)
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>
The SDK was unable to find the C++ header pieces correctly since its
using a generic compiler, not one specifically targeting the multilib
vendor prefix. This adds in the right mapping to ensure multilib SDKs
work as expected. This fixes multilib SDK automated tests.
(From OE-Core rev: 823ce9555ee78aa460d0560b8fd9b309cfd36997)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
gcc-source is the only gcc recipe meant to handle the fetch/unpack/patch
tasks, the other gcc recipes then depend on this.
This approach has been creating some confusion for tools like the archiver.
The simplest way to signal to these processes that there is no source
is to empty SRC_URI at the same time we disable the other tasks.
(From OE-Core rev: 0df9d45e0be59e55e585e6d25dedbf0fc55c490c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When building libgcc some files and libraries may be built but not packaged.
The original code packaged only some explicitly specified files targeting mostly x86.
This patch does not discriminate between various targets.
It fixes errors such as these:
ERROR: QA Issue: libgcc: Files/directories were installed but not shipped in any package:
/usr/lib/arm-poky-eabi/4.9.3/thumb
/usr/lib/arm-poky-eabi/4.9.3/fpu
/usr/lib/arm-poky-eabi/4.9.3/thumb/libgcov.a
/usr/lib/arm-poky-eabi/4.9.3/thumb/crtn.o
/usr/lib/arm-poky-eabi/4.9.3/thumb/crtend.o
/usr/lib/arm-poky-eabi/4.9.3/thumb/crtbegin.o
/usr/lib/arm-poky-eabi/4.9.3/thumb/libgcc.a
/usr/lib/arm-poky-eabi/4.9.3/thumb/crti.o
/usr/lib/arm-poky-eabi/4.9.3/fpu/libgcov.a
/usr/lib/arm-poky-eabi/4.9.3/fpu/crtn.o
/usr/lib/arm-poky-eabi/4.9.3/fpu/crtend.o
/usr/lib/arm-poky-eabi/4.9.3/fpu/crtbegin.o
/usr/lib/arm-poky-eabi/4.9.3/fpu/libgcc.a
/usr/lib/arm-poky-eabi/4.9.3/fpu/crti.o
Please set FILES such that these items are packaged. Alternatively if they are unneeded,
avoid installing them or delete them within do_install. [installed-vs-shipped]
(From OE-Core rev: 603b2f3ef400ec66a6899a7b407cbfecd3da5910)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We presently don't package isl. Unfortunately, if the host is already
using gcc-5.2 (as is presently the case on Arch Linux), configure will
autodetect the host's libisl, and do_compile will break because the
system isl headers aren't pulled in. In lieu of packaging isl, disable
it for now.
[YOCTO #8376]
(From OE-Core rev: 555e8d110435cf4af1e1ab4699c2fa55898e9d80)
Signed-off-by: Richard Tollerton <rich.tollerton@ni.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
0063-nativesdk-gcc-support.patch can not be applied to source code due to
the buggy patch command on sled11, so reformat it, nothing is changed.
(From OE-Core rev: 2c8c3d9c4b65d2a5c7976d530138ebcaac2b1447)
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix a variety of problems such as typos, bad punctuations, or incorrect
Upstream-Status values.
(From OE-Core rev: bd220fe6ce8c3a0805f13a14706d3130ea872604)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It couldn't be applied by sled11's patch, now fix it.
(From OE-Core rev: e01b450a419aba2164a86510ca1ae402ec86aff0)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Without this patch, the D's include_fixed folder may change after building it
(due to the gcc's fixinc.sh script, executed on the do_compile task) and changes
depend on the current sysroot headers, making the gcc's builds non-deterministic.
[YOCTO #7882]
(From OE-Core rev: e0af4b2c8f8e29ac6f8eccef401c7c004355359d)
Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Modifications to to support build for TCLIBC="baremetal"
(From OE-Core rev: 9e7da158e0e7628c22013fbee34270f7d2db621f)
(From OE-Core rev: 92eb54c6b7424770f96a8e14e792cbe5124968c3)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Exclude all versions of gcc-source from world builds so that:
bitbake -c <stage> world
will work. gcc-source deletes most bitbake build stages
since it is a source-only package.
(From OE-Core rev: 0eda7b4d889b926ab97d60fcbb1c0d12d730f8ea)
Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The location of some files for mips varies between gcc 4.9 and 5.2. Ensure
that we cover both cases (and allow specified files to be optional).
(From OE-Core rev: 5c33b0a752e6168200776da61dee7d4d807ddbb0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
"n32" is a mips64 variant we need to consider when processing the TARGET_OS
extensions. Also add the multilib extensions for mips64.
(From OE-Core rev: fe26f809aaad5d5d608e841c99b817316c5a59a0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The symlink being generated needs to match both the current arch (e.g. mips
or mips64) but also use the underlying TARGET_SYS without multilib extensions
to TARGET_VENDOR or extensions to TARGET_OS.
The way multilib changes TARGET_VENDOR meant this code did not have
a way of removing that change. The method of removing some TARGET_OS
suffixes was also not working.
By using immediate expansion to run this code, we can run before the
multilib code changes it and get the original values.
We then use the *current* TARGET_ARCH value in case this does get changed
by the multilib since we need to point at the right compiler (32 bit one
for 32 bit code).
(From OE-Core rev: 89cd6c244b6bc0a8cb52ec84d378d5b305df030f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
gcc itself does not add the '-' of options to its multilib configuration.
We should follow its example.
(From OE-Core rev: e742eef3e1016a29f744341c17d1b421d318b40f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In some cases such as cross architecture configurations (using mips-X-linux
on mips64-X-linux), gcc can get confused about finding a 'real' version
of ld. Adding a symlink to 'real-ld' allowed these configurations
to work properly.
(From OE-Core rev: cdd86896c8d29135f937968e9aa07f919cf543d3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: b928d92bb9f76c118846d6c495dc57c149368f0f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: cd3d874fced2ee4c950d9964d30c0588fd8772e7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixed:
* gcc 5 introduces a plugin libcc1.so, which is used by gdb, the target
gcc didn't build it in the past because gcc_cv_objdump is null, and
the error was:
gcc-5.2.0/libcc1/configure: line 14531: -T: command not found
This only happens for tar gcc as the code shows:
if test x$build = x$host; then
export_sym_check="objdump${exeext} -T"
elif test x$host = x$target; then
export_sym_check="$gcc_cv_objdump -T"
else
export_sym_check=
fi
* Install libcc1.so and libcc1plugin.so to
$(libexecdir)/gcc/$(target_noncanonical)/$(gcc_version) as lto-plugin did.
* Use sed command to fix bad RPATH iussue.
[YOCTO #7956]
(From OE-Core rev: f6e47aa9b12f9ab61530c40e0343f451699d9077)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is second bugfix release in gcc5 series
All backported patches are dropped
no other patches needed any rework
(From OE-Core rev: 2a212e56a814e5dc8a8bae4974b91109ed0486ef)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The gcc-intermediate had been gone, so remove EXTRA_OECONF_INTERMEDIATE.
(From OE-Core rev: 00ffc14c57598e845281e151589292573905b03c)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Chromium/CEF reveals these warnings which are then treated as errors
which has been fixed on gcc_5 branch upsteam. We backport the relevant
commits
Change-Id: I088a1480d49cdb439c72f0e159bee6de8ba94258
(From OE-Core rev: a8a5c58ec753a8bddc824eb15b06ad4cc8bd021e)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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
(From OE-Core rev: 626f7c1b848defe1fb34c2b2c3f0664dca2a8366)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixed race issue when build more than one gcc-source and inherit
rm_work, for example:
$ bitbake gcc-source-4.9.2 gcc-source-5.1.0
File "/path/to/bitbake/lib/bb/build.py", line 512, in exec_task
return _exec_task(fn, task, d, quieterr)
File "/path/to/bitbake/lib/bb/build.py", line 489, in _exec_task
make_stamp(task, localdata)
File "/path/to/bitbake/lib/bb/build.py", line 599, in make_stamp
os.unlink(name)
OSError: [Errno 2] No such file or directory: '/path/to/tmp/stamps/work-shared/gcc-4.9.2-r0.do_rm_work_all.02cf1ed9b79d4edb0a51d3b913b7f9ba'
This is because make_stamp() uses glob.glob() to remove the old stamps
before create the new one, when gcc-source-5.1.0 removes gcc-4.9.2-r0's
stamp, we may get the error.
We can't use deltask do_rm_work_all as do_rm_work since it is a
recrdeptask, otherwise:
ERROR: Command execution failed: Traceback (most recent call last):
File "/path/to/bitbake/lib/bb/command.py", line 102, in runAsyncCommand
commandmethod(self.cmds_async, self, options)
File "/path/to/bitbake/lib/bb/command.py", line 324, in generateDotGraph
command.cooker.generateDotGraphFiles(pkgs_to_build, task)
File "/path/to/bitbake/lib/bb/cooker.py", line 847, in generateDotGraphFiles
depgraph = self.generateTaskDepTreeData(pkgs_to_build, task)
File "/path/to/bitbake/lib/bb/cooker.py", line 672, in generateTaskDepTreeData
rq.rqdata.prepare()
File "/path/to/bitbake/lib/bb/runqueue.py", line 587, in prepare
generate_recdeps(dep)
File "/path/to/bitbake/lib/bb/runqueue.py", line 575, in generate_recdeps
add_resolved_dependencies([taskData.tasks_fnid[t]], tasknames, newdeps)
TypeError: list indices must be integers, not NoneType
Update STAMPCLEAN to contain ${PV} to fix the problem.
(From OE-Core rev: 9099d46a46ee511d1b7e496472c5b973e8e8feaf)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Setting OE's PATH for the 'cd' command has no real effect.
In the normal case it has no effect for the gnu-configize command
either (since OE's PATH is already set in the context which runs
do_preconfigure) but it may be useful when manually re-running a
failed gnu-configize commandline copied from an error log, etc.
(From OE-Core rev: 4321fce801daea50baaaae9ed6a141c6e7712834)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
gcc-5.1.0: gcc: Files/directories were installed but not shipped in any package:
/usr/bin/i586-poky-linux-gcov-tool
(From OE-Core rev: 3e2ca755624c13a8249ac66672ebf4d8d7217e62)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Marek Vasut
Ross Burton
Andre McCurdy
Khem Raj
Richard Purdie
Dmitry Eremin-Solenikov
Yuanjie Huang
Alexander Kanavin
Martin Jansa
Juro Bystricky
Robert Yang
Mark Hatle
Kai Kang
Richard Tollerton
Roy Li
Leonardo Sandoval
Randy MacLeod