The unfs3 license matches the SPDX template for BSD-3-Clause.
There is no reason why this should be referenced as unfs3,
which is not a registered SPDX identifier.
License-Update: use SPDX identifier
(From OE-Core rev: e608747d6fba47d2bfc8637adb39ff3593559fca)
Signed-off-by: Bastian Germann <bage@debian.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The EDL-1.0 license matches the SPDX template for BSD-3-Clause.
There is no reason why this should be referenced as EDL-1.0, which is
not a registered SPDX identifier for exactly this reason.
License-Update: use SPDX identifier
(From OE-Core rev: 9745740bbab58365f86ef579e1ad1e86b90594a6)
Signed-off-by: Bastian Germann <bage@debian.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The XSL license was standardized by SPDX as DocBook-XML.
Copy the license file to the new name and use it in
docbook-xsl-stylesheets.
License-Update: use new DocBook-XML SPDX ID, copy text from existing XSL
(From OE-Core rev: e172e27e19fc09160cfee2a29af8e8c5c2426c9c)
Signed-off-by: Bastian Germann <bage@debian.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Recipes are much more readable with whitespace around the assignment operators.
Fix various assignments in OE-Core to show this is definitely the preferred
formatting.
(From OE-Core rev: 30ea609d3357fb3de911f2f6a5e6856c151b976a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
YOCTO [#15061]
The rust target and linker are getting setting from the sdk environment and
so the config file is not needed. The redundant config file geneartion is removed.
(From OE-Core rev: d5f78816d2ad0f3e43ce883eef199d1683cfcbb4)
Signed-off-by: Harish Sadineni <Harish.Sadineni@windriver.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
YOCTO [#15061]
The rust sdk installs both 'rust.sh' and 'cargo.sh' for lib32 and lib64 in the same location.
This causes below error while installing the lib32 & lib64 binaries:
Error: Transaction test error:
file /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/environment-setup.d/cargo.sh
conflicts between attempted installs of rust-cross-canadian-arm-1.67.1-r0.x86_64_nativesdk and
rust-cross-canadian-aarch64-1.67.1-r0.x86_64_nativesdk
file /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/environment-setup.d/rust.sh
conflicts between attempted installs of rust-cross-canadian-arm-1.67.1-r0.x86_64_nativesdk and
rust-cross-canadian-aarch64-1.67.1-r0.x86_64_nativesdk
ERROR: Task (virtual:multilib:lib32:/media/build/poky/meta/recipes-sato/images/core-image-sato.bb:do_populate_sdk)
failed with exit code '1'
The change includes:
- Prepending '${RUST_TARGET_SYS}' to 'rust.sh' to differentiate between target systems.
- Moving the non-target-specific environment variables to 'nativesdk-cargo' and 'nativesdk-rust',
instead of being managed by the cross-canadian recipe.
(From OE-Core rev: 40eb4bfe2f100ba5301046ca25110fcc55a640bb)
Signed-off-by: Harish Sadineni <Harish.Sadineni@windriver.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The string package in python currently contains common string
operations. This package is still in full use.
However, the old summary line of the package marked it as deprecated. As
this is not the case, this commit updates the summary line to better
represent this Python package.
The new summary line was taken from Python's documentation for the
package (https://docs.python.org/3.13/library/string.html).
In the past, the string library used to contain functionality that later
was moved to the str object in Python. The assumption is that during
this change, this library was marked as deprecated here. However, as
this package contains more functionality, which is still relevant and
used by python, the package itself should not be marked as deprecated.
This commit changes the description of the package, but does not change
the name of the package. The proper name for this package should be
"string" (instead of "stringold"). However, changing the package's name
will break compatibility with anyone using the string package in their
project. As this is a big change, it is decided not to be done yet.
The change in description, as well as this commit message, should be
enough to let users understand that the string package in python is
still valid, and should not be treated as deprecated.
(From OE-Core rev: 7602a9013d6c61959ec293ee29285c90257b5fbb)
Signed-off-by: Omri Sarig <omri.sarig13@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Summary of changes:
- New custom dependency for atomic
- --cap-lints allow used for Cargo subprojects
- Cargo features are resolved globally
- Meson can run "clippy" on Rust projects
- Devenv support in external project module
- Fixed sizeof and find_library methods for Fortran compilers
- format command now accept stdin argument
- "machine" entry in target introspection data
- Add new language Linear Asm
- Control the number of child processes with an environment variable
- Support for Rust 2024
- Support TASKING VX-Toolset
- Test targets no longer built by default
- Install vcs_tag() output
(From OE-Core rev: 37d4a5b2653b94d5030b5026b1ecf979420cfb20)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When using the -fsanitize=address CXX_FLAG for a program compiled for
aarch64 / arm64
This is happing:
MemorySanitizer: CHECK failed: sanitizer_allocator_primary64.h:133 "((kSpaceBeg))
== ((address_range.Init(TotalSpaceSize, PrimaryAllocatorName, kSpaceBeg)))"
(0xe00000000000, 0xfffffffffffffff4) (tid=51745)
With -DSANITIZER_CAN_USE_ALLOCATOR64=0 this is not happening and
potenial bugs are detected.
ARM32 does not require this patch.
More info about the issue in this thread:
https://github.com/llvm/llvm-project/issues/65144
(From OE-Core rev: 12442b9b6df06317174066854935b1d6a4f1865d)
Signed-off-by: Thomas Roos <throos@amazon.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Ross Burton <ross.burton@arm.com>
zipfs is a new facility in tcl 9.x where various data files are bundled
into a zip archive, rather being separately installed.
Then that zip is embedded into libtcl.so from Makefile, thusly:
cat ${TCL_ZIP_FILE} >> ${LIB_FILE}
This is a major case of face meeting palm: any binary object
processing on the resulting .so file discards the extra data
at the end, and that's exactly what happens in do_package(),
resulting in a tcl installation without any language libraries.
This is not caught by ptest because it runs against a private
copy of the source tree.
Additionally, it helps to have data files on target systems
as files that can be viewed and edited.
(From OE-Core rev: 05e31be56498123b177f363c700c96b20958585c)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Ross Burton <ross.burton@arm.com>
We have a patch to allow us to 'poison' system include directories,
which are warnings by default but we make them fatal in cross builds.
However, in the 13.1 upgrade[1] the patch to make the warnings fatal was
dropped in the compiler invocation, so it only took effect for pure
preprocessor calls. This was not noticed at the time as the test case
was flawed, but this has now been fixed.
Add back the fatal poisoning, and restructure the patch slightly so it
is less invasive.
[1] oe-core bea46612fd9106cc5b46eb1d81623b6492563c13
[RP: Tweak to fix gcc/gcc-cross-canadian failure]
(From OE-Core rev: 56f21a02c009cb74072ee79467a5bcab3c4643a5)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With gcc posioning fixed, this recipe showed errors, using an incorrect include
path looking at the host system. If pkgconfig is present, the correct include
paths are used. Therefore add the missing dependency.
(From OE-Core rev: 6cf0aaa3af276694709369b6007f629862e21559)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, providers are set on a global config basis. This change allows
for a select set of providers to be configured using BB_RECIPE_VIRTUAL_PROVIDERS
on a per recipe basis. This would allow for the selection of virtual/cross-cc
as gcc or clang for example.
The PROVIDERS are removed from the recipes so that if a version of the
dependency accidentally slips through, the build will fail and the user
can correct the issue.
(From OE-Core rev: 6eeab1a5d7f23917b94c130e417d59afb757b546)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The idea of the base class dependency is to say "yes, I need a C cross compiler"
and this was never meant to be gcc specific. Looking at the codebase, whilst we
code triplets into this, it does overcomplicate things as there are only ever
limited, "target", "sdk" and the class extended versions like mutlilib.
After much thought, we can simplify this to virtual/cross-cc and virtual/nativesdk-cross-cc.
This lets us remove the "gcc" specific element as well as removing the over
complicated triplet usage.
At the same time, change the much less widely used "g++" variant to "c++" for
similar reasons and remove the triplet from virtual/XXX-binutils too.
Backwards compatibility mappings could be left but are just going to confuse
things in future so we'll just require users to update.
This simplification, whilst disruptive for any toolchain focused layers, will
make improved toolchain selection in the future much easier.
Since we no longer have overlapping variables, some code for that can just
be removed. The class extension code does need to start remapping some variables
but not the crosssdk target recipe names.
This patch is in two pieces, this one handles the renaming with the functional
changes separate in a second for easier review even if this breaks bisection.
(From OE-Core rev: 4ccc3bc8266c327bcc18c9a3faf7536210dfb9f0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
fmt-native is needed to build ccache-native, and the compile fails on
hosts with GCC 9.4 (such as Ubuntu 20.04). Backport a patch to fix this
issue.
(From OE-Core rev: 7dbb984f86d04e79d2311411cd8b775e2674b5f3)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This variable no longer exists, and would have had the effect of not
letting the target libtool see the contents of the native aclocal
directory.
I don't understand why this was needed but autotools has improved
dramatically in the last eight years, so it's most likely obsolete now.
(From OE-Core rev: 8ae468b6726392c681a3a35ff37c4401ec45b9d2)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #15625]
The first attempt to get around the timeout was to double it from 5000
to 10000, which doesn't seem to be enough. Let's try to fix this by
extending the timeout by a factor of 10.
(From OE-Core rev: fb19e038582a2bfc414465ef396c30197f67128f)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Modified logic in gcc/incpath.cc to ensure that non-existing host system paths are
not deleted during cross-compilation. If the build system attempts to search a host
path, gcc will now issue a warning instead of silently ignoring it.
Fixes [YOCTO #15672]
https://bugzilla.yoctoproject.org/show_bug.cgi?id=15672
(From OE-Core rev: 32e2f9a73a653a00e555e50f9197b605f2f70f89)
Signed-off-by: Sunil Dora <sunilkumar.dora@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
During the Rust build process, multiple copies of libstd-*.so are generated, as Rust copies the
required files from the stage2 build artifacts to the target image directory. When these build
binaries are copied to the image, Yocto's do_package step encounters an error. To resolve this,
the redundant libstd-*.so files are removed during the do_install step.
-----------------------------------------------------------------------------------------------
ERROR: rust-1.81.0-r0 do_package: rust: Multiple shlib providers for libstd-20c3de2d9292cd03.so:..
....
-----------------------------------------------------------------------------------------------
Multiple copies of libstd-*.so are generated during the Rust build process.
The redundant files are removed during the do_install step.
(From OE-Core rev: effd4ba4c23cbf53b01116b5cc81d6a29ca3b1a6)
Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The per-tune qemu options variable is QEMU_EXTRAOPTIONS_${TUNE_PKGARCH},
but this doesn't follow the pattern of all of the other tune-specific
variables in the machine configuration which is VARIABLE:tune-[name].
Rename QEMU_EXTRAOPTIONS_${TUNE_PKGARCH} to
QEMU_EXTRAOPTIONS:tune-${TUNE_PKGARCH} for consistency.
Note that this will mean that BSPs need to update any assignments of
this variable.
(From OE-Core rev: 7f981d074442b901f7e64dbdb9db851ff31c3733)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using the package architecture to select the right qemu options to pass
to qemu-user is incorrect, and fails for recipes that set PACKAGE_ARCH
to MACHINE_ARCH (as the qemuppc workarounds suggest) because there are
not typically any options set for the machine name.
Solve this by using TUNE_PKGARCH instead: for the majority of recipes
this is the same value, but for machine-specific recipes it remains the
same instead of changing to the machine name.
This means we can remove the qemuppc workarounds, as they're obsolete.
Also update the gcc-testsuite recipe which uses the same pattern to use
TUNE_PKGARCH, and generalise the else codepath to avoid needing to
update the list of architectures.
[ YOCTO #15647 ]
(From OE-Core rev: 414b754a6cbb9cc354b1180efd5c3329568a2537)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
