The behavior before this change was to check USER_CLASSES and adjust
the install script to return either exit 0 (don't do anything) or
exit 1 (run on first boot). This enabled a user to include the prelink
package without enablign the image-prelink bbclass and get a first boot
prelink.
Checking USER_CLASSES is not desired, as an image should be able to simply
inherit the image-prelink and get the same type of behavior. Modifying
the recipe based on the inclusion of a class is a bad idea as it makes
this style work more difficult. So we move to a more defined strategy
based on exist uses. (That we know of...)
If we ae doing a cross install, we want to avoid prelinking.
Prelinking during a cross install should be handled by the image-prelink
bbclass. If the user desires this to run on the target at first boot
they will need to create a custom boot script.
[YOCTO #11169]
(From OE-Core rev: e31c9d32072b9cf62c0e9e55b4d421849d3d489b)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Backport two patches to fix the following error when booting qemu.
Failed to unlock byte 100
(From OE-Core rev: 91eee8b08cd52f49bb1c8f8c680607b3f3a52d24)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
CVE-2017-9226 : check too big code point value for single byte
CVE-2017-9227 : access to invalid address by reg->dmin value
CVE-2017-9228 : invalid state(CCS_VALUE) in parse_char_class()
CVE-2017-9229 : access to invalid address by reg->dmax value
(From OE-Core rev: f15f01edbaa431829a50053d07ed6d6b333584c7)
Signed-off-by: Joe Slater <jslater@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The release version was actually working correctly; it only makes
the warning work properly.
(From OE-Core rev: e7986a5493ccd222b82c2388ea8c3bb7004b48dd)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
CURL_FORMAT_OFF_T does not seem to exist anymore, use
CURL_FORMAT_CURL_OFF_T instead. This works with old and new curl.
(From OE-Core rev: 5548f9c87c6a10cda2baf6f198762380e55f6ae2)
Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
do_configure() will no longer convert references to
/usr/include into /path/to/recipes-sysroot/usr/include
for the file "Porting/Glossary".
[YOCTO #11243]
(From OE-Core rev: cb2dfe5627df2ff235b37622260484841f39af17)
Signed-off-by: Ooi Cinly <cinly.ooi@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Removed all instances of -fdebug-prefix-map in LTCFLAGS
declaration because they contain references to host system
and are not needed.
/absolute/path/to/host/dd was replaced with 'dd' in
lt_truncate_bin declaration.
Please take note that the location of regex is important
for DEBUG_PREFIX_MAP. Removal of DEBUG_PREFIX_MAP has to be
done before other regex command modify its option value.
Both are modified because they affect binary reproducibility.
[YOCTO #11656]
(From OE-Core rev: 04db02138e363898e040e33557f1296e8a43c3fd)
Signed-off-by: Ooi Cinly <cinly.ooi@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Disable build for muslx32.X32 isn't supported by valgrind at this
moment.
(From OE-Core rev: a945141062ac3d0736558be428f60af405b53a94)
Signed-off-by: sweeaun <swee.aun.khor@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
OE-core commit 800753069f667cd1664d70b3779150c467e3b3fe remove
RPROVIDES list to get runtime dependences from manifest file.
python3-misc is added in python3 recipe, we need to add
native runtime to use python3-misc with native recipes.
(From OE-Core rev: 31fd20811f6d11e7ed6ac84caf776ac46cd6fb6f)
Signed-off-by: Fabio Berton <fabio.berton@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
mkelfimage uses different flags to compile as freestanding binary
it does not pour CFLAGS into them during configure as a result
-fno-stack-protector was never used. Which failed to build with
compilers configured to build with ssp by default. It worked with
gcc since we do not configure our toolchain to default to ssp
Fixes errors e.g.
| objdir/linux-i386/convert_params.o: In function `convert_params':
| linux-i386/convert_params.c:(.text+0x9f4): undefined reference to `__stack_chk_fail'
| objdir/linux-i386/convert_params.o: In function `compute_checksum':
| linux-i386/convert_params.c:(.text+0xa71): undefined reference to `__stack_chk_fail'
| objdir/linux-i386/convert_params.o: In function `printf':
| linux-i386/convert_params.c:(.text+0xcc7): undefined reference to `__stack_chk_fail'
| make: *** [linux-i386/Makefile:24: objdir/linux-i386/convert] Error 1
(From OE-Core rev: f6ed82482838e34202721be8f40ca1cc340c325e)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When rpmdeps files a perl script, it attempts to determine what it provides
and what it requires. Often the requires are incorrect, within the context
of Wind River Linux. This results in an error that DNF is unable to install
a package due to one or more unresolved dependencies.
In RPM5 we had disabled this behavior, the alternative is to require that all
perl scripts be 'complete', in that they only require things they absolutely
need and that OE provides. If we ever enforce that, this commit can be
reverted. Until they fall back to prior behavior (which also matches ipkg
and deb style packages.)
(From OE-Core rev: 99376f602c997fec96dbb28ddbe3fa5f68fde2c3)
(From OE-Core rev: 586875cea5769fea7d17bae2677eab72e4fc7e31)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In order to support Nios2 emulation by QEMU, we need
at least QEMU version 2.9.
(From OE-Core rev: f2d725d9268563f7bbcac770a34aceacb56cb2aa)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When Thumb1 is used as default ISA, there are linker
issues, therefore always use ARM ISA
Fixes
relocation truncated to fit: R_ARM_THM_CALL against symbol `__gnu_thumb1_case_uhi' defined in .text section
(From OE-Core rev: a0c9d19b46ccefbb90eea5965e11ea21d13242b4)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These git commands require Perl modules that do not exist in OE-Core.
Add PACKAGECONFIGs to enable them. Be aware though that if you enable
them you must also provide the missing dependencies.
(From OE-Core rev: d7909007b2a912ae5adf01edfabaa8b8646369cd)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This makes it possible to enable 'repo_gpgcheck' in dnf.conf. That is, do
GPG signature check on repository metadata. Without gnupg dnf fails with
"error: Invalid crypto engine."
[YOCTO #11209]
(From OE-Core rev: 8a7154cfe150840b451bc56951f0fa31cb8d6fa0)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
getentropy/random() is only available in glibc 2.25+ and uninative may relocate
binaries onto systems that don't have this function. For now, force the code to
the older codepaths until we can come up with a better solution for this kind of
issue.
(From OE-Core rev: 92bda0024d85ae78345665cc2f9646c9881ed61b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The compiled .pyc files contain time stamp corresponding to the compile time.
This prevents binary reproducibility. This patch allows to achieve binary
reproducibility by overriding the build time stamp by the value
exported via SOURCE_DATE_EPOCH.
Patch by Bernhard M. Wiedemann.
[YOCTO#11241]
(From OE-Core rev: 2175aec10a764bfc925a3fb447547982d0ae662f)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When compressing by gzip, do not save the original file name and time stamp.
[YOCTO #11916]
(From OE-Core rev: c32d526a056adb8ed1eb8beb9d495bfd01af2342)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
python3-docutils recipe must be upgraded to latest stable release.
LIC_FILES_CHKSUM changed due to a typo fix from previous version,
but license type and information remained the same.
This change was tested on qemu with core-image-minimal.
(From OE-Core rev: f99247335485e15c820991e3ea20b766364111fc)
Signed-off-by: Jose Lamego <jose.a.lamego@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Both python-setuptools and python3-setuptools must be updated
to latest stable release.
These changes were tested on qemu with core-image-minimal
(From OE-Core rev: 147d9260eb79edfdf7a91fb8bc3d915f141dc685)
Signed-off-by: Jose Lamego <jose.a.lamego@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In case a systemd service disables itself while init is still in its
boot sequence the reloading of the service files can be problematic.
In that case: It seems that systemd looses the state of .device units,
and some services depend on such units (namely serial consoles such as
serial-getty@ttymxc0.service). As a result no getty is spawned on the
affected serial tty.
After a power-cycle the second boot (which does not disable services)
succeeds.
The following sequence shows this problem:
| Jan 09 16:36:28 apalis-t30 systemctl[162]: Removed /etc/systemd/system/sysinit.target.wants/run-postinsts.service.
| Jan 09 16:36:28 apalis-t30 systemd[1]: Reloading.
| ...
| And then the failing one:
| Feb 22 15:33:15 apalis-t30 systemd[1]: dev-ttyS0.device: Job dev-ttyS0.device/start timed out.
| Feb 22 15:33:15 apalis-t30 systemd[1]: Timed out waiting for device dev-ttyS0.device.
| Feb 22 15:33:15 apalis-t30 systemd[1]: Dependency failed for Serial Getty on ttyS0.
| Feb 22 15:33:15 apalis-t30 systemd[1]: serial-getty@ttyS0.service: Job serial-getty@ttyS0.service/start failed with result 'dependency'.
| Feb 22 15:33:15 apalis-t30 systemd[1]: dev-ttyS0.device: Job dev-ttyS0.device/start failed with result 'timeout'.
| Feb 22 15:33:15 apalis-t30 systemd[1]: Reached target Login Prompts.
(the time has been updated between this two events, but that does not
influence the issue)
Using --no-reload in the service file avoids the "Reloading." message
above and seems to not cause such issues anymore.
Reported-by: Stefan Agner <stefan.agner@toradex.com>
(From OE-Core rev: 23b359b6e26d0b17037bf955bd15a16a3fd9ab8f)
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
(cherry picked from commit 4a425d05bac5dcba023b67aa3d726f7e7869404f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In case a systemd service disables itself while init is still in its
boot sequence the reloading of the service files can be problematic.
In that case: It seems that systemd looses the state of .device units,
and some services depend on such units (namely serial consoles such as
serial-getty@ttymxc0.service). As a result no getty is spawned on the
affected serial tty.
After a power-cycle the second boot (which does not disable services)
succeeds.
The following sequence shows this problem:
| Jan 09 16:36:28 apalis-t30 systemctl[162]: Removed /etc/systemd/system/sysinit.target.wants/run-postinsts.service.
| Jan 09 16:36:28 apalis-t30 systemd[1]: Reloading.
| ...
| And then the failing one:
| Feb 22 15:33:15 apalis-t30 systemd[1]: dev-ttyS0.device: Job dev-ttyS0.device/start timed out.
| Feb 22 15:33:15 apalis-t30 systemd[1]: Timed out waiting for device dev-ttyS0.device.
| Feb 22 15:33:15 apalis-t30 systemd[1]: Dependency failed for Serial Getty on ttyS0.
| Feb 22 15:33:15 apalis-t30 systemd[1]: serial-getty@ttyS0.service: Job serial-getty@ttyS0.service/start failed with result 'dependency'.
| Feb 22 15:33:15 apalis-t30 systemd[1]: dev-ttyS0.device: Job dev-ttyS0.device/start failed with result 'timeout'.
| Feb 22 15:33:15 apalis-t30 systemd[1]: Reached target Login Prompts.
(the time has been updated between this two events, but that does not
influence the issue)
Using --no-reload in the service file avoids the "Reloading." message
above and seems to not cause such issues anymore.
Reported-by: Stefan Agner <stefan.agner@toradex.com>
(From OE-Core rev: 059bc9b164d239f0ba319f8e6a54b5edf7761b22)
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
(cherry picked from commit 16b7b455ee40fd1be5bb9aacf24b106df0d9325e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In case a systemd service disables itself while init is still in its
boot sequence the reloading of the service files can be problematic.
In that case: It seems that systemd looses the state of .device units,
and some services depend on such units (namely serial consoles such as
serial-getty@ttymxc0.service). As a result no getty is spawned on the
affected serial tty.
After a power-cycle the second boot (which does not disable services)
succeeds.
The following sequence shows this problem:
| Jan 09 16:36:28 apalis-t30 systemctl[162]: Removed /etc/systemd/system/sysinit.target.wants/run-postinsts.service.
| Jan 09 16:36:28 apalis-t30 systemd[1]: Reloading.
| ...
| And then the failing one:
| Feb 22 15:33:15 apalis-t30 systemd[1]: dev-ttyS0.device: Job dev-ttyS0.device/start timed out.
| Feb 22 15:33:15 apalis-t30 systemd[1]: Timed out waiting for device dev-ttyS0.device.
| Feb 22 15:33:15 apalis-t30 systemd[1]: Dependency failed for Serial Getty on ttyS0.
| Feb 22 15:33:15 apalis-t30 systemd[1]: serial-getty@ttyS0.service: Job serial-getty@ttyS0.service/start failed with result 'dependency'.
| Feb 22 15:33:15 apalis-t30 systemd[1]: dev-ttyS0.device: Job dev-ttyS0.device/start failed with result 'timeout'.
| Feb 22 15:33:15 apalis-t30 systemd[1]: Reached target Login Prompts.
(the time has been updated between this two events, but that does not
influence the issue)
Using --no-reload in the service file avoids the "Reloading." message
above and seems to not cause such issues anymore.
Reported-by: Stefan Agner <stefan.agner@toradex.com>
(From OE-Core rev: e735c176361fca43420565dcb8900bbff2f3664e)
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
(cherry picked from commit 94fabe4b03e899d8876027ee2ced649737a9e522)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Under some rare circumstances we may end up with GCC segmentation fault.
This was observed with versions of sysmacros.h, which contain macros
with embedded warning messages :
When trying to actually display the warning, we may end up with a segmentation
fault instead. The reason is the actual warning message gets parsed (the text is
unquoted) and words in the message such as "not", "and" etc. are interpreted as
operators CPP_NOT, CPP_AND. When the time comes to display the warning, the code
uses wrong structure to access the "name" corresponding to the operators.
[YOCTO #11738]
(From OE-Core rev: 6f81fe4f3a1177c0049b26a070e43546bc6fe974)
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>
Add a patch to force a native build for a helper binary
(which is not installed or used outside of the build process).
(From OE-Core rev: 35e3ed68fd25941e3d76e5a063299b1d1cee0e70)
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>
In upstream, the following commit:
e711cafab1
...
commit e711cafab13efc9c1fe6c5cd75826401445eb585
Author: Benjamin Peterson <benjamin@python.org>
Date: Wed Jun 11 16:44:04 2008 +0000
Merged revisions 64104,64117 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
...
(see diff in setup.py)
It assigned libraries for multiprocessing module according
the host_platform, but not pass it to Extension.
In glibc, the following commit caused two definition of
sem_getvalue are different.
https://sourceware.org/git/?p=glibc.git;a=commit;h=042e1521c794a945edc43b5bfa7e69ad70420524
(see diff in nptl/sem_getvalue.c for detail)
`__new_sem_getvalue' is the latest sem_getvalue@@GLIBC_2.1
and `__old_sem_getvalue' is to compat the old version
sem_getvalue@GLIBC_2.0.
If not explicitly link to library pthread (-lpthread), it will
load glibc's sem_getvalue randomly at runtime.
Such as build python on linux x86_64 host and run the python
on linux x86_32 target. If not link library pthread, it caused
multiprocessing bounded semaphore could not work correctly.
...
>>> import multiprocessing
>>> pool_sema = multiprocessing.BoundedSemaphore(value=1)
>>> pool_sema.acquire()
True
>>> pool_sema.release()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: semaphore or lock released too many times
...
And the semaphore issue also caused multiprocessing.Queue().put() hung.
(From OE-Core rev: ca1542cdf6b6437a2f3dcdb33ac5216bf841c04a)
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>
This was needed when we were conflicting with clang-native
but this is solved via append PN to binaries of llvm-native
(From OE-Core rev: 82ea78bd2f03b6ba4d720595d3a3fbd96e0232f9)
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>
When parsing this recipe on an unsupported or non-mappable architecture
an error is generated despite no dependencies on the recipe. E.g.
ERROR: .../llvm_git.bb: cannot map 'microblazeel' to a supported llvm architecture
Instead of generating an error which might confuse users, raise a
SkipRecipe exception similar to other arch-style mapping functions (e.g.
go_map_arch). This avoids showing the error during parse, and prevents
the use of the recipe on unsupported targets. Resulting in an error like
so when trying to build llvm:
ERROR: Nothing PROVIDES 'llvm'
llvm was skipped: Cannot map 'microblazeel' to a supported LLVM architecture
(From OE-Core rev: d796abac982f368aa088a291560b565cc47a2c27)
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We have a variable YOCTO_ALTERNATE_EXE_PATH to point to
target sysroot, utilize this in mesa to use native version
of llvm-config to report values from target sysroot.
(From OE-Core rev: 1c4444f7b2f5cbcaaf6f9d21d7b4f86555ed746a)
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>
Alioth always redirects, so we might as well save time by looking in the right
place.
(From OE-Core rev: e681e25fb8fb97a8592df69180d2fd85d136352c)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is highlighted when CC is passing flags like -fPIE
which are stripped by libtool when building shared libs
and replaced with -fPIC, this actually results in CC
not matching the CC computed from cmdline created for
compiling and as a result libtool heuristic to compute
tags auotmatically fails.
(From OE-Core rev: 519c34adeb0735f6ff606addd00a7bbe19f4b15c)
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>
Fixes
| /mnt/a/oe/build/tmp/work/corei7-64-bec-linux/python3-pycairo/1.10.0-r2/recipe-sysroot-native/usr/bin/x86_64-bec-linu
x/x86_64-bec-linux-ld: src/cairomodule.c.1.o: relocation R_X86_64_PC32 against symbol `CairoError' can not be used whe
n making a shared object; recompile with -fPIC
(From OE-Core rev: 058b155a66c5f81573379d258250323c72901ff7)
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>
External compilers will explicitly pass -fPIE -pie flags
unlike internal toolchain which does not use them, so the build
fails with external toolchains because, its passing these
flags to linker when building with -r option and fails to link
| /mnt/a/oe/build/tmp/work/corei7-64-bec-linux/go/1.8.3-r0/recipe-sysroot-native/usr/bin/x86_64-bec-linux/x86_64-bec-linux-ld: -r and -pie may not be used together
(From OE-Core rev: bb89849b5edb05a953586d190826a67ba87c1c5a)
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>
libtool tries to guess the --tag value based on CC/CXX environment
variables and the compile commandline generated by makefiles. This
heuristics however fails when we construct CC variables in OE
and add security flags to it, especially -fPIE -pie which are added
by external compilers e.g. clang particularly. It fails because
libtool removed PIE flags from compiler cmdline intelligently
if it figures out that its building a library, which means that
the CC variable passed from cmdline does not match with the compiler
cmdline constructed by libtool and we end up with errors like
| arm-bec-linux-musleabi-libtool: compile: unable to infer tagged configuration
| arm-bec-linux-musleabi-libtool: error: specify a tag with '--tag'
This works with internal gcc toolchain because we configure gcc for
PIE when hardening is selected and dont pass -fPIE -pie options explicitly
but this is not an option for clang, and some external gcc toolchains
using older gcc
This patch adds the --tag option to help libtool set correct tags
in packages where it cant get it right via its heuristics
(From OE-Core rev: 0505075ae8d339ba097aebb82b4d0ae62f87c0a9)
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>
Instead of moving aclocal.m4 to acinclude.m4 in a custom do_configure, simply
tell autoreconf not to run aclocal.
(From OE-Core rev: 5cc53ea9347035f96a721ab057a338eded5c5c67)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
