The 66e32244aed8d33f1b49fbe78179f2442545c730 wrongly removed gudev from
PACKAGECONFIG, now add it back.
(From OE-Core rev: 5c90b561930aac1783485d91579d313932273e92)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For some reason that I don't understand (a decade-old attempt at optimisation?)
libaio disables linkage to the system libraries. Enabling fortify means linking
to the system libraries, so remove the existing addition of -lc for x86 (the
problem also happens on at least PPC) and just link to the system libraries on
all platforms.
Also remove the sed of src/Makefile as the build not respecting LDFLAGS has been
fixed upstream.
(From OE-Core rev: f435ac9db0581d8313a38d586b00c2b3de419298)
(From OE-Core rev: 901af5a00338fd8f1ace939123484ea91c090a7a)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In oe-core commit a46d3646a3e1781be4423b508ea63996b3cfca8a
...
Author: Fahad Usman <fahad_usman@mentor.com>
Date: Tue Aug 26 13:16:48 2014 +0500
logrotate: obey our flags
Needed to quiet GNU_HASH warnings, and some minor fixes.
...
it explicitly move logrotate to /usr/bin without any reason,
which is against the original Linux location /usr/sbin.
So partly revert the above commit which let logrotate be
kept in the original place /usr/sbin.
(From OE-Core master rev: 0007436b486fd0bea9e6ef60bf57603e7cfce54b)
(From OE-Core rev: c0a13c410393ce51a2a55e36a0913c0136058bdc)
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>
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Without an explicit license, cairo-script-interpreter inherits
the default LICENSE and isn't packaged in builds which blacklist
GPLv3.
(From OE-Core master rev: cb8f84218b065fed88a8c36f3c78065e8ab726bf)
(From OE-Core rev: 6d0cf8ebde4eaa2c868dac8d0dac498c4210ec05)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A bug in glibc 2.22's ld.so interface for the prelink support causes
the displayed values to be incorrect. The included path fixes this
issue.
Clear ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA for prelink
prelink runs ld.so with the environment variable LD_TRACE_PRELINKING
set to dump the relocation type class from _dl_debug_bindings. prelink
has the following relocation type classes:
where ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA has a conflict with
RTYPE_CLASS_TLS.
Since prelink doesn't use ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, we
should clear the ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA bit when the
DL_DEBUG_PRELINK bit is set.
(From OE-Core master rev: 12c86bdcc60c54e587a896b0dceb8bb6cc9ff7e3)
(From OE-Core rev: 73919830f88f2d28da973e72fbdfaab591a5af69)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
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 master rev: 70c55aada1101a5c687cdaa79f370fa4530b39d9)
(From OE-Core rev: 44adc575be5d9b9ad0d87e143467aeeadde2fe89)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix the following issues:
IA32 / ARM - Resync to glibc-2.22, fix a mismatch w/ glibc's ld.so
MIPS - Ignore the new SHT_MIPS_ABIFLAGS
ARM - Fix missing ARM IFUNC support chunk
Also upstream prelink project no longer has a 'trunk' directory.
(From OE-Core master rev: c725328f2ab5c9b220c552ed37c0d24b098a218d)
(From OE-Core rev: de7f25e9d67b150db4780bb82ef9481982e81312)
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>
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
OpenJDK-8 has it's configure script at common/autotools - which will cause
the entire assumption of ${S}/configure is regenerated by autoreconf, intltoolize or alike
fails heavily.
Also - other configure mechanisms can be supported more similar (see how pkgsrc
manages different ones ...)
(From OE-Core master rev: fe506eddb0790e37ac1e50f37fa2e32ad81d5493)
(From OE-Core rev: 809df21d8a8cc4ab860a84ccd7b2e51105df68ee)
Signed-off-by: Jens Rehsack <sno@netbsd.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
On Ubuntu-system, When sourcing the env.sh from an exported sdk, and
running a bogus linux command (for example "asd"), a core dump of
python is usually generated.
Unset the command_not_found_handle to fix it.
(From OE-Core master rev: 473ccbebb426df757adb8955eaa5e191d88180d1)
(From OE-Core rev: fe622c4508d2c87f7bd7c15c6391c8e1319fd3b6)
Signed-off-by: Fang Jia <fang.jia@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we're upgrading a recipe that fetches from git, and we've simply
fetched a tarball of the repo instead of directly from the upstream repo
(this can happen if you have PREMIRRORS set up as in poky with a core recipe,
e.g. kernelshark) then we won't have any new revisions, and the checkout
will fail with "fatal: reference is not a tree: <hash>". To avoid this,
do a "git fetch" before checking out the new revision.
(From OE-Core master rev: c4daebf3fe797a8063dcbc2ab229be2fbedc8134)
(From OE-Core rev: 2c8afd6aae775ab10dd30eb890fc410739048d79)
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>
If we're upgrading a git recipe the recipe file usually won't need
renaming; for some unknown reason we were throwing an error here which
isn't correct.
(From OE-Core master rev: 656348dff9bc9dd1cafc8fff11e5e374e3667f0f)
(From OE-Core rev: 9816c0a2ad2c1011e298d734576b531de9947740)
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>
This code was clearly never tested. Fix the following issues:
* Actually set SRCREV if it's been specified
* Enable history tracking and reparse so that we handle if variables are
set in an inc file next to the recipe
* Use a more accurate check for PV being in the recipe which will work
if it's in an inc file next to the recipe
(From OE-Core master rev: 8b8f04226ebf464fa61c05ca7af7c6cbda392339)
(From OE-Core rev: 105a7c90dac6f43b7c3d1de92827db2db8419112)
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>
If you did a "devtool add" followed by "devtool upgrade" and then did
a "devtool reset" on the recipe you upgraded, the first recipe would
also be deleted from the workspace - this was because we were
erroneously adding the entire "recipes" subdirectory and its contents to
be tracked for removal on reset. Remove the unnecessary call to
os.path.dirname() that caused this.
(From OE-Core master rev: 65354e066f87df7d3138adceb22d6a05d1685904)
(From OE-Core rev: c44d41b0dec7457c4347a00b21d8b5bd24a9b887)
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>
The external source of kernel has been patched during the
construction of git repository. Include the do_patch task in the
SRCTREECOVEREDTASKS.
(From OE-Core master rev: 0731c5a9e98f7b7f6e5ada9bbb99acb3f5884516)
(From OE-Core rev: e82466ebd9c8b9277255680d5efdd76eabf125b1)
Signed-off-by: Tzu-Jung Lee <roylee17@currantlabs.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you put an $ character in the path, SDK installation fails during the
preparation stage, so add this to the disallowed characters.
Fixes [YOCTO #8625].
(From OE-Core master rev: 654f4785f719552f4e78e14a5a901c07d00ce68d)
(From OE-Core rev: d7bcdb33a675fbdd30596d62961be52aa98c9e05)
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>
* Print some status when running
* When incorrect number of arguments specified, print usage text
(From OE-Core master rev: ac38d245878b618ddf56f9a68834d344500e45a6)
(From OE-Core rev: 5c5953cbc44c7532650cb9e3c877fa86c9d0f242)
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>
buildtools-tarball uses a custom env setup script, which isn't named the
same as the default; thus unfortunately OE-Core revision
a36469c97c9cb335de1e95dea5141038f337df95 broke installation of
buildtools-tarball. Revert that and implement a more robust mechanism.
(From OE-Core master rev: 00e081b81ba8118959b724269ba9d18d42aba8a4)
(From OE-Core rev: feefaceb8a2bce8129aba82d4d93e725656ee075)
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>
In the case where many environment-setup-* files exist, the incorrect
filename might be lastly set in env_setup_script, which leads to
incorrect behaviour for the initialization of native_sysroot.
The scenario I had was that our custom meta-toolchain-*.bb, which
inherits populate_sdk, defined another environment-setup-* file to dump
variable information for qt-creator. The file is named like so in order
for the sdk shell script to pick it up and fix the SDK paths in the
file. Since it (coincidentally) alphabetically comes after ...-core2, it
was last set in env_setup_script and the grep OECORE_NATIVE_SYSROOT
would simply be blank. The apparent symptom was "...relocate_sdk.py:
Argument list too long" since the find command would not be searching in
the right path.
(From OE-Core master rev: a36469c97c9cb335de1e95dea5141038f337df95)
(From OE-Core rev: 2f04a9285cfabdb053dafacd17320f847ac6343f)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We want to support different names for the buildtools tarball. The
name may not always be of the default oe-core format.
For instance, at Wind River we define the built-tools name to be:
${SDK_ARCH}-buildtools-nativesdk-standalone-${DISTRO_VERSION}
because thes standard SDK_NAME has additional information that is not
relevant to the builtools tarball.
(From OE-Core master rev: b49c6f179b06a8b97106aa4c95f2cdb3c4dc0920)
(From OE-Core rev: ed92440d19e5948aa64c95fcf30b989c5e6efdb9)
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>
The extensible SDK relies upon uninative, and with the way that
uninative works, the build system architecture must be the same as the
SDK architecture or the extensible SDK won't be usable. At some point in
future hopefully we can remove this limitation, but until then it's
disingenuous to allow this to build, so add a check to ensure
SDK_ARCH == BUILD_ARCH and fail if it isn't.
(From OE-Core master rev: 9e30e849eda3b0a0c54d3f7ed0102760fdaef06c)
(From OE-Core rev: 1042d020d5d1b6af3f32e5fe29562d1dce765f0a)
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>
If you have a local workspace layer enabled when building the
extensible SDK, we explicitly exclude that from the SDK (mostly because
the SDK has its own for the user to use). Adjust the message we print
notifying the user of this so it's clear that we're excluding it from
the SDK, and scale it back from a warning to a note printed with
bb.plain().
(From OE-Core master rev: 90f46f74a088a7b965d2205eceb9eff6f276dd38)
(From OE-Core rev: dbacd35c0db2e9f4b9b2a20ffa6bcc5f78432d8a)
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>
When SDK preparation fails:
* Insert an ERROR: in front of the error message
* Add an error message to the environment setup script
Hopefully this should make it more obvious when this happens.
Fixes [YOCTO #8658].
(From OE-Core master rev: 105df569b3b1982005c2edb37f4690f9ba6bde35)
(From OE-Core rev: 98215b9513212b7002d072afa763347520544ee0)
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>
Use a variable for the log file which includes the full path; this is
not only neater but avoids us writing the first part (the output of
oe-init-build-env) to a file in another directory since we are
changing directory as part of this subshell.
(From OE-Core master rev: 001af71752a9e9aab460cbd49ed049e1eb726295)
(From OE-Core rev: dded5f93d5650ebe5eb661a5cec698b1fa82e1ba)
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>
Fixes the following warning sometimes appearing during image builds:
WARNING: The license listed ABC was not in the licenses collected for recipe xyz
The files being looked for here, which runs during do_rootfs,
are written out by the do_populate_lic task for each recipe. However,
there was no explicit dependency between do_rootfs and all of the
do_populate_lic tasks to ensure they had run - only an implicit link via
do_build, so it is possible that sometimes they had not depending on how
the tasks were scheduled. Add an explicit set of dependencies to fix
this.
(From OE-Core master rev: ef7dc532e800d9b170246550cbc8703adf624beb)
(From OE-Core rev: f521d8d2d1ea495383f54e5e7c2754dde007f7eb)
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>
Fixes the following error showing up for layers that aren't a git repo
(or aren't parented by one):
fatal: Not a git repository (or any of the parent directories): .git
This was because we weren't intercepting stderr. We might as well just
use bb.process.run() here which does that and returns stdout and stderr
separately.
(This was a regression that came in with OE-Core revision
3aac11076e).
Fixes [YOCTO #8661].
(From OE-Core master rev: f533c1bf4c6edbecc67f9e2c62fd475d64668e86)
(From OE-Core rev: 8968ede9c8cdcd2cbf13bd5bba95883082189908)
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>
Fix test_layer_appends to work when build directory is not inside
COREBASE.
Fixes [YOCTO #8639].
(From OE-Core master rev: 0f146e77655d153d3f9a59e489265450f08c6ad7)
(From OE-Core rev: e353b303e271368426e71810bb75173ca6f53455)
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>
Fix test_devtool_update_recipe_git to work when build directory is not
inside COREBASE.
Fixes [YOCTO #8639].
(From OE-Core master rev: 0225888207f82e5f1d9e3dffb7c342a10169aea3)
(From OE-Core rev: 16250994516ff907e18e71158aeb15e4d637de63)
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>
We weren't splitting SRC_URI values containing multiple URIs here; this
didn't cause any errors except when a trailing ; was left on a URI, in
which case the next URI was considered part of the parameter, which
didn't contain a = and therefore was considered invalid.
We only care about the first URI in SRC_URI in this context (since
that's the upstream URI by convention) so split it as we should and take
the first item.
Fixes [YOCTO #8645].
(From OE-Core master rev: 8e75b7e7d54e5638b42b9e7f90f2c6c17e62033f)
(From OE-Core rev: a28eba9fb03720c805eae02c3d0aebf9294e300b)
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>
Previously UNINATIVE_LOADER was always ld-linux-x86-64.so.2. That is
incorrect when the host is 32-bit.
This change also changes to using ?= so the user can override
UNINATIVE_LOADER if so desired.
[YOCTO #8124]
(From OE-Core master rev: b78fa0bcadd54bb29b6f1bb3a9308d4c454bf4e2)
(From OE-Core rev: b901a3057ff511f4c8bc730b37b967a93995de2f)
Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The crypto_use_bigint_in_x86-64_perl patch uses the "bigint" module to
transparently support 64-bit integers on 32-bit hosts. Whilst bigint (part of
bignum) is a core Perl module not all distributions install it (notable Fedora
23).
As the error message when bignum isn't installed is obscure, add a task to check
that it is available and alert the user if it isn't.
[ YOCTO #8562 ]
(From OE-Core master rev: 2f9a2fbc46aa435a0a7f7662bb62029ac714f25a)
(From OE-Core rev: 7aab4744a329f5fd1aca221950ef629e9f92b456)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* we don't want the do_package signature depending on INHERIT variable
* e.g. just adding the own-mirrors causes texinfo to rebuild:
# bitbake-diffsigs BUILD/sstate-diff/*/*/texinfo/*do_package.sig*
basehash changed from 015df2fd8e396cc1e15622dbac843301 to 9f1d06c4f238c70a99ccb6d8da348b6a
Variable INHERIT value changed from
' rm_work blacklist blacklist report-error ${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO} ${INHERIT_BLACKLIST} sanity'
to
' rm_work own-mirrors blacklist blacklist report-error ${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO} ${INHERIT_BLACKLIST} sanity'
(From OE-Core rev: 9cee82c8267f8bc0cb5fa4c7313f9682edf1ce2d)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* without this the do_rootfs task doesn't respect OPKGLIBDIR and
info, status are created in different directory than opkg on
target expects
* people who modify OPKGLIBDIR need to make sure that opkg.conf included
in opkg package also sets info_dir and status_file options
(From OE-Core rev: 48a6d618d4b39058bf04a6cb0d8c076ae5da4013)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The Wayland support requires GLES2 to be enabled as otherwise the EGL support
code in SDL2 isn't enabled.
| In file included from .../SDL2-2.0.3/src/video/wayland/SDL_waylandvideo.c:34:0:
| .../SDL2-2.0.3/src/video/wayland/SDL_waylandvideo.c: In function 'Wayland_CreateDevice':
| .../SDL2-2.0.3/src/video/wayland/SDL_waylandopengles.h:38:38: error: 'SDL_EGL_GetSwapInterval' undeclared (first use in this function)
| #define Wayland_GLES_GetSwapInterval SDL_EGL_GetSwapInterval
Solve this by adding gles2 to the Wayland PACKAGECONFIG option.
(From OE-Core rev: 0f7f15ed02ec0f7b08b9ef62f6eca6c0c1e5a73f)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
