Some newer libraries and programs use RUNPATH to specify the library
search path. These executables were being skipped by the rpath fixup
code because it was grepping the ELF header for RPATH only. A more
correct solution is to ask patchelf to report the rpath, as that tool
will properly report either RPATH or RUNPATH as appropriate.
(From OE-Core rev: d1e88ad01df9b6419e02f632b1ba288d4cc3b2bf)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Modifies the icecc-create-env script so that it can log output to a log
file. In addition, a --debug flag is added that allows verbose logging.
Finally, the silent flag was removed since it was never used in
icecc.bbclass
(From OE-Core rev: 3d0bd786fd79967cf8754d022044df311dd8ad3e)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In some circumstances, gconf isn't able to save configurations
because ~/.config folder aka root_dir doesn't exist.
For example when saving settings using matchbox-appearance,
the following error is shown:
GConf Error: Configuration server couldn't be contacted: D-BUS error:
Can't overwrite existing read-only value: Value for
`/desktop/poky/interface/font_name' set in a read-only source at the
front of your configuration path
This issue was not seen before because ~/.config directory is shared
between several packages and one of those packages usually creates it
by the time gconf wants to use it.
This patch makes sure that gconf creates the .config directory if it
doesn't exist, along with the gconf directory inside it.
[YOCTO #12632]
(From OE-Core rev: 4d16fa05e47ccc8425ebb085c295d7d8dca6b2e6)
Signed-off-by: Alejandro Hernandez <alejandr@xilinx.com>
Signed-off-by: Jaewon Lee <jaewon.lee@xilinx.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
/mmeeks/bootchart.git is redirecting to /xrmx/bootchart.git so update SRC_URI to
match.
(From OE-Core rev: c4208f0ef0753a4615cf9dbcfb305f638b262f50)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The python3 installation in the SDK did not include the minimum set
of modules to be functional, particularly in the case where Python
is brought in through dependencies. Rather than requiring the user
to explicitly add the modules, it's better to pull in the modules
through RRECOMMENDS. Note that the Python 2 recipe already does
this.
(From OE-Core rev: 5a88e59e488248b7ec53b072f934052b96c78a51)
Signed-off-by: Tom Hochstein <tom.hochstein@nxp.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Author: Juro Bystricky <juro.bystricky@intel.com>
Date: Fri Mar 30 10:14:05 2018 -0700
modpost: srcversion sometimes incorrect
"srcversion" field inserted into module modinfo section contains a
sum of the source files which made it. However, this field can
be incorrect. Building the same module can end up having inconsistent
srcversion field eventhough the sources remain the same.
This can be reproduced by building modules in a deeply nested directory,
but other factors contribute as well.
The reason for incorrect srcversion is that some source files can be
simply silently skipped from the checksum calculation due to limited
buffer space for line parsing.
This patch addresses two issues:
1. Allocates a larger line buffer (32k vs 4k).
2. Issues a warning if a line length exceeds the line buffer.
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
(From OE-Core rev: 7d92ed3dcd8c4b5f7cde2f521569c792d55fae65)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
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>
I guess not many people are building linux-yocto-tiny for
v4.15, given that I managed to mangle the name of the recipe
when I introduced it.
[YOCTO #12640]
(From OE-Core rev: 6c1ddbbb0eb9c86646fcb99520e4747cfcd2b418)
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>
4.15+ already has the following dependencies:
DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}"
DEPENDS += "openssl-native util-linux-native"
Updates to 4.14 via the -stable releases have also introduced the same
dependencies to 4.14's "make scripts". As such, we bring the same lines
into 4.14 to restore the ability to build scripts.
(From OE-Core rev: 148fd7a5bfea5d18952355a294e6d36ca82291d2)
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>
xz has native support for threaded compression now and SDK creation was the only
part of oe-core which is using pixz instead of xz.
Not only does this remove pixz-native from the SDK dependencies, but in my
limited testing xz -T0 is slightly faster and produces smaller archives than
pixz for the same input.
(From OE-Core rev: ce1cfa57d9828c0898f52e736f671ce8db534031)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since pigz is no longer a drop-in replacement for gzip (oe-core 1624b7b) the
image creation has been using gzip instead of pigz, despite still depending on
pigz-native. Fix this by invoking pigz explicitly.
(From OE-Core rev: 214fa7fe3b162162d2fa8b31eec28bedd86fcc7d)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [#YOCTO 12030]
Updated the "Task Checksums and Setscene" section to provide a bit
of user information around the bitbake-dumpsigs use that lets a
user examine signatures and inputs that determine if a do_compile
task is indeed supposed to be run.
Added more explanation of how a user can examine signatures used
to determine if a do_compile task is indeed supposed to be run.
(Bitbake rev: 103bbc6642261cd5da038ba2071621919ee01253)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Made sure that the terms "OpenEmbedded-Core" and "OE-Core"
are used as such throughout the manual.
(Bitbake rev: 677e58f8616a4bf58772e54d2313af3885a3b110)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* linux-firmware contains ${PN}-license package since this commit:
commit 1ee083da0730408fffdbbf5f29abc299c0e61be9
Author: Jackie Huang <jackie.huang@windriver.com>
Date: Mon Apr 13 10:17:21 2015 +0800
linux-firmware: fix the mess of licenses
* LICENSE_CREATE_PACKAGE functionality in license.bbclass when enabled
adds new package with suffix:
LICENSE_PACKAGE_SUFFIX ??= "-lic"
but then it checks if ${PN}-${LICENSE_PACKAGE_SUFFIX} is included
in PACKAGES before adding it and when found it shows:
WARNING: linux-firmware-1_0.0+gitAUTOINC+4c0bf113a5-r0 do_package: linux-firmware-lic package already existed in linux-firmware.
and doesn't add the ${PN}-lic to PACKAGES and causes another warning:
WARNING: linux-firmware-1_0.0+gitAUTOINC+4c0bf113a5-r0 do_package: QA Issue: linux-firmware: Files/directories were installed but not shipped in any package:
/usr
/usr/share
/usr/share/licenses
/usr/share/licenses/linux-firmware
that's because it was searching ${PN}-lic in PACKAGES as a string
so it found ${PN}-lic as a substring of ${PN}-license, add a split
to search in an list
(From OE-Core rev: 9b9897fc034819385a9d4ce591cc79dd458f3f24)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* add it to allow older distributions e.g. Ubuntu 14.04 with gcc 4.8
to build this, otherwise it fails with:
../git/gen-des-tables.c: In function 'write_table_u8':
../git/gen-des-tables.c:307:3: error: 'for' loop initial declarations are only allowed in C99 mode
for (size_t i = 0; i < m; i++)
^
(From OE-Core rev: 2591741896a6a267ceca9519f21bd39b5b196559)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add option for dbus in configure.ac, and explicitly build without dbus
for rpm-native.
Previously, the rpm recipe tries to prevent rpm-native from attempting
to inhibit shutdown via session dbus by appending '--disable-plugins'
to EXTRA_OECONF in case of native.
However, some layer may need some functionality via plugin support. And
when it enables it, we would meet the following warning at rootfs time.
Unable to get systemd shutdown inhibition lock: Socket name too long
As plugins/systemd_inhibit.c is the only place that's related to this
dependency, we can be sure that dbus is really not needed for rpm-native.
(From OE-Core rev: 815ccef2d5bef1e46c51916e694d0974aee394a9)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since ${SSTATE_ARCHS} now contains ${PACKAGE_EXTRA_ARCHS} there is no
longer any need to add those extra architectures to the list of
architectures handled in get_deployed_dependencies().
(From OE-Core rev: e55e6df4f1434458cdfa0e2d3610b48119e5a782)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This makes sure files provided by packages that use any of the extra
architectures defined using ${PACKAGE_EXTRA_ARCHS} are cleaned from
tmp/sysroot-components when sstate_eventhandler2() executes.
Without this, changing a package from using one of the extra
architectures to another architecture would lead to files being
leftover in tmp/sysroot-components, which could later be picked up
when creating the RSS for another package rather than the files that
belonged to the updated package.
(From OE-Core rev: b959b3bd92aa2939d407800fc4167b0535fd4674)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Without this change, there will be two sstate index files in
tmp/sstate-control for any machine that contains a dash in the
name.
(From OE-Core rev: 29e7799bdb3773c40492e01448e0c614ed44583d)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fedora28[1] has decided to go ahead and use libxcrypt to replace libcrypt from glibc
despite the change not having merged into glibc upstream yet. This breaks the use of
uninative in OE on fedora28 since binaries there are now using new symbols only found
in libxcrypt. libxcrypt is meant to be backwards compatible with libcrypt but not the
reverse.
Since this will impact OE in the next release cycle, this changes nativesdk only
to use this new model and adds libxcrypt to work in that case. This allows us to
build a uninative which is compatible with fedora28 and previous other OSes.
In order to work, recipes will now need to depend on virtual/crypt where they use
libcrypt since its now a separate library and we can't depend on it from glibc to
preseve backwards compatibility since glibc needs to build first. For now, only the
problematic nativesdk recipes have been fixed up. For target use, the default
provider remains glibc for now. Assuming this change is merged into upstream glibc,
we will need to roll this change out for the target but we will do this in the next
release cycle when we can better deal with the resulting bugs.
[1] https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt
Original patch from Charles-Antoine Couret <charles-antoine.couret@essensium.com>,
tweaked by RP to add virtual provides, SkipRecipe for libxcrypt and other minor
tweaks.
(From OE-Core rev: c1573cb7faeb296fe7077a60d02443d5ed5bded0)
Signed-off-by: Charles-Antoine Couret <charles-antoine.couret@essensium.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that we see warnings if LAYERSERIES_COMPAT is unset, the auto generated
code from devtool needs to set this to avoid warnings which break
various tests.
(From OE-Core rev: f65ebfeda0bfbac78e4a2a6609ba654ca38a8b0e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that we see warnings if LAYERSERIES_COMPAT is unset, the auto generated
code from devtool/oeqa needs to set this to avoid warnings which break
various tests.
(From OE-Core rev: 27568410ebb0d40db3428550704f35199df0e034)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Alejandro asked this be reverted as the patch causes more problems
than it solves.
This reverts commit 5d288d286e.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add Perl's patch submitted to upstream to be compiled along with glibc with libcrypt split.
(From OE-Core rev: 79703d83790a2973fefdb0e12e125b5f17e98cdf)
Signed-off-by: Charles-Antoine Couret <charles-antoine.couret@essensium.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Although the package will get an automatic prefix "kernel-module", so
the package kernel-module-hello does exist, populating rootfs can
generate an error:
- nothing provides kernel-module-hello ...
This is quite unfortunate, as this recipe is used as a sample.
Adding RPROVIDES_${PN} += "kernel-module-hello" to the recipe fixes
the problem.
[YOCTO #12641]
(From OE-Core rev: ca17a7bbea5f5454da43545d544ff7772d83ac19)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
New crosstap python implementation is total replacement for
crosstap shell script, that has superseding capabilities.
New script support cross compiling of SystemTap scripts
for user-land, by using supplied image rootfs. Whereas old
script could only deal with scripts against kernel. New script
has more complex logic and additional capabilities.
As invocation interface new script support old "legacy"
mode and provides alternative new regular options interface
to access additional functionality.
(From OE-Core rev: 1cbbcf26e0a9ca6e0b34a89512bf75dbae8bfaf0)
Signed-off-by: Victor Kamensky <kamensky@cisco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For details on issues fixed please look at commit message of individual
patches.
Upstream-Status: Backport [systemtap@sourceware.org]
(From OE-Core rev: 5aa93de3a79c8691e74e982d3d4b0099b04f5555)
Signed-off-by: Victor Kamensky <kamensky@cisco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For cases when systemap module compilation happens on host in
cross-compilation mode, and it is desirable to minimize systemtap
presense on target we need to have just smallest possible set of
utilties that are required to run compiled modules.
Introduce new "translator" PACKAGECONFIG, if it is not set
it would mean that just minimal set of run-time utilities will
be included in the package.
For run-time only systemtap build variant use
PACKAGECONFIG_pn-systemtap = "" or
PACKAGECONFIG_pn-systemtap = "monitor"
Suggested-by: Taras Kondratiuk <takondra@cisco.com>
(From OE-Core rev: a22b8140c6924eb3b3cd7b5bea66a4d3ed413807)
Signed-off-by: Victor Kamensky <kamensky@cisco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is IMAGE_GEN_DEBUGFS="1" variable that enables build of
additional rootfs-dbg and additional archive that contains
complimentary symbols files for a given image. But the issue
with this resulting directory and tarball that before use it
has to be combined with original image content. It is required
since all cross debugging tools like gdb, perf, and systemtap
need file system that contains both target executables/libraries
and their symbols. Those tools need to find executable/library
first and through it debuglink note find corresponding symbols
file.
image-combined-dbg when added to USER_CLASSES just copies
final resulting rootfs back into rootfs-dbg creating combined
target and debug symbols rootfs that can be used for debugging
directly.
(From OE-Core rev: 7ccb077f51c9232de70e5c6f9897fd9986e3be9d)
Signed-off-by: Victor Kamensky <kamensky@cisco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since v7.51.0, libidn2 is the only available option, libidn
support was dropped.
The configure option was renamed as of v7.53.0
Therefore, curl unconditionally tries to build against libidn2,
which in particular is a problem for curl-native, as that might
or might not build against the build-machine's libidn2 now,
which furthermore causes problems when trying to share sstate
between multiple build machines.
We therefore see the following in the config log:
...
checking whether to build with libidn2... (assumed) yes
...
checking for libidn2 options with pkg-config... no
configure: IDN_LIBS: "-lidn2"
configure: IDN_LDFLAGS: ""
configure: IDN_CPPFLAGS: ""
configure: IDN_DIR: ""
checking if idn2_lookup_ul can be linked... yes
checking idn2.h usability... yes
checking idn2.h presence... yes
checking for idn2.h... yes
...
IDN support: enabled (libidn2)
...
even though this recipe tries to disable that.
While libidn2 isn't available in OE, this change at least:
* prevents curl-native to silently build against libidn2 if
that is installed on build machine, even if not requested
* alerts people who use the PACKAGECONFIG option that it's
not actually doing what they intend to do
(From OE-Core rev: 705eaea991622bdbb2ee83eefa8df8e665e3efe4)
Signed-off-by: André Draszik <andre.draszik@jci.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
aarch64 has been supported since GCC 5.1, sparc has been supported
since 4.9, and S390 since 7.1.
(From OE-Core rev: a2cbb5dc4c6191ca343dc4211abde693dc1a579a)
Signed-off-by: Dan McGregor <dan.mcgregor@usask.ca>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
aarch64 has been supported since GCC 5.1, sparc has been supported
since 4.9, and S390 since 7.1.
Also mark as broken entirely with musl.
(From OE-Core rev: 7d90d2a70f0184ad715e9917d3e7aa096cf98f79)
Signed-off-by: Dan McGregor <dan.mcgregor@usask.ca>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We'd like layers to set this variable so that we know which layers are compatible
with which others, even if the branch is a generic un-updated "master" branch.
Start printing a warning to highlight this issue.
(Bitbake rev: cca81e33b58c390dcf5cc3a31555a43b79177166)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Also set LAYERSERIES_COMPAT for core (we're compatible with ourself).
(From OE-Core rev: 4aa43cd844781a07a2dbf17f21ed35c6a0100d02)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adpat to the upgrade from 5.0 -> 6.0.
(From OE-Core rev: dc52f9cf343df4c2d77bee0e47004466321e7edb)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since gnomebase class already inherits autotools and pkgconfig,
there is no need to repeat it here.
(From OE-Core rev: bae5ced6eba78f1903e15d7f9dd7afc3c06e8955)
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since gnomebase class already inherits autotools,
there is no need to repeat it here.
(From OE-Core rev: 9a514311fa062fa3f8bccc4c47e907f88221024a)
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since gnomebase class already inherits autotools and pkgconfig,
there is no need to repeat it here.
(From OE-Core rev: 301d153781c7ddb6e38178c56f960e18d62788ab)
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since gnomebase class already inherits autotools and pkgconfig,
there is no need to repeat it here.
(From OE-Core rev: 2eb7ba6cb68e171c880bcb1fc614f1ae6b300e4f)
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
PRINC is no longer used and removed from documentation:
commit 7baadd86ee
Author: Scott Rifenbark <scott.m.rifenbark@intel.com>
Date: Mon May 18 09:25:51 2015 -0600
ref-manual: Removed PRINC entry from the glossary
(From OE-Core rev: b15089b014b95a8730f622ca4959b42ed15cb175)
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When archiving a kernel, if S is ${WORKDIR}/git, then
${WORKDIR}/git is in fact a soft link into work-shared,
and the archive contains just the soft link. Fix by
archiving the real directory.
(From OE-Core rev: 564204dd6b73697ef4b6c17243067892876cc323)
Signed-off-by: Tom Hochstein <tom.hochstein@nxp.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Special handling for kernel source in work-shared was
incorrectly limited to kernel-yocto.bbclass instead
of kernel.bbclass.
(From OE-Core rev: b8c5680a67888d43540366a40bd0c501e926ac31)
Signed-off-by: Tom Hochstein <tom.hochstein@nxp.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that we have postinst intercept execution working for SDK generation,
adding MLPREFIX again makes sense in all cases, as the intercepts do require
that it is there.
This reverts commit 4ffb728df4.
(From OE-Core rev: 0792540170b6150a0c5fe8586bb8012affc3f90e)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When it was something else than /usr/libexec (e.g. when
installing native SDK packages), things broke down.
(From OE-Core rev: d99e819a6cbde6d1116c434ddba4c5f8eca7e6d8)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously this wasn't done, and so any packages installed from
populate_sdk would not have the postinsts fully executed
(particularly generation of various caches via running nativesdk or target
binaries with qemu wasn't working).
[YOCTO #12630]
(From OE-Core rev: a484ff072eea3f47de2c3348048201249cefa46b)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
