The checksum value is only calculated if the uninative class is
inherited, so check for inherit before adding it to local.conf
(From OE-Core rev: 3b5b832589d943700b273e3a4d83561be0c47f36)
Signed-off-by: Jeremy Puhlman <jpuhlman@mvista.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The audit package specifies the following:
UPDATERCPN = "auditd"
However because it is not multilibized, the value "auditd" is used to
search for the package to add the post install script too. In the mutlilib
alternate abi case, that package does not exist. It ends up assigning
the post install script to the lib32-audit-lic package, which
subsequently failes to execute the script due to the initscript it is
trying to turn on is not installed.
(From OE-Core rev: ce99653e1af50d9e8f070ca6ae810908c4c138c6)
Signed-off-by: Jeremy Puhlman <jpuhlman@mvista.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There's a bug in Meson[1] where it find_program("foo") will fail if foo is
defined in the cross file as a list.
This is causing the Meson build of libdrm to fail, but for this instance we can
work around the problem by only using lists in the cross file if there are
arguments, and just using a string if there are not.
[1] https://github.com/mesonbuild/meson/issues/3737
(From OE-Core rev: 7fd8bc469c2caacc1c2021bd0aa83dd6da7fe1e7)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When generating the extended SDK, there is a copy step where this class
goes through the layers and other stuff that have been copied to
generate the SDK. The corebase; ie. the folder that contains the core
layer 'meta' is treated in a special way. Unfortunately in our tree, we
have:
sources/meta/meta
| `- core layer
`------- corebase
In populate_sdk_ext's copy_buildsystem, the heuristic to determine which
element of the list returned by copy_bitbake_and_layers is corebase is
fooled by such layout.
In copy_bitbake_and_layers, corebase is already handled specifically and
reliably, so we should let that function tell us which folder is
corebase instead of trying to determine it.
To do so, change the return type of copy_bitbake_and_layers to a tuple
that contains (corebase, copied_layers). It also simplifies the code on
the caller side.
(From OE-Core rev: 5368bc5d0d3606198b93e877bcafcd77bb5f4fd1)
Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When generating overlay DTB configuration sections, U-Boot doesn't want
the kernel specified again as we already have that in our base DTB. Add
support for this to allow bootm to process overlay configuration sections.
(From OE-Core rev: c0db9776beb4f519079a554a733353c368739dcf)
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Introduce UBOOT_DTB_LOADADDRESS and UBOOT_DTBO_LOADADDRESS so that you
can set where U-Boot loads full and overlay DTBs. This is required when
using bootm's overlay support to construct the final DTB.
(From OE-Core rev: 05d2230db1d7379494814407fc0d79d7e755d89e)
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When include conf/distro/include/security_flags.inc, NOPIE flags are
still required for mips64 target builds. Otherwise it fails to build
packages such as glide which inherit go.bbclass:
| .../tmp-glibc/work/mips64-wrs-linux/glide/0.13.1-r0/recipe-sysroot-native/usr/bin/mips64-wrs-linux/../../libexec/mips64-wrs-linux/
| gcc/mips64-wrs-linux/7.3.0/ld: .../tmp-glibc/work/mips64-wrs-linux/glide/0.13.1-r0/go-tmp/go-link-518447869/go.o:
| relocation r_mips_26 against `a local symbol' can not be used when making a shared object; recompile with -fPIC`
Use override 'mipsarch' to set SECURITY_CFLAGS for both mips and mips64.
(From OE-Core rev: 98b24e9268dc444356ce8bd9ddfec6adcce5e02a)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By default, we ought to use console="${console},${baudrate}" as
console bootparam as commonly it is left to be passed with the
bootargs.
(From OE-Core rev: 2ce3534b2011cf5516780c9fd7e00bd107619adc)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a package installs manual files, it should update manual index cache
after its installation. Add package 'man-db' to RDEPENDS which contains
command 'mandb' to update the cache. And do the update in the post
install scripts.
(From OE-Core rev: 078900f2416202b677471b10b69c8defb0f14c8d)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of patching Module::Build, maybe Module::Build::Tiny and all other
similar tools, use the official way to tell them which is the target perl
on target.
(From OE-Core rev: f3925216b06ff7fbe21989210f8eb11e16be6631)
(From OE-Core rev: 306435507c4790ec44f30cd3c7fa7d340b441ec4)
Signed-off-by: Jens Rehsack <sno@netbsd.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch adds the posibility to build using TCLIBC=newlib.
It allows users to build baremetal applications with the use of a
C library.
Newlib is a lightweight C library meant to be used on embedded systems,
it is meant to be easily portable for new platforms and to provide
basic functionality on them, by design, it provides stubs for some of
these core functions declared as weak, so they can be built correctly
and then linked against some other library which provides specifics
about the platform being used if need be, libgloss takes care of these
in some cases, but it can also be extended, this patch also allows the
user to easily add other libraries to it by adding them to
NEWLIB_EXTENDED for this specific reason.
(From OE-Core rev: 9f0570351a7b0877aa50efff5fe9a9ef368cb38f)
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@xilinx.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch adds makes it possible to build elf for powerpc by adding
this combination to the elf headers machine dictionary, this can be
useful when trying to build baremetal applications where the TARGET_OS=elf
(From OE-Core rev: 6f7ef4f6049fa8f2a8e17abfcf53ccbc22394088)
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@xilinx.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With recent kernels (i.e. 4.17+) the configuration phase of the kernel
will check for capabilities/options of the compiler for CVE and other
mitigation support.
For a general kernel, we want to ensure that CC is fully defined when
the config targets are invoked (so the proper compiler will be checked).
For linux-yocto, we also need to specify the compiler/tools dependencies
for the configme task since it executes before configure and hence the
main kernel build DEPENDS will not always be in the sysroot before it
executes. Without those dependencies the kernel will be incorrectly
configured (i.e. bison is missing) or the configuration will fail the
mitigation tests.
[YOCTO #12757]
(From OE-Core rev: ff1bdd75d50f0ebac3d599e461685ace29559a82)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It's useful for the post-relocate scripts to be able to see the SDK
environment, for example to see the values of CC, CXX etc. in order to
dynamically generate toolchain files.
To enable this, source the SDK environment script prior to calling the
relocate scripts.
(From OE-Core rev: adcf69ee3310171580c28e141fec6997b1f06da4)
Signed-off-by: Martin Kelly <mkelly@xevo.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, if a post-relocate script fails, it fails silently. We should
be louder about this, as it likely indicates a broken SDK.
Print a message if a post-relocate script fails.
(From OE-Core rev: 369b5f3f98f8455c79731621cc669ad1948e2022)
Signed-off-by: Martin Kelly <mkelly@xevo.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, we look only for scripts matching *.sh, which means we can't
write post-relocate scripts in other languages.
Expand this to allow any type of script.
(From OE-Core rev: 5569a6ec6d3c4358719350cac88afa69a76097a8)
Signed-off-by: Martin Kelly <mkelly@xevo.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A function is uses a mix of spaces and tabs. The rest of the file
uses tabs, so switch to tabs uniformly.
(From OE-Core rev: 693daaac7399a5a7665cd3bcbc915ff93db36db5)
Signed-off-by: Martin Kelly <mkelly@xevo.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously, when dropbear was started via its init script, relocation
of DROPBEAR_RSAKEY_DIR to support read-only rootfs was handled at
run time from within the init script.
Update the init script to take advantage of the read-only rootfs
config setup by read_only_rootfs_hook() and therefore be consistent
with startup under systemd (where relocation of DROPBEAR_RSAKEY_DIR
is handled by the read_only_rootfs_hook() at build time).
(From OE-Core rev: 4990f87b2f6a8b30c8d1c767636e7f5527f595ba)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
testimage-auto is expected to run testimage task's codes automatically.
But in fact, it's currently missing some codes, including testimage_sanity
and create_rpm_index.
This leads to the problem of unexpected runtime failure of test_dnf_makecache.
The error message is as below.
RESULTS - dnf.DnfRepoTest.test_dnf_makecache - Testcase 1744: ERROR
This error is caused by the fact that create_rpm_index is not executed
before running the tests.
There's no reason why such codes should not be in testimage_main, so
move them into it.
(From OE-Core rev: fa7ba486ded13907f63f9300f66350ba2835a3f7)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Having 'auto' in TEST_SUITES will also run the 'dnf' test cases,
so also check it to determine whether to create rpm index or not.
This is to fix the following error when TEST_SUITES = "auto".
RESULTS - dnf.DnfRepoTest.test_dnf_makecache - Testcase 1744: ERROR
(From OE-Core rev: c1f4177848d25a9121f2a85da655ee414cd424b1)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The current behaviour of TEST_SUITES is very confusing.
setting: TEST_SUITES = ""
result: Execute all test cases.
setting: TEST_SUITES = "some_case_not_exist"
result: Error out with 'Empty test suite' message.
The expected behaviour of TEST_SUITES should be:
1. when 'auto' is in it, execute as many test cases as possible
2. when no valid test case is specified, error out and give user message
The first one is implemented by a previous patch.
The second one is fixed in this patch.
Also add debug message to show test cases to be executed. This is
for easier debugging.
(From OE-Core rev: 909568821fbad8a6a7034b10a2dc349a210fdfc6)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The native override is specified in two different places, so let's move
it into a function to reduce code duplication.
(From OE-Core rev: c455ec4a12d4966524da9436722476aa2d428765)
Signed-off-by: Martin Kelly <mkelly@xevo.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
One of the uses of externalsrc is to enable iterative editing and
rebuilding of source files during development. In such situations,
disabling Automake dependency tracking can lead to sources not being
rebuilt even though files they depend on have been modified.
(From OE-Core rev: af2f802d5b59203a887982af83252565b8078085)
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>
Currently if KERNEL_IMAGETYPES contains both vmlinux and vmlinux.gz,
KERNEL_IMAGETYPE_FOR_MAKE will end up containing two copies of
vmlinux, which will result in two calls to "make vmlinux" from
kernel_do_compile().
Avoid duplicating vmlinux in KERNEL_IMAGETYPE_FOR_MAKE plus some
minor non-functional updates to formatting and comments.
(From OE-Core rev: 80455a0b6cce6d12a5b32194d0cad2e4c7f71599)
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>
Building on a host OS other than a recent version of Linux is not
recommended or supported. Drop the historical _build-${BUILD_OS}
over-ride to avoid giving the impression that other host OS's might
be supported.
(From OE-Core rev: 428fc39356cb77830de9e0d3f1dbd00f5868290a)
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>
There doesn't seem to be a clear reason to have two separate
variables to hold whitelisted GPLv3 recipes. Both variables are
treated the same, so adding a recipe to LGPLv2_WHITELIST_GPL-3.0 is
already equivalent to adding it to WHITELIST_GPL-3.0.
Anyone needing to whitelist a GPLv3 recipe should now just use
WHITELIST_GPL-3.0.
(From OE-Core rev: d4dea76fbe9765d489e3e522a9d2c22049610c7b)
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>
The _virtclass-XXX over-rides are problematic in that they are higher
priority than _forcevariable, which is documented as being the
highest priority over-ride.
Since they are now obsolete (replaced by _class-native and
_class-nativesdk) drop them entirely rather than try to fix their
priority.
(From OE-Core rev: c5aa33ac483618bc23fbaccb0a18853186f9155d)
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>
Some backported patches fix multiple CVEs and list the corresponding
identifiers on multiple lines, rather than on a single line.
cve-check.bbclass yields false positive warnings when CVE IDs are
presented on multiple lines because re.search() returns only
the first match.
An example of this behavior may be found when running do_cve_check() on
the wpa-supplicant recipe while in the rocko branch. Only CVE-2017-13077
is reported to be patched by commit de57fd8, despite the patch including
fixes for a total of 9 CVEs.
This is resolved by iterating over all regular expression matches,
rather than just the first.
(From OE-Core rev: 8fb70ce2df66fc8404395ecbe66a75d0038f22dd)
Signed-off-by: Jon Szymaniak <jon.szymaniak.foss@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add test cases to test “exclude” and “installroot“ options, also modify
the logic of filtering packages on the feed to have all the packages
needed by the tests.
[YOCTO #10744]
(From OE-Core rev: 1121806603c6f621d084b692216f3f616a0768dc)
Signed-off-by: Jose Perez Carranza <jose.perez.carranza@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Each time I build my image after the first, I end up with a
do_image_complete_setscene stamp file with an extra _setscene appended to
the name. Eventually, the filenames end up being so long that mv complains
and the build fails.
It looks like this behaviour was introduced when the special handling was
added for do_image_complete in 2ff9d40dc88d43567472218cf3d3faf414398c71.
So, let's ensure that the *_setscene* pattern is matched before anything
else so that any do_image_complete_setscene stamp file is always ignored
and the do_image_complete non-setscene stamp file is moved only once.
It's not straightforward to just move *do_image_complete* after the
*_setscene* pattern because do_image_complete stamps would then match
do_image*.
(From OE-Core rev: f04e6bd144deb0c8fe2742f66b18904b6619a502)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a recipe sets S to ${WORKDIR}/ then the S != WORKDIR test doesn't work as
expected. Use os.path.normpath() to normalise the paths so string comparison
works.
(From OE-Core rev: 06aaafd14f3c8e27faeea0a514f80e1ff5eb4deb)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Commit a1690131691507bbf5853540229b3ad775b836bf removed the ability of
recipes to set KERNEL_IMAGETYPE_FOR_MAKE. Fix that by letting recipes
continue to set their own KERNEL_IMAGETYPE_FOR_MAKE if they so wish.
They may have been doing so for a while, and don't want to have their
carefully-selected value trampled on by kernel.bbclass.
This may be required if the recipe itself wants to build one type of
kernel, but post-process it into a different type, rather like the
vmlinux->vmlinux.gz support provided by kernel.bbclass.
(From OE-Core rev: 38abd26fe7de321e0f1fc4895f754f34dee90f6c)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
shlibs is largely useless for allarch, the particular usecase where it
fails is when DISTRO_FEATURE is changing due to libc being different e.g.
Variable package_do_shlibs value changed:
-DISTRO_FEATURES{ldconfig} = Set
+DISTRO_FEATURES{ldconfig} = Unset
musl -> glibc or other way around 'ldconfig' gets added or deleted to
DISTRO_FEATURE set, neither this distro feature nor the shlibs processing
during packaging is of interest to allarch packages which are largely
arch independent scripts
(From OE-Core rev: 06602d56d1d311562144eafe459fcea36931a34c)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The SSTATECLEANFUNCS mechanism was introduced to solve user/group
deletion problem. After RSS mechanism was introduced, there's no
need to do so.
There was a patch to remove these obsolete codes for useradd.bbclass,
but the codes in sstate.bbclass were not removed. So clean it up.
(From OE-Core rev: 215b83ce892a7002ed0b1bd7b82a08e67ae15121)
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>
We have some tasks depending on image's do_image_complete task, and we
are also using WKS files to generate partitioned images, but now there
is lacking a inter dependency between do_image_wic and
do_image_complete, so we have to depend on both of them.
Fixed by adding the dependency.
(From OE-Core rev: e3a25f06f2cde701415f4130a43c9b3895d42f10)
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Native.bbclass needs to fixup both base_libdir and libdir to handle things like multiarch. This fixes wic and ext4.* image failures during do_rootfs where mkfs.ext4 can't find its libraries.
(From OE-Core rev: 464dad0dc93aeeedd34d90c2f06596060ec135fd)
Signed-off-by: Koen Kooi <koen.kooi@linaro.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Where /bin/sh is dash, the recent toolchain scripts change fails as the $(pwd)
usage in oe-init-build-env doesn't function correctly. Fix this by saving
and restoring the cwd and calling the script within its own directory.
This fixes meta-ide-support on dash based systems.
(From OE-Core rev: dceca6d34071b4cbef9e28bbf19dc12f5d925525)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The environment setup script generated in the build directory sets the PATH
variable by expanding ${PATH} which would have host paths filtered. Sourcing
this script to run runqemu will not work as it complains host stty (/bin/stty)
cannot be found.
To resolve this, the script no longer expands ${PATH} during generation time,
instead it will now source oe-init-build-env to initialize the build
environment so that all host paths will be preserved. Also be sure to prepend
STAGING_BINDIR_TOOLCHAIN to the PATH variable so that the toolchain from the
build directory can be found.
[YOCTO #12695]
(From OE-Core rev: a64a144096c0637387244b89ed22f4b5352b2522)
Signed-off-by: Chin Huat Ang <chin.huat.ang@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Allow debugsource listing using dwarfsourcefiles to fail for static
libraries when the archive content is not as expected.
(From OE-Core rev: e2235b7567a9aba474cda4cdc20cc9bfffc63711)
Signed-off-by: Ola x Nilsson <olani@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
PACKAGELOCK is there to protect readers of PKGDATA_DIR from writes and files
changing whilst they're being read. With various changes to the codebase,
the lock code has become confused as the files are now written by the sstate
code in do_packagedata, not in do_package directly any longer.
This change cleans up the code so read sites take the shared lock (anything in
do_package), write sites take the full lock (do_packagedata sstate).
The lock from do_package sstate is no longer needed since it doesn't write
outside WORKDIR.
(From OE-Core rev: d46cadbbb42aa71f9436d640891d6ccc8f8e3618)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
"package.bbclass: Include dbgsrc for static libs" introduced a regression
on mingw, fix this by excluding on that TARGETOS.
(From OE-Core rev: 305dda730738a8fb3789047b06fcc45d10212aa3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The debugsource must be added from the package providing the static
lib, because any package using that lib does not have access to the
source code.
Fixes [YOCTO #12558]
(From OE-Core rev: eefa5ba35663fabe1f3f8cf7f1ff126d51240613)
Signed-off-by: Ola x Nilsson <olani@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Its possible some dynamic runtime library in the dependency chain may
come from sstate and link to libraries which need the libc from
uninative. If we don't do this and binaries are run at do_install time
they would fail to find the symbols from the later libc. Examples:
cmake-native do_install:
bin/cmake: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by TOPDIR/tmp/work/x86_64-linux/cmake-native/3.10.3-r0/recipe-sysroot-native/usr/lib/libexpat.so.1)
dbus-native do_install:
tmp/work/x86_64-linux/dbus-native/1.12.2-r0/build/bus/.libs/lt-dbus-daemon: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x32/build/build/tmp/work/x86_64-linux/dbus-native/1.12.2-r0/recipe-sysroot-native/usr/lib/libexpat.so.1)
This issue is resolved when the interpreter is changed at sstate unpack
time but this isn't soon enough to avoid issues at compile/install time.
By specifing which dynamic linker/loader to use at compile time, this
race window is removed entirely.
(From OE-Core rev: 35867ee035030ab76fc9ccdb0eb1c3f80126301c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We have a problem when for example, a glibc 2.27 based system builds some
library like libpopt-native and puts it into sstate then it is reused
on a pre glibc-2.27 system to build something which depends on popt like
rpm-native. This results in an error like:
recipe-sysroot-native/usr/lib/libpopt.so: undefined reference to `glob@GLIBC_2.27'
In the past we've had this problem with new symbols like getrandom and
getentropy, here its with a more complex symbol where there is an old
version and a newer version.
We've looked into various options, basically we cannot link against our
uninative libc/ld.so since we don't have the right headers or compiler
link libraries. The compiler doesn't allow you to switch in a new set
either, even if we did want to ship them. Shipping a complete compiler,
dev headers and libs also isn't an option.
On the other hand if we follow the ld man page, it does say:
"""
The reasons for allowing undefined symbol references in shared libraries
specified at link time are that:
- A shared library specified at link time may not be the same as the one
that is available at load time, so the symbol might actually be
resolvable at load time.
"""
which is exactly this case. By the time the binary runs, it will use
our uninative loader and libc and the symbol will be available.
Therefore we basically have a choice, we get weird intermittent bugs,
we drop uninative entirely, or we pass this option.
If we pass the option, we can drop the other workarounds too.
(From OE-Core rev: 75a62ede393bf6b4972390ef5290d50add19341a)
(From OE-Core rev: d18bf7fa8e80d6cfaf3fdbe1ab06eec84b954432)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We just ran into an issue where tar failed to build on one server setup
but built everywhere else just fine.
It was running makeinfo to regenerate some docs files and makeinfo was too
old for the host it was running on. There was no dependency on makeinfo-native
as it was not meant to be regenerating the docs.
It was being regenerated as a date from a timestamp used in the docs
was different in Asian timezones than in the other timezones our builds
were being tested in.
I added an entry to https://wiki.yoctoproject.org/wiki/TipsAndTricks/
about how this was debugged.
As such, lets default to setting and exporting TZ to 'UTC' as was already
pioneered by the reproducibile builds work. This makes the builds
deterministic.
[YOCTO #12665]
(From OE-Core rev: 2a90ae7a3286724ff9e3615c4dbf56038f703810)
(From OE-Core rev: e31f31f81efe4b60938b724bece2a03c7c74a68d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The isELF function works by running:
result = file <pathname>
if 'ELF' in result
By default 'file' will prepend the result with the path name of the file
that is being checked. This usually works fine, such as:
$ file /home/foo/openembedded-core/meta/classes/package.bbclass
/home/foo/openembedded-core/meta/classes/package.bbclass: Python script, ASCII text executable, with very long lines
However, if the path includes 'ELF', ELF will end up in the result, and then
the check will return positive.
$ file /home/ELF/openembedded-core/meta/classes/package.bbclass
/home/ELF/openembedded-core/meta/classes/package.bbclass: Python script, ASCII text executable, with very long lines
This will then result in the isELF coming back true, and possibly causing the
checks that use isELF, such as the 'is it already stripped' check, to do the
incorrect thing.
Adding the '-b' option to file will result in the path being omitted in the
result:
$ file /home/ELF/openembedded-core/meta/classes/package.bbclass
Python script, ASCII text executable, with very long lines
(From OE-Core rev: 5a324e9b2cf6378f8eaa4e394f9cb36d4e2680ac)
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>
