aboutsummaryrefslogtreecommitdiffstats
path: root/meta/conf
AgeCommit message (Collapse)Author
2016-02-07security_flags: wipe security flags for gcc/glibc and related librariesKhem Raj
It causes a catch-22 situation where we build libssp in gcc-runtime but also pass -fstack-protector flags which require libssp (From OE-Core rev: 61ef8212cc6880f502f1e05e2683d232ea782ae4) 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>
2016-02-07security_flags: use -fstack-protector-strongKhem Raj
This is a better version of -fstack-protector-all with reduced stack usage and better performance yet giving same amount of coverage. It's available in gcc 4.9 onwards. https://outflux.net/blog/archives/2014/01/27/fstack-protector-strong/ has more details. (From OE-Core rev: 4ca946c029f04ba3991ed0f1f65355a7a7840ff4) 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>
2016-02-07security_flags: ensure security flags only apply to target buildsKhem Raj
As otherwise the security flags can leak into target builds. This can result in flags that the host compiler doesn't support, causing build failures. (From OE-Core rev: ff2c8af73046f55aa733ce8289b6236c88300290) 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>
2016-02-07security_flags.inc: don't do -pie for syslinuxRoss Burton
sysroots/x86_64-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/5.3.0/ld: syslinux.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC (From OE-Core rev: b87a9c82663446fa8c002e144de57127e8902b54) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-02-06gtk-theme-torturer: remove from oe-coreRoss Burton
This recipe is very old, unmaintained, not used at all in OE-Core, and not useful in a world that has moved to GTK+ 3 (even if Sato is slow at catching up). (From OE-Core rev: d9ecac4828cb316230c3681670e7bf6d197e3a30) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-02-06bitbake.conf/native/nativesdk: Set PKG_CONFIG_SYSTEM_ at top levelRichard Purdie
Setting PKG_CONFIG_SYSTEM_{HEADERS/INCLUDE}_PATH for nativesdk isn't enough, we also need to deal with multlib cases where libdir from pkg-config-native isn't correct. Native builds are about the only case where this variable shouldn't be set. Therefore move the code from nativesdk to bitbake.conf and unexport it in the native case. (From OE-Core rev: 46c48c26ab1916e2dfb841d74a0f2a58d8b2b870) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-02-04meta: add ASSUME_PROVIDED dependency on wget-native for http fetchesRoss Burton
For clarity and consistency, add a dependency on wget-native for any URIs that will be fetched using the wget fetcher, and add wget-native to ASSUME_PROVIDED. (From OE-Core rev: 91583704383aef3d4742630380fd3f1d38c4b00a) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-02-04documentation.conf: align the documentation for DEBUG_OPTIMIZATION and ↵Pascal Bach
FULL_OPTIMIZATION with bitbake.conf (From OE-Core rev: 2218490b075b077683f17b643ab211c7716d0dfc) Signed-off-by: Pascal Bach <pascal.bach@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-02-02machine/include: drop tune-cortexm*.inc and tune-cortexr4.incAndre McCurdy
The Cortex M1, M3 and R4 CPU tuning files are poorly tested (if at all). They have no obvious users either inside or outside oe-core. Until OE officially gains support for CPUs without an MMU, these tuning files are probably better maintained outside of oe-core (e.g. in a separate meta-nommu layer). (From OE-Core rev: 7a1445c55de904115b950c8e50432a9f11f02208) Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-02-01binutils: Upgrade to 2.26Khem Raj
(From OE-Core rev: 86ade2cc2553c942d9526c5323a11ae151653505) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-31gcc, qemuppc: Explicitly disable forcing SPE flagsKhem Raj
G4 does not have SPE, so we make that explicit in the tune files and since we emulate G4 when building Qemu, we ensure it for qemuppc as well. GCC config for powerpc-linux is made to include SPE by default which is equivalent if the tripet was powerpc-linux*spe, this forces gcc to configure assembler to enable -mspe by default, when we do that then the kernel fails to compile with binutils 2.26, since newer assembler is smart to detect the tlbia instructions are not compatible with SPE and hence the kernel build breaks rightly. We configure the kernel for G4 as well where it enables tlbia instrucitons rightly so because it thinks its being configured for power4. So we keep the options but do not force -mspe down to assembler as default. (From OE-Core rev: 7a51776a830167e43cbd185505f62f328704e271) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-30bitbake.conf: stop exporting PATCH_GET = "0"Andre McCurdy
Exporting PATCH_GET = "0" has been redundant since patch 2.6.0 was released in 2009: http://git.savannah.gnu.org/cgit/patch.git/commit/?id=b008dece18e6b94b8a13ea44a253855bf407ed01 Host distros which shipped with patch 2.5.x (e.g. Centos 5) are no longer supported, so this export can be retired from bitbake.conf. (From OE-Core rev: e9638fe60d24325e85dacc0c1551f671daed5c06) Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-30libc-package.bbclass: add LOCALE_UTF8_IS_DEFAULTRichard Tollerton
python hard-codes the encoding of many locales; for instance, en_US is always assumed to be ISO-8859-1, regardless of the actual encoding of the en_US locale on the system. cf https://hg.python.org/cpython/file/7841e9b614eb/Lib/locale.py#l1049, getdefaultlocale(), etc. This code appears to date back to python 2.0. The source of this hard-coding is Xorg's locale.alias but is ultimately justified by glibc's SUPPORTED. This causes problems on OE, because any locale lacking an explicit encoding suffix (e.g. en_US) is UTF-8. It has been this way from the beginning (svn r1). That is not a bug, per se -- no specification prohibits this AFAIK. But it seems to be at odds with virtually every other glibc-based distribution in existence. To avoid needlessly aggravating hidden bugs that nobody else might hit, it makes sense to disable this behavior such that locales are named precisely as specified by SUPPORTED. I suppose that reasonable minds may disagree on whether or not the current behavior is prudent; at the very least, this is likely to break IMAGE_LINGUAS settings. So let's create a new distro variable LOCALE_UTF8_IS_DEFAULT to allow either behavior. Set it to 0 and all your locales get named exactly like they are in SUPPORTED. Leave it at 1 to preserve current OE locale naming conventions. (From OE-Core rev: fcde0c43f7b57ec6f8201226ad98e6e46708d288) Signed-off-by: Richard Tollerton <rich.tollerton@ni.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-29documentation.conf: Update the help for BBMASKPeter Kjellerstedt
Since it is now possible to concatenate multiple regular expressions into BBMASK, there is no longer any real reason to limit it to be specified only in local.conf. (From OE-Core rev: 629043e3ec798543a31c3c2f9fa7ca5fa8248228) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-26image.bbclass: check INITRAMFS_MAXSIZERobert Yang
Usually, the initramfs' maxsize can be 1/2 of ram size since modern kernel uses tmpfs as initramfs by dafault, and tmpfs allocates 1/2 of ram by default at boot time, which will be used to locate the initramfs. Set INITRAMFS_MAXSIZE to 131072K (128M) by default (ram 256M), the initramfs is small usually, for example, core-image-minimal-initramfs is about 21M (uncompressed, 17M * 1.3) by default, but if the user add a lot pkgs to initramfs, we can error and stop to let the user know ealier rather than fail to boot (e.g., OOM-killer) at boot time. Please see the bug for more info: https://bugzilla.yoctoproject.org/show_bug.cgi?id=5963 [YOCTO #5963] (From OE-Core rev: 155ba626b46bf71acde6c24402fce1682da53b90) 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>
2016-01-24bitbake: set default libexecdir to $prefix/libexecRoss Burton
The use of $libdir/$BPN as libexecdir is contrary to all other mainstream distributions (which either use $prefix/libexec or $libdir), and the GNU Coding Standards[1] which suggests $prefix/libexec and notes that any package-specific nesting should be done by the package itself. Finally, having libexecdir change between recipes makes it very difficult for different recipes to invoke binaries that have been installed into libexecdir. The File System Hierarchy[2] now recognises the use of $prefix/libexec/, giving distributions the choice of $prefix/lib or $prefix/libexec without breaking FHS. Change bitbake.conf to use $prefix/libexec for libexecdir, so that the binaries are separated from the libraries. This should avoid complications with multilib configurations. [1] https://www.gnu.org/prep/standards/html_node/Directory-Variables.html [2] http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html [ YOCTO #6398 ] (From OE-Core rev: e7270e331560546d3805cd66ed14afcbc96b6d89) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-24linux-libc-headers: update to 4.4Bruce Ashfield
Updating the lib-headers to match the 4.4 LTSI kernel version. (From OE-Core rev: 046b1f4cf439e36c8e8a4904f8e8014a9ea733e2) Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-24bitbake.conf: Remove horrible variable expansion hacksRichard Purdie
We used to need these hacks to make things work. Rework the variables to remove the horrible hacks and make things slightly less ugly. This does mean PE and PRAUTO are given default empty values but this is preferred to the other ugliness. (From OE-Core rev: f37af830448794d3941aca9ab4b2bfa9d8358694) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-20python: Upgrade 2.7.9 > 2.7.11Alejandro Hernandez
- no license change, just dates Rebased: - check-if-target-is-64b-not-host.patch - add-CROSSPYTHONPATH-for-PYTHON_FOR_BUILD.patch (From OE-Core rev: 9ed4ef038a4a8140accfa97b2eb6b75f8bed3693) Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-19security_flags.inc: remove obsolete workarounds for curlAndre McCurdy
The curl configure script contains sanity checks for unexpected options being passed via CFLAGS, LDFLAGS, etc. environment variables. These sanity checks catch -Dxxx options in CFLAGS, which clashes with OE's approach of using CFLAGS to pass -D_FORTIFY_SOURCE (curl's configure script suggests, quite correctly, that -Dxxx options should be passed via CPPFLAGS instead). These sanity checks previously generated fatal errors, but have been downgraded to warnings since curl v7.32. Therefore the workaround of avoiding -D_FORTIFY_SOURCE for curl is obsolete and can be removed. https://github.com/bagder/curl/commit/5d3cbde72ece7d83c280492957a26e26ab4e5cca (From OE-Core rev: d0dfd7bf9b2d6fb269f4d9b62263fd7ccc805fde) Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-18bitbake.conf: rename python-native-runtimeEd Bartosh
The code in native.bbclass adds -native suffix to the package names that don't have it. Renamed python-native-runtime -> hostpython-runtime-native to avoid mangling it and to conform with the naming convetion for native packages. (From OE-Core rev: 8a474057d86b3ebf6271656d6b9adf384ea9ad6d) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-15tcmode-default.inc: Fix preferred provider nativesdk-sdk_prefix-libc-initialMark Hatle
Similar to the libc-for-gcc preferred provider, we also need a libc-initial version. Layers such as meta-mingw need the ability to override these values in order to generate an SDK that works on non Linux environments. (From OE-Core rev: ea4b19ad2e4d259c41c9e09ecb70bc8043509a4f) Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-15gdb: upgrade to 7.10.1Richard Purdie
The PPC inferior patch was dropped since an equivalent fix was merged upstream. (From OE-Core rev: 564c56207edd9a7dcef3ea966580e11a1548115c) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-11meta: rename perl-native-runtimeEd Bartosh
The code in native.bbclass adds -native suffix to the package names that don't have it. perl-native-runtime becomes perl-native-runtime-native because of this. Renamed perl-native-runtime -> hostperl-runtime-native to avoid mangling it and to conform with the naming convetion for native packages. (From OE-Core rev: f4dade8e765a8c7bfd131728b9e0a34631e24950) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-11bitbake.conf: remove 'stamp-base'Chen Qi
Remove 'stamp-base' from this file as this flag is no longer used. [YOCTO #8468] (From OE-Core rev: be6070e54f8fe3b530dce66623287403a50ac8a1) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-11bitbake.conf: add virtual/libiconv-native to ASSUME_PROVIDEDRoss Burton
It's possible for a native recipe to have virtual/libiconv-native as a build dependency, but as we expect that the host provides that add it to ASSUME_PROVIDED. (From OE-Core rev: a5e6f5939c0ee4280eabd7cfc01131052040bc81) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-07x11vnc: remove all references to moved packageIoan-Adrian Ratiu
Together with the move to meta-oe, all references to x11vnc should be removed from oe-core. There are three of these: a distro alias, a packagegroup rdepends and a runtime test. (From OE-Core rev: cfd1e4bcd66a9a542007115647cadb8480330fab) Signed-off-by: Ioan-Adrian Ratiu <adrian.ratiu@ni.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-07tune-*: use mcpu instead of mtune for ARM tunesMartin Jansa
* since: commit cffda9a821a3b83a8529d643c567859e091c6846 Author: Martin Jansa <Martin.Jansa@gmail.com> Date: Tue Sep 11 17:05:45 2012 +0000 arch-arm: define different ARMPKGARCH when different CCARGS are used we don't need to worry about e.g. cortexa7 device upgrading binary package from armv7a feed which would be built with -mcpu=cortexa15, so we can use -mcpu instead of -mtune, because we won't share the binary feed with MACHINEs built with different tune. (From OE-Core rev: f7bb2d4cf18ca8d2a90b4b3b5c6c48dad106ca28) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-07arch-armv7ve: add tune include for armv7ve and use it from cortexa7 and ↵Martin Jansa
cortexa15 * be aware that this -march value is available only in gcc-4.9 and newer: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57907 * -mcpu=cortex15 and -mcpu=cortexa7 conflict with -march=armv7a We either have to stop putting -march in default CCARGS or at least set it compatible one like this patch does. (From OE-Core rev: 35392025f3236f5e5393f9cf0857732da9a2e503) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-07cortexa{7,15,17}: add VFPv4 tunesMartin Jansa
* it was added only to hf cortexa7 in: commit e97d152ca13556b41a236c1a4cfb11e77ff857d7 Author: Kristof Robot <krirobo@gmail.com> Date: Sun Jan 26 10:03:56 2014 +0100 Add Cortex A7 support for NEONv2 & FPv4 * add it to softfp cortexa7 and both versions for cortexa15 and cortexa17 tunes (From OE-Core rev: 109c26d99b6324c1412f440fef85f090518f6da0) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-07feature-arm-vfp.inc: Further simplify with TUNE_CCARGS_MFLOATMartin Jansa
* add TUNE_CCARGS_MFLOAT variable which is used to set -mfloat-abi parameter as well as ARMPKGSFX_EABI suffix in TUNE_PKGARCH and TARGET_FPU * TARGET_FPU was using ARMPKGSFX_FPU, but in most cases we use it only to distinguish between hard and soft abi, not various -mfpu variants which can appear in ARMPKGSFX_FPU (From OE-Core rev: 10bece310ca6e0bbae28665f873f907d751d1057) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-07feature-arm-{neon,vfp}.inc: refactor and fix issuesMartin Jansa
* respect all 4 vfp options ('vfp', 'vfpv3d16', 'vfpv3', 'vfpv4') when setting -mfloat-abi and ARMPKGSFX_EABI, without this change it wasn't possible to use call-convention hard together with vfpv4 * move 'vfpv3d16', 'vfpv3', 'vfpv4' support from feature-arm-vfp.inc to feature-arm-neon.inc the main difference is that feature-arm-vfp.inc is included in arch-armv5.inc while feature-arm-neon.inc only in armv7*.inc, so these options should be added to TUNEVALID also only for armv7* MACHINEs. * support vfpv4 with or without neon when both vfpv4 and neon are in TUNE_FEATURES we want to set only one -mfpu parameter and to neon-vfpv4 * prevent multiple appends to ARMPKGSFX_FPU, we don't want to include e.g. -vfp as well as -vfpv4 when both "vfp" and "vfpv4" are in TUNE_FEATURES * add -mfpu=vfp for tunes with "vfp" in TUNE_FEATURES - before that we were only adding -vfp to ARMPKGSFX_FPU * add TUNE_CCARGS_MFPU variable which is used to set -mfpu parameter as well as ARMPKGSFX_FPU suffix in TUNE_PKGARCH, all enabled values are appended to it based on TUNE_FEATURES and then the last one is used in the actual param and suffix * this prevents multiple -mfpu options in TUNE_CCARGS * !!! This means we need to change TUNE_PKGARCH and PACKAGE_EXTRA_ARCHS for vfpv4, vfpv3d16, vfpv3 tunes, because the -vfp* isn't prependend multiple times. If you're using one of these new DEFAULTTUNES (which were at least partially broken anyway) and depend on working binary package feed upgrade-path, then don't forget to migrate PR service database to new TUNE_PKGARCH. (From OE-Core rev: 6661718158f8fdcdf63b0d48e8fe72d3ac4778f2) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-07arch-armv7a.inc: add vfpv4 support also to softfp and big endiand tunesMartin Jansa
(From OE-Core rev: b4e90a15e6b1e5639b2039adeae26f2c780a7864) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-07arch-armv7a.inc: Fix PACKAGE_EXTRA_ARCHS for tune-armv7atb-vfpv3, ↵Martin Jansa
tune-armv7atb-vfpv3d16, cortexa7thf-neon-vfpv4 (From OE-Core rev: 8c12a71e41fb53a014b8357ae9b30bfd422f86ec) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-07arch-armv5.inc: drop duplicate ARMPKGSFX_DSP and ↵Martin Jansa
PACKAGE_EXTRA_ARCHS_tune-armv5tehf-vfp * both belong and already are in arch-armv5-dsp.inc (From OE-Core rev: 791f52d3b58ce1fd4bfd159deb83a1917d6267f2) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-07arch-armv[456]*.inc: improve indentation like armv7aMartin Jansa
(From OE-Core rev: 5e685647733294315e6c2ce76733c9b9a5ee554b) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-07arm/arch-arm*, tune-cortexa*, tune-thunderx.inc, ↵Martin Jansa
powerpac/arch-powerpc64.inc: Use normal assignment * some tunes were using weak assignment for TUNE_FEATURES, unify all tunes to use normal assignment so it behaves consistently (From OE-Core rev: 0a52bd3ed23e66200401d0836aad783095e7c7a0) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-07arch-armv7a, tune-cortexa*: improve indentationMartin Jansa
* indent the assignments, so that it's easier to see the algoritm how these values are modified and do less errors, see fixes in next commit (From OE-Core rev: f774b44fa007a2a756ada892ede832b1251d940c) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-07arch-armv7a, tune-cortexa*: improve comment VFP -> HFMartin Jansa
* the section bellow the comment adds only HF variants, VFP is already mixed in the softfp sections above (unlike armv5, armv6 tune files where it really was above VFP/DSP section) (From OE-Core rev: 0c60d744f6ec3b77f044ac7d66e30c00d00fea81) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-07arch-armv7a: add missing space before ?=Martin Jansa
(From OE-Core rev: e4502063aae68b8dc31160fb418c74e4f0412cb6) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-07tune-cortexr4.inc: fix PACKAGE_EXTRA_ARCHSMartin Jansa
* PACKAGE_ARCHS were missing TUNE_PKGARCH armv7rt2-vfp because thumb is enabled in TUNE_FEATURES (From OE-Core rev: 51a99e28d0d15e227fc05f43974f54f6d8e62ef5) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-07security_flags.inc: disable -fstack-protector-XXX for valgrindAndre McCurdy
Valgrind (v3.11.0) expects to build with stack protection disabled and includes -fno-stack-protector in its default CFLAGS. However, the CFLAGS provided by OE are included on the compiler command line after the defaults so any -fstack-protector-all / -fstack-protector-strong option provided by security_flags.inc will cause problems. | .../build-bcm97425vms/tmp/work/mips32el-rdk-linux/valgrind/3.11.0-r0/valgrind-3.11.0/coregrind/m_mallocfree.c:892: undefined reference to `__stack_chk_guard' | .../build-bcm97425vms/tmp/work/mips32el-rdk-linux/valgrind/3.11.0-r0/valgrind-3.11.0/coregrind/m_mallocfree.c:947: undefined reference to `__stack_chk_fail' (From OE-Core rev: ff4f46700a4810fcb49c58978b17af4f52fa9925) Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-07meta/conf/layer.conf: bump layer version due to Qt4 removalRoss Burton
Qt4 has been moved to meta-qt4, so increase the layer version so that this can be detected programatically. (From OE-Core rev: 824f0bdbe87f9a847bd7a3bdd9a89bffd58befa8) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-07qt4: remove recipes and classesAlexander Kanavin
Qt4 is no longer supportd upstream, but it is still needed for LSB compliancy. Qt4 recipes have been moved to a separate meta-qt4 layer to be consistent with meta-qt3 and meta-qt5. (From OE-Core rev: cb89d2b25b4edb1241bc5426a69a6bc44df9be2c) Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-06base-utils:flexible dependency for command utilitiesAlejandro Joya
add base-line configuration for command utilities, this will be used instead of hardcoded uses of busybox around the environment. (From OE-Core rev: b14027e361fc0393fa4ee060ecb1088742607533) Signed-off-by: Alejandro Joya <alejandro.joya.cruz@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-12-28tcmode-default: Use glibc for nativesdk version even on uclibc and muslKhem Raj
We do not have musl or uclibc based systems for building OE itself. Most of build servers run glibc, there will be other issues to build OE on a uclibc based build system (From OE-Core rev: 3ec457e7cdc347a98ab561fd3d2a500a218cdeb0) 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>
2015-12-22tune-cortexr4.inc: provide an _armv7r over-ride via MACHINEOVERRIDESAndre McCurdy
(From OE-Core rev: 3911fcb1504f435409501544c908c1704a6fc7b9) Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-12-22tune-cortexm3.inc: provide an _armv7m over-ride via MACHINEOVERRIDESAndre McCurdy
(From OE-Core rev: ed60460459e746ca91b8884526cdb1fc6a3fd640) Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-12-22feature-arm-thumb.inc: drop 'no-thumb-interwork' tuning featureAndre McCurdy
Interworking is required for ARM EABI, so attempting to disable it via a tuning feature no longer makes sense (support for ARM OABI was deprecated in gcc 4.7). We can drop '-mthumb-interwork' from TUNE_CCARGS for the same reason. (From OE-Core rev: d942f94de8966c839209e8c9a632351d108852c4) Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-12-22feature-arm-thumb.inc: drop legacy _thumb and _thumb-interwork over-ridesAndre McCurdy
Bitbake over-rides for _thumb and _thumb-interwork are undocumented and are not used anywhere in oe-core or meta-oe. The logic setting up the thumb-interwork over-ride even seems to be reversed and nobody noticed, so it seems safe to assume that these over-rides are not used. (From OE-Core rev: 351443d71eb246a946b41f12b54d57b36fe1574e) Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit 1.2.3-korg (git 2.39.0) at 2024-04-27 14:37:24 +0000