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>
Without this, g++/c++ compilation doesn't work on target due to missing
header files. Automated sanity tests fail. Add back the gcc4 patch to
address this.
(From OE-Core rev: 93d8becf19cc72df650d3aaff7e3ea188bd6e09e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Drop backports obviously
additionally drop local patches around
parallel compilation since it got reworked upstream
To select set
GCCVERSION = "5.1%"
SDKGCCVERSION = "5.1%"
in local.conf
Change-Id: Icdfa61017a617244128f361b022e7c8f1f9e0610
(From OE-Core rev: 4bc4acc67e5d7b3f27afadeda5710f9ba5f627d2)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In an effort to clean up some of the license handling, correctly set the
LICENSE of libgcc-initial to be the same as libgcc which has a GPLv3
exception.
(From OE-Core rev: a3022665600bb3c08f8d4212ffa3516578e86d7c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This means you can have one gcc version for some gcc recipes
(e.g. crosssdk/nativesdk) and another gcc version for target code.
Also remove the preferred version entry from the default toolchains
list since the version issue is now handled automatically.
We also need to specifically handle gcc-source in the license handling
code since expanding ${PV} in the base class isn't possible. Since
gcc-source doesn't generate any packages directly this shouldn't be
an issue and whitelisting in this way is easiest (and matches the
rest of the toolchain handling).
(From OE-Core rev: 67db7182faf6742b0d971d61d8c5ba34f69d2e12)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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
(From OE-Core rev: 6751ef78694783fb86e55c77afefae750ab1b610)
Signed-off-by: Stefan Müller-Klieser <s.mueller-klieser@phytec.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There should be only one dev and dbg package.
(From OE-Core rev: b38119f4dc69421605355f92954ef39dad93b419)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There should be only one dev and dbg package.
(From OE-Core rev: 1e9ccec936554c69ede04babee9955f25b296588)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Drop already applied patches
This fixes random ICE seen on mips with large c++ files ( webkit )
Then there are several backports
Change-Id: Ie1c3acda2fda1b6cbd356416c860938f6cbd758e
(From OE-Core rev: ca228b117abe3dc40c996a006c9cbea91c17ccea)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In a baremetal build, TARGET_ENDIAN_OPTION isn't set leading to build
failures. Add in ifdefs to avoid this.
(From OE-Core rev: 3a50ec5f0142cc3a74b405dbdff264f8f862edfa)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This seems to have been disabled since the dawn of time for no good reason.
Enable the .debug stripping and packaging allowing for a smaller SDK.
(From OE-Core rev: bbaf97ba38329b5221e6d4d0d18f20e6b7d6fd91)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
gcc-source don't do do_package_write_rpm, so we should set
PACKAGES = "" to avoid the building error if we want generate srpm,
otherwise, we get the error as below.
ERROR: Task do_deploy_archives in meta/recipes-devtools/gcc/gcc-source_4.9.bb \
depends upon non-existent task do_package_write_rpm in \
meta/recipes-devtools/gcc/gcc-source_4.9.bb
(From OE-Core rev: 704fd8f1efbd7fa9368cfe4f956abf24cd58664e)
Signed-off-by: Bian Naimeng <biannm@cn.fujitsu.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The ${STAGING_INCDIR_NATIVE}/gcc-build-internal-$mtarget may not exist
when use the external sdk toolchain, we need check before link for it.
Fixed:
run.do_configure.12538: 149: cd: can't cd to sysroots/x86_64-linux/usr/include/gcc-build-internal-x86_64-wrs-linux
(LOCAL REV: NOT UPSTREAM) -- Sent to oe-core on 20150204
(From OE-Core rev: 82166e514438eb1b562f2a4dc2f9f8fecf3f60df)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Installing /usr/lib/gcc/* means we'd have two copies, one from gcc-cross
and one from here. These can confuse gcc cross where includes use #include_next
and builds track file dependencies (e.g. perl and its makedepends code).
For determinism we don't install this to the sysroot, ever and rely on the
copy from gcc-cross.
[YOCTO #7287]
(From OE-Core rev: 15b3324b769dc92e1b0d4b9da9fbfccbc8dde9dd)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It is not needed any more since sed-native had been dropped.
(From OE-Core rev: 289e433f8d0e4b5a710094e3a3c0d8e77e82e50d)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #7230]
In certain system configurations TRANSLATED_TARGET_ARCH will not
expand in the right order for gcc-cross-candian-mips64n32 to be
generated properly.
This will cause SDKs to fail to generate properly.
Changing the global definition of TRANSLATED_TARGET_ARCH always
expands the ABIEXTENSION, which causes the OVERRIDES to pick it up
as well. This effectively defines a new class of overrides for the 'n32'.
The side effect is that we need to duplicate some mips64 overrides, and
redefine others that were previously 'n32' or 'mips64' exclusive to have
the correct semantics.
(From OE-Core rev: 4b3a2b703b20583bd107f00a297d972e9bfb514a)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The sanitizer runtime library is dual-licensed under the NCSA
and MIT licenses.
Also make nativesdk-gcc-sanitizers use SDKGCCVERSION by default
instead of GCCVERSION
(From OE-Core rev: 4ed21998827060745d2858e2d6c121baf823e64a)
Signed-off-by: Dan McGregor <dan.mcgregor@usask.ca>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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].
(From OE-Core rev: 5c87bb9ac2b35b3f8cf2b7d3e4507e7013115162)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Without the fakeroot flag the two tasks may create files or
symbolic links that end up being owned by the user and not
root:root as expected.
(From OE-Core rev: 7e9fd9d34a540fdfc1243d059d1f13f1d09864d2)
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>
Remove libgfortran packages from PACKAGES list as long as libgfortran
has separate receipe since commit
5bde5d9b39
gcc: Allow fortran to build successfully in 4.8
Otherwise, when fortran support will be enabled in the compiler, both
lingfortran and gcc-runtime receipes will create the same files and will
try to install them. This will cause errors:
ERROR: The recipe libgfortran is trying to install files into a shared
area when those files already exist. Those files and their manifest
location are: ...
Please verify which recipe should provide the above files.
(From OE-Core rev: 872342fa3d08edede4a0105ac3ddb0f2ae3224b4)
Signed-off-by: Daniel Dragomir <daniel.dragomir@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
AddressSanitizer is a fast memory error detector.
ThreadSanitizer detects data races.
UBSanitizer detectes undefined behaviour.
All consist of compiler instrumentation and a run-time library.
The compiler instrumentation was already enabled, this builds
the run-time library component.
(From OE-Core rev: 1709bf0c3a84bb04bc52e9104ad8e09fba6c6f91)
Signed-off-by: Dan McGregor <dan.mcgregor@usask.ca>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We want to revert to default gcc behavior to support oe-core's ability
to change the libdir.
(From OE-Core rev: 7ea9e87217c78a20cebcb16a23bfd412e276440f)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It can be alarming to attempt to exclude GPLv3 from an
image but find that libstdc++ and libgcc still show it.
We indicate the license for each package to show libraries
that really are just GCC-3.0-with-GCC-exception.
(From OE-Core rev: 5db535a91edea439c14e75726acd23e64bb1e2ea)
Signed-off-by: Joe Slater <jslater@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Whilst gcc doesn't have any source to fetch, it still needs a fetch task so that
a world fetch can run without errors. So instead of deleting the fetch task,
stub it.
(From OE-Core rev: 8e68ebbddc2bc41eb6cb607c51d6a80c54c4199d)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The current implementation of shared work for gcc is at best confusing. It relies
on the fetch/unpack/patch tasks having exactly the same stamps and if this gets
broken for some reason, its hard to figure out what the problem is. It also
leads to complex code in bitbake.
The benefits of shared work for gcc are clear but a better approach is needed. This
patch adjusts things so that a single new recipe (gcc-source) provides the
fetch/unpack/patch/preconfigure tasks, the rest of gcc simply depends on these tasks
and have no fetch/unpack/patch tasks of their own.
This means we should get the significant benefits (disk usage/performance) of the
single source tree but in a way which has less potential for problems and is
easier for people to understand. The cost is an extra recipe/some inc files
which is probably a good tradeoff.
(From OE-Core rev: ceaa0a448dc5ebddb4f7fb94fb8a503a1c0248c3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I disabled this patch as it became obsolete some time ago but forgot to
remove it, this cleans things up.
(From OE-Core rev: 11dc68ef46aa0e3f28473c0decb4034e0d00fcab)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
While compiling gcc-crosssdk-initial-x86_64 on some host, there is
occasionally failure that test the existance of default.h doesn't
work.
...
| tmp/work-shared/gcc-4.9.1-r0/gcc-4.9.1/gcc/calls.c:1240:
error: 'STACK_CHECK_MAX_VAR_SIZE' was not declared in this scope
...
The reason is tm_include_list='** defaults.h' rather than
tm_include_list='** ./defaults.h'
So we add the test condition for this situation.
(From OE-Core rev: fec684512c6f934d7a847b0c9f5151da81426910)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If configure or any of the components it uses from the shared work directory
change, do_configure may fail.
An existing do_preconfigure was created to handle these conditions, but
a 'sed' operation was missed, and a call to gnu-configize was also missed.
(From OE-Core rev: 21c2cfff14442cf224e3568bdbb9bcd4070be247)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: de52db1b1b0dbc9060dddceb42b7dd4f66a7e0f3)
Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: 04b725511a505c582a3abdf63d096967f0320779)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
(From OE-Core rev: 365221f7285c0e392f573deaab3b1e00b12bc293)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some architectures can mix different TARGET_OS values, in most cases
we just use one but in the ppc case, can use two different values. In this
case, to use one toolchain with both, we need to ensure the symlinks exist.
This isn't ideal but does fix the ppc toolchains for the release, after
which better ways of handling this can be investiaged. Without this, failures
in the C++ toolchain are seen.
(From OE-Core rev: 112641117f1152bad8a806f1aa872a67575d5316)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is a race where:
NOTE: recipe libgcc-initial-4.9.1-r0: task do_configure: Started
NOTE: recipe gcc-runtime-4.9.1-r0: task do_preconfigure: Started
| checking build system type... /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-deb/build/build/tmp/work-shared/gcc-4.9.1-r0/gcc-4.9.1/libgcc/../config.sub: line 1711: syntax error near unexpected token `;;'
| /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-deb/build/build/tmp/work-shared/gcc-4.9.1-r0/gcc-4.9.1/libgcc/../config.sub: line 1711: ` ;;'
| configure: error: /bin/bash /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-deb/build/build/tmp/work-shared/gcc-4.9.1-r0/gcc-4.9.1/libgcc/../config.sub x86_64-linux failed
| WARNING: exit code 2 from a shell command.
so we need to make sure the preconfigure task executes in all shared
work contexts.
(From OE-Core rev: 3c30331d6eaf804b83a6d27189a12efc94310e91)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
change use of eglibc related variabled to glibc equivalents
(From OE-Core rev: fd15d6e0c8da75951a91d4467eda23c229b1026d)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
musl e.g. is configured to not use fixed-include
which is an improvement btw. but libgcc-initial configure
has tests which probe for limits.h and since we put
it in include-fixed/ dir and that dir does not appear
in gcc's internal default search path the configure tests
for CPP detection fail and libgcc-initial can not be compiled.
(From OE-Core rev: 3bdc225a9e622e9d594944833964fe396200db01)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The gcc-runtime recipe builds the gcc libraries including libstdc++ with
$TARGET_CC_ARCH flags, which include -march=FOO flags that affect
whether atomic instructions are available. This causes an ABI
incompatibility when the compiler by default generates code for less
capable architectures. For example, gcc-runtime libraries on a
Cortex-A8 are built with a different C++11/C++14 mutex implementation
than is used code compiled outside OE and without architecture-specific
flags.
This commit fixes the problem specifically for ABI issues related to
atomic instructions available in ARMV6 and subsequent architectures.
Other ABI incompatibilities may remain in other architectures.
See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62100
(From OE-Core rev: 0ba6ab39f187ecd4261f08e768f365f461384a3a)
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: 06f911894a367f395139c2b0d6c2ba6371398478)
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
musl does not support IBM 128 long double for ppc, instead of
doing complex overrides move it into a pythong snippet which
is easier to read and more compact.
(From OE-Core rev: e7011429e40ae96b9c9f1e7f3c6f4c1f1102607f)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This variable is used to ensure the proper version of --with-float=FOO
is passed to gcc's configure script. gcc also has a --with-fpu=FOO
option that means something different. To avoid confusion, change the
names to be consistent.
(From OE-Core rev: c17d883fa99b6967d83c3796d22fc0c1dbe704e6)
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(From OE-Core rev: 9ec30be63ad6d991646a7ce0ee22acdad7a81184)
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
--enable-libunwind-exceptions was removed from gcc at release 3.4.3
about ten years ago.
(From OE-Core rev: 285d3579727177e6962d7ad16677429e7dec65f4)
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Apply to gcc 4.9 the recent fix to the --with-gxx-include-dir override.
Original OE-Core rev: 5a2ff3e8f7cd7a47a5ab4e581847ecc4df87fca
(From OE-Core rev: 5fec278316fa9466241b9134c4553bad6db1c1a9)
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: c89443e0f98249b9f9ea33f686c27babe35fd024)
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: d971db8b2259e4c35b871cccf130fba193849560)
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We already indicate our intentions to use ld.bfd by
specifying it in configure using --with-ld which works
ok unless here where we manually create symlinks to
binutils-cross components, when we use ld-is-gold feature
default ld points to gold and this symlinking has to be
aware of the fact that we configured binutils and gcc-cross to use
gold as default ld but gcc-cross-initial uses BFD ld
This would be visible when using gold and rebuilding
eglibc
(From OE-Core rev: 77cab553ee6caa940e21cca46ff134f84e65c171)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix an issue on a multilib configuration that contains more then 1 multilib.
I.e. on MIPS64:
DEFAULTTUNE = "mips64"
MULTILIBS = "lib32n:mips64_n32 lib32:mips32"
While normally you'd use 'libn32', the above is legal.
With the startswith code, the system will look to expand the 'lib32' element
and find the 'lib32n' instead, and will result in a warning:
lib32 doesn't have a corresponding tune. Skipping...
(From OE-Core rev: ced919f6013fc0dbb8b8f75f87a8c0a4f416b1fe)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Drop patches which are already available in 4.9.1
(From OE-Core rev: b2ecf4065fa5930b896b8790d153389e400eb0ec)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The gcc-ar.o, gcc-nm.o, gcc-ranlib.o and errors.o included
config.h which was a generated file. But no explicity rule
to clarify the dependency. There was potential building
failure while parallel make.
For gcc-ar.o, gcc-nm.o and gcc-ranlib.o, they were compiled from one C
source file gcc-ar.c, we add them to ALL_HOST_BACKEND_OBJS, so the
'$(ALL_HOST_OBJS) : | $(generated_files)' rule could work for these
objects.
For errors.o, it is part of gengtype, and the gengtype generator program
is special: Two versions are built. One is for the build machine, and one
is for the host. We refered what gengtype-parse.o did (which also is part
of gengtype).
[YOCTO #6568]
(From OE-Core rev: aea4b2d58856226c471922dfa40650cba2f5a36a)
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>
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]
(From OE-Core rev: 86c2483f0fe05fb763d280ae22d70e54cb4bb0bc)
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>
MULTILIB_OPTIONS takes the parameters which trigger a given multilib to be
selected. It supports *one* option per multilib, '/' separated. Spaces
separate options used to generate additional multilib combinations.
Adding in all of CFLAGS to this is therefore clearly a really bad idea
but how do we fix things?
The best option I've come up with so far is a list of whitelist variables
to use to trigger the multilibs. Its populated with the standard multilibs
we support, anyone setting up an advanced multilib can populate the variable
with the correct trigger parameters.
This has the advantage of simplifying the code and allowing us to remove
the code filtering blocks since there is no longer option duplication. Testing
after this change shows a much improved sdk toolchain functionality.
(From OE-Core rev: 29202cd1b9d2e5d56e5b9f7a596e44e229c90492)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* GLIBC_DYNAMIC_LINKER64 reglex does not work for rs6000/linux64.h,
update it.
* it turns out that UCLIBC_DYNAMIC_LINKER reglex will strip the 32/64
chars from UCLIBC_DYNAMIC_LINKER64/UCLIBC_DYNAMIC_LINKER32, add '\b'.
my two PCs: Centos 6.5 (python 2.7.5) and Fedora 13 (python 2.7.3)
(From OE-Core rev: a0b408191d64804df1748163060313af31433ac8)
Signed-off-by: Ting Liu <ting.liu@freescale.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It was observed that code using STLport 4.6 fails to compile under the
SDK with the following error message:
.../includes/cstddef:38:46: fatal error: ../4.7.2/cstddef: No such file
or directory
STLport 4.6 (screwily) assumes that the C++ system headers live in a
gcc-versioned subdirectory, for gcc>=3.0; cf
http://sourceforge.net/p/stlport/code/ci/STLport-4.6-patch/tree/stlport/config/stl_gcc.h#l269.
This assumption is *almost always* valid, because that matches the
default setting of --with-gxx-include-dir. We can match that behavior by
appending "/${BINV}" to our own --with-gxx-include-dir settings.
Natinst-CAR-ID: 446449
Natinst-Reviewboard-ID: 57209
Acked-by: Ken Sharp <ken.sharp@ni.com>
Acked-by: Ben Shelton <ben.shelton@ni.com>
(From OE-Core rev: 5a2ff3e8f7cd7a47a5ab4e581847ecc4df87fca3)
Signed-off-by: Richard Tollerton <rich.tollerton@ni.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: bf1473d0c1b099b8d919835cc430b99606134aab)
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
While we're not going to package the libgcc component as part of the SDK,
we do need to generate it to get the unwind, and quadmath headers. Without
this change it is not possible to build eglibc or other components that
require these headers with the SDK toolchain.
(From OE-Core rev: e67b24401a366b20644510703c7140be975869ea)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The gengtype patch we apply to gcc aims to ensure that the build and host
config headers don't get confused. We're seeing build failures where
both headers have been included, likely due to a race over the configuration
files.
It seems the gengtype-lex.c file isn't being regenerated when it should
and the unconditional inclusion of bconfig.h is resulting in these issues.
The fix is therefore to remove the file, forcing its regeneration.
[YOCTO #6393]
(From OE-Core rev: dd649374b30eb2d9980dce6eae95db0563593ef7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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).
(From OE-Core rev: db44be06c75f2ac17a55dd1764471e869e872b8b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: 879ff7e931a80fd090db4485b6b6dee8e4c71d30)
Signed-off-by: Petter Mabäcker <petter@technux.se>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need to handle the UCLIBC_* linker variables in the same way
as we do the GLIBC_* ones to allow uclibc multilib to work properly.
(From OE-Core rev: 025ec5958b7e1fd71caa0079ec3c573126b30886)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is a fix about to go into bitbake to ensure that datastores
being accessed with a name other than "d" are correctly reflected
in checksums. This will cause this function to add in a number of
dependencies we don't want.
These do need to be properly unravelled in due course but would
only really affect multilib builds. For now therefore just exclude
the variables as per the old behaviour.
(From OE-Core rev: cbc41a573dd3a073e7b862ca9d763ce815e8f927)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The class itself currently does nothing. The idea is to mark all recipes that
make use of the texinfo utilities. In the future, this class could be used to
suppress the generation/formatting of documentation for performance,
explicitly track dependencies on these utilities, and eliminate Yocto's
current dependency on the host system's texinfo utilities.
(From OE-Core rev: e6fb2f9afe2ba6b676c46d1eb297ca9cc532d405)
Signed-off-by: Max Eliaser <max.eliaser@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Within the OE build environment, we supply the correct fpu settings. These
only need to be spelt out for the on-target gcc.
Doing this means the checksums for the core compiler don't depend on the fpu
settings. We exclude the compiler tunes for similar reasons, it doesn't need
to influence the compiler build.
(From OE-Core rev: ce1f3fd20d81545d6d5dfc68f86f9fddf8ac9bbf)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since we no longer build target libs within gcc-cross, we can drop the
TARGET_CC_ARCH flags and hence make it independent of tune.
(From OE-Core rev: 74d8866814aec520822518cc4cb8a942f7069bf7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As far as I can tell this variable is now completely unneeded. It would
only ever get used in target builds and these are now correctly done
in the target environment namespace, not any of our cross environments.
As such, CC and other variables contain the correct compilers and other
tune options and these are correctly picked up when building libgcc,
libstdc++ and others.
I tried to figure out where else these would make any sense and couldn't
find anything. Builds appear fine without them so lets drop the complexity
including the patch adding in this flag to gcc.
(From OE-Core rev: 5484596f4252e707ff791feedf143a72dbb613f6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This command modifies ${S} and can race against other tasks running do_configure and
having the scripts disappear from under them. To avoid this move to its own
task and work on the shared work directory as a common task.
It needs to be a python task to avoid lots of shell exported variables as
dependencies.
(From OE-Core rev: 55ed9ffbab5118140baac5d0d29dcc919e1f1668)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently the gcc builds are building copies of the target libraries
that we never use (it isn't installed in do_install). This is a rather
pointless waste of cpu time.
Instead just compile the host targets. Comparing the package output of
this compared to a previous build shows that the unwind.h header is
missing since its provided by gcc. Fix this simply by copying it in.
(From OE-Core rev: 19448a50c106684ee7e3862f759418c982363a29)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows them to co-exist together in the native sysroot, with one
set of cross tools per target architecture.
(From OE-Core rev: a2c5509520d5c3e082f55844e6545d0309565f8f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The base_contains is kept as a compatibility method and we ought to
not use it in OE-Core so we can remove it from base metadata in
future.
(From OE-Core rev: d83b16dbf0862be387f84228710cb165c6d2b03b)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
BitBake has the exact same code as oe.utils.contains so there's no
reason to duplicate it. We now rely on the bb.utils.contains code for
metadata.
(From OE-Core rev: 93499ebc46547f5bf6dcecd5a786ead9f726de28)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Its useful to separate out the native (cross) binaries from the target
compilation. We already do this for libgcc, this now takes the same
approach for -initial.
(From OE-Core rev: 8a2aaf8b6bdca2d28c0047093c7f668750d57666)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rather than building the whole of libgcc to obtain the unwind.h header
file, simply configure it and then install the file. This avoids copying
chunks of data around when we don't need to and building the same thing
twice.
After doing this we need to make sure the target build directory exists
in the libgcc case since it will no longer be created automatically.
(From OE-Core rev: 459e4dc25462771038459567c22e87d4cd38b117)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Prepare the ground for the creation of libgcc-initial by splitting common
libgcc code into a libgcc-common.inc file.
(From OE-Core rev: 7c9f4a22d5c14d768be872beb9fc798163d6d204)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are two places unwind.h is installed, even by the Makefile's admission.
Disable one of them to prevent build failure races.
(From OE-Core rev: d3b02218dcfedda8e4efb43b8fa6d13af8d91f78)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* it uses autotools but doesn't call autotools_do_install
* fixes QA warning:
gcc-4.8.2: The /usr/share/info/dir file is not meant to be shipped in a particular package.
(From OE-Core rev: 0b62f8b012d8a128f34bd85a26aa97ea939cbf64)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Duplicate parameters in the tune args are repeated in the
MULTILIB_OPTIONS variable. This leads to incorrect configurations
if the order of the parameters is bad.
(Eg. "mhard-float m32/mhard-float m64" leads to an incorrect config)
This patch finds the common parameters and removes the duplicates.
(From OE-Core rev: 90dc31c24adfa8e916a9c475ae1afc58ad179dfb)
Signed-off-by: Alexandru-Cezar Sardan <alexandru.sardan@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
GCC 4.8 includes a new runtime library, libatomic, which supports
atomic operations not supported by hardware or the OS. Build it,
so other packages can link against it, if needed.
(From OE-Core rev: a4dd6dfccee0be50d3addce3dd1bf903e051ad5a)
Signed-off-by: Cosmin Paraschiv <cosmin.paraschiv@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of using oe.path.relative, use the Python Standard Library function
os.path.relpath.
(From OE-Core rev: 90c3a0401c566e26d89a5c0410b2a51fe27b95b2)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When adding extra symlinks, we have to make sure that the directory
that the links are created in is valid. Added a check for this.
This is an incremental addition to commit
97f2a81d6796ddaf7bbaab86c2ab9039673c732c
(From OE-Core rev: ea297e807f4f84c281e0f8c6c4470ee3f3fa949b)
Signed-off-by: Alexandru-Cezar Sardan <alexandru.sardan@freescale.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix for internal compiler error hit when building lttng-tools_4.2.0:
kernel-consumer.c:324:1: internal compiler error: in gen_movsi, at
config/arm/arm.md:5539
(From OE-Core rev: ec1d5bdf4cc0a7a3e4747b42b7b95805752bea07)
Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[ADT bug #5761] -- https://bugzilla.yoctoproject.org/show_bug.cgi?id=5761
Also this patch adds symlinks to libgcc such that a GCC configured
by passing the target parameter without LIBCEXTENSION and ABIEXTENSION
specifiers to find the correct startup files from a libgcc configured
with these variables.
(From OE-Core rev: 97f2a81d6796ddaf7bbaab86c2ab9039673c732c)
Signed-off-by: Alexandru-Cezar Sardan <alexandru.sardan@freescale.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
GCC 4.8.0, 4.8.1 and 4.8.2 can generate broken epilogues for the
ABI used by the kernel. Apply the patch that is included for GCC
4.8.3 from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854.
The issue was found on Yocto/Dora and the patch should be backported
to this branch. A kernel built with Dora's GCC 4.8.1 misbehaved on:
while true;
do
(for i in `seq 1 100`;
do
echo "Log message... $RANDOM";
done) | logger;
done
busybox's syslogd would from time to read a huge negative value and
then exit, strace would get stuck waiting on a syscall. After this
patch it appears to work better.
(From OE-Core rev: 3004eb3b7ee5fd8dfe9c4e5749b4e125d0bd4b59)
Signed-off-by: Holger Hans Peter Freyther <holger@moiji-mobile.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We've had 4.8 around for a while now, I'm not aware of any issues with
it so we can drop the older 4.7 version.
(From OE-Core rev: 15685dccd37f7636bbdd56af04a9dbc9b7595612)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix statement indenting and spacing issues that I happened to notice.
(From OE-Core rev: d11e297b007aba625b398c52952ec929c3b02b83)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A lot of our recipes had short one-line DESCRIPTION values and no
SUMMARY value set. In this case it's much better to just set SUMMARY
since DESCRIPTION is defaulted from SUMMARY anyway and then the SUMMARY
is at least useful. I also took the opportunity to fix up a lot of the
new SUMMARY values, making them concisely explain the function of the
recipe / package where possible.
(From OE-Core rev: b8feee3cf21f70ba4ec3b822d2f596d4fc02a292)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently the code has problems differentiating between "gcc-cross" and "gcc-cross-initial"
sstate files. We could add in a ton of special casing but tests show this isn't scaling
well. Using a more unique separator resolves the issue.
The choice of which separator to use is a hard one. We need something which isn't commonly
used in PN, PV, PR, *_OS and *_ARCH which rules out '-', '_' and it needs to work ok with
webservers/http which makes ';' and '%' harder.
The change also sets SSTATE_SWSPEC globally since writing out differently named siginfo
files for the fetch/unpack/patch tasks is a waste of diskspace, the hashes match for
all PN in the majority of cases and if they don't, its not a big issue as the hash is
different. This makes the results from sstate debugging more understandable.
(From OE-Core rev: 6f823a23c5f1d0ffa0a27db1c1bc1907de788505)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For a shared workdir, any one of the fetch/unpack/patch tasks may run yet the
PN and architecture fields in SSTATE_PKGSPEC may differ. This makes looking up
the appropriate siginfo file near impossible.
I've tried several different ways of resolving this and this is the neatest
solution I could find, its still rather ugly. I believe the usefulness of
better sstate debugging outweighs the ugliness of the code.
This patch also changes the sstate_checkhashes() code to look for siginfo
files rather than the actual sstate packages themselves. This means the
function can be used in other contexts to find info files for tasks that
may not have sstate data. It is assumed that sstate mirrors will have both
files available. This is done to allow bitbake to query whether tasks have
matching signatures in sstate directories or not.
(From OE-Core rev: 068e4289b597699cbff2dfde44ba833af4535281)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We had disabled the sdt from configure, let's also disable it from
confgure.ac to keep them compatible.
BTW, the libstdc++-v3 of gcc-4.7 doesn't use the sdt, so we don't need
to edit libstdc++-v3/configure as gcc-4.8.
NOTE, this commit edit the patch gcc-4.7/disablesdt.patch directly.
[YOCTO #5657]
(From OE-Core rev: 452c6afc3883b0304e06eb1764614348fb6599c8)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We may meet such an error when building gcc/libstdc++-v3:
gcc-4.8.1/libstdc++-v3/libsupc++/unwind-cxx.h:41:21: fatal error:
sys/sdt.h: No such file or directory
We already have a patch to disable the sdt for gcc, we also need disable
it for libstdc++-v3.
BTW, we need edit both configure.ac and configure to make them keep
compatible.
NOTE, this commit edit the patch gcc-4.8/0031-Disable-sdt.patch directly.
[YOCTO #5657]
(From OE-Core rev: 32854af3cc6c0626620e827dc1915f61c51250b8)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Without this sstate builds can fail with missing dependencies.
(From OE-Core rev: f92ebf78d94cb8f4010f8d444d1d0336c1fb1341)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
gcc 4.8 fortran presents some challenges:
* libquadmath headers need to be in the libexec include dir. It turns out
to be easiest just to manually do this.
* libgfortran configure needs libquadmath to be compiled. This means
a separate recipe is needed (the alternative is gross hacks)
* the libtool uses to link libgfortran doesn't have our improved rpath
handling and puts bogus RPATHS into the libraries. We can avoid this
by tweaking libtool with sed.
This patch resolves those issues. Any user of fortran does need to DEPEND
on libgfortran in order to trigger it to build but this shouldn't be a major
issue.
(From OE-Core rev: a5e7ee5770b9e0cf719c573efffd874440f74289)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using the contains function results in more optimal sstate checksums
resulting in better cache reuse as we as more consistent code.
(From OE-Core rev: 9c93526756e7cbbff027c88eb972f877bcb1f057)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When fortran was enabled, builds were failing due to a extra files.
For now we can remove these and avoid the build failure.
(From OE-Core rev: 2e60ef7fe63974e443a9ddc25c5eb4249ec37963)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
gcc has cross and target components with a shared workdir. The unpack umask
settings need to match for all of these. We need to use strings in each
case to ensure the sstate code matches them correctly.
This patch tweaks various things to ensure the change adding the unpack umask
change doesn't break the compiler builds.
(From OE-Core rev: 67162438ee9c402b23c32853af9d313949eb6e4a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
MIPS gcc is not configured with multiarch enabled. This causes
compiler generates local label with $ prefix, which is specified
in default o32 abi. It is not recognized as local symbol by n64
assembler, so we get a lot of unexpected external symbols. We
should configure MIPS gcc with --enable-targets=all, as for other
archs.
(From OE-Core rev: c210393b3e0c54606493e311d7c2040efebc4dcd)
Signed-off-by: Lei Liu <lei.liu2@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
PowerPC toolchains can use the OS "linux" or "linux-gnuspe". This
patch links them together so the one cross-canadian toolchain can support
both.
GCC_FOR_TARGET is set for the GCC recipe as otherwise configure
can pick up an incorrect value.
[YOCTO #5354]
(From OE-Core rev: a1d6331238982b0c5d39b0a18794f6654b00d46a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Khem Raj
Ross Burton
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
Andre McCurdy
Stefan Müller-Klieser
Bian Naimeng
Dan McGregor
Paul Eggleton
Daniel Dragomir
Joe Slater
Hongxu Jia
Jackie Huang
Saul Wold
Peter A. Bigot
Ting Liu
Paul Gortmaker
Alexandru-Cezar Sardan
Petter Mabäcker
Max Eliaser
Otavio Salvador
Alexandru-Cezar Sardan
Cosmin Paraschiv
Tom Zanussi
Holger Hans Peter Freyther
Lei Liu