rust sets LD_LIBRARY_PATH which causes a lot of problems with host
binaries conflicting with SDK libraries. By using sh/bash from the
SDK we avoid those issues.
[YOCTO #14878]
(From OE-Core rev: dabd97e78a599a81c056c0f3291244f5afae44b0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
cargo ends up running target-rust-ccld with LD_LIBRARY_PATH set to libdir but not
base_libdir which breaks the SDK. You see errors like:
/bin/sh: error while loading shared libraries: libncurses.so.5: cannot open shared object file: No such file or directory
On such a system, this would fail:
LD_LIBRARY_PATH="<path>/testimage-sdk/sysroots/x86_64-pokysdk-linux/usr/lib" cargo build
but this would work:
LD_LIBRARY_PATH="<path>/testimage-sdk/sysroots/x86_64-pokysdk-linux/usr/lib:<path>/testimage-sdk/sysroots/x86_64-pokysdk-linux/lib" cargo build
so wrap cargo with both paths in LD_LIBRARY_PATH.
The error depends on the versions of the host system, it reproduced on tumbleweed-ty-3.
(From OE-Core rev: 388e7cac9f90e79ce8c3c1683d8ee0f4df1bc907)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Update the README to match the current status and remove unclear/obsolete
information and fix formatting.
(From OE-Core rev: fa5d16692dda655a54653df7b4bf98410090ec5c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To ensure buildpaths aren't encoded in the debug symbol output, ensure
we pass our prefix remapping compiler options in.
(From OE-Core rev: c7a529743560c37973787e4ab2433cb7485afb86)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Musl targets need a sysroot set to find the musl static libraries. Set this
appropriately in musl builds.
(From OE-Core rev: 1c5ab57ddda393631ce2da97ef5a876a2020d51f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Enable rust target builds as well as nativesdk-rust for the sdk. Merge
the builds of rust-tools components into the rust build, packaged separately
since this is a lot more efficient and saves rebuilding core rust multiple
times. The tools are not target specific so nativesdk-rust-tools suffices
and we can drop the cross canadian piece.
(From OE-Core rev: b9b0cd99cdc77e7a90e5fd5711e706ebe64c7b6b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that target config json is provided by rust-target-config.bbclass,
the need for the cross and crosssdk recipes is removed. Drop them and
simplify dependencies accordingly.
(From OE-Core rev: 4b54f5f52b33db4d2fe95c5faef033b6c6b37b7d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since a copy of rust can target any target and doesn't need to be target
specific, we can simplify rust-cross-canadian to simply contain the json
configuration and envirionment setup scripts.
(From OE-Core rev: 6ec18de9d6f49bccff72f2665821dbd732b69b48)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The cargo-cross-candian variant made no sense as one version of cargo in
the SDK can work for all targets. Replace it with nativesdk-cargo instead.
Move the SDK env to rust-cross-canadian.
(From OE-Core rev: 6d6d135924eff5993736ee58ba8cc5d00ca635f3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For cross compilation, build, host and target may be different. Ensure
the main rust config has the appropriate sections added to match the
configurations.
(From OE-Core rev: e2cdbf9df8d3f90b5a7ba35288c5db4f252d134d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To allow nativesdk variants of the tools to build, enable a nativesdk
variant of rust-llvm.
(From OE-Core rev: b4b24dc53fdb86624da71b854dfe018923a203fe)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Improve the common class to handle BUILD_SYS as well as host and target,
removing the need to a workaround in the rust recipe.
(From OE-Core rev: 0dc9635c28c269f782ad4ed6ea06b4e4de1beb8e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move the "unknown" vendor workaround used during bootstrap to a
central location so it is applied consistently to all RUST_BUILD_SYS
values rather than some subset.
(From OE-Core rev: d02c28b2219d736c9598a13fead7a03eaa3256a6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of generating target configuration files centrally and often getting
it wrong, or having trouble finding the right set, generate them dynamically
from the bbclass into WORKDIR per recipe.
(From OE-Core rev: 9160e4a37561d8ac882057450a818621bec13bed)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This variable is no longer used by the llvm patches.
(From OE-Core rev: 35e1ecf88cf9725e1ba43c948e90359df983002f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need llvm-config for the target but the cross compiled target binary is
no good. We can copy the native one into the target location where it will
then return the target values though.
(From OE-Core rev: f355e55c1fcef57f288279ffb47ebeb52a72b689)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of reusing a "target_section" variable, name them host and build
section instead. This patch sets things up for other improvementsm,
separating out the renaming.
(From OE-Core rev: 279b809e8306b0eb6ae6caeb6b0a3c3c62d2f9d2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The code was using a mixture of XXX_SYS and RUST_XXX_SYS. Use
RUST_XXX_SYS consistently and add the variables to the global exclsion
on signatures as they're reflected in the directory triplets and trying
to filter them out the hashes separately is too painful.
(From OE-Core rev: ee0c0fdf9c1eba9eece6ed1293fda25bf18964b3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a patch which removes the sections of code which encode buildpaths. Whilst
not ideal, the patches at least show where the problematic data is coming from
and should allow more focused work to resovle it by someone who has a better
understanding of rust and what this code is doing. It does look unlikely we
actually need this code in our usecases anyway.
(From OE-Core rev: c08c522fc29445aef0c64f0dd8df8a3531c04afa)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
reproducible.patch
refreshed for new version.
0001-change-shebang-to-python3.patch
removed as not needed since upstream has removed the shebang lines.
License-Update:
src/pip/_vendor/html5lib/LICENSE: removed since it's not it new version
src/pip/_vendor/chardet/LICENSE: file format modified, change St to Street
src/pip/_vendor/pygments/LICENSE: Copyright year updated to 2022
(From OE-Core rev: d69f360bb48001a4ec9220c8f935bb5fe43b4f7a)
Signed-off-by: Wang Mingyu <wangmy@fujitsu.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Changelog:
=========
Error out instead of crashing when marshaling unsupported fundamental types in some cases !180
Add a workaround for a PyPy 3.9+ bug when threads are used !200
Fix crashes when marshaling zero terminated arrays for certain item types !191
Fix a crash/refcounting error in case marshaling a hash table fails !191
Make the test suite pass again with PyPy !191
tests: support running tests with (MSVC) CPython 3.8+ on Windows !206
interface: Fix leak when overriding GInterfaceInfo !204
setup.py: look up pycairo headers without importing the module (helps with building on Windows and MSVC CPython 3.8+) !205
(From OE-Core rev: 14c442bfe4886e6180bd58f5e69928efd54e9c3c)
Signed-off-by: Wang Mingyu <wangmy@fujitsu.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Changelog:
===========
-Fix relative $ref resolution when the base URI is a URN or other scheme (#544).
-pkgutil.resolve_name is now used to retrieve validators provided on the command
line. This function is only available on 3.9+, so 3.7 and 3.8 (which are still
supported) now rely on the pkgutil_resolve_name backport package. Note however
that the CLI itself is due to be deprecated shortly in favor of check-jsonschema.
-best_match no longer traverses into anyOf and oneOf when all of the errors
within them seem equally applicable. This should lead to clearer error messages
in some cases where no branches were matched.
(From OE-Core rev: 203dc71c2b2a712a88f41fc6a5b9894d36d0d3c0)
Signed-off-by: Wang Mingyu <wangmy@fujitsu.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As discussied in [YOCTO #14717] cmake contains a OEToolchainConfig.cmake
file to configure the toolchain correctly in cross-compile build for recipes
using cmake. The CMAKE_ASM_FLAGS are the configuration are meant for assembly,
but the spelling is incorrect and the Flag is ASFLAGS for gcc and other compilers.
So this variable might neever have worked and it is better for
recipes to specify their own.
(From OE-Core rev: 72729ffbab53f95ee9dd1bc22913d9b864495930)
Signed-off-by: Martin Beeger <martin.beeger@online.de>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When using meson-native directly from bitbake this has no effect and
everything works as before; the use case is being able to build
meson-driven projects from the 'direct SDK' environment. Build systems
like cmake/autotools are entirely driven by environment variables,
but meson needs configuration files, and so this replicates how SDKs
set things up.
In particular, with this change the libepoxy build test from the SDK
test suite is able to pass.
(From OE-Core rev: 87d4f6d176f27c22dbb99abc271b9a6eaca314f8)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Remove further code duplication by allowing the main function to be
configurable.
(From OE-Core rev: 2d4b35a0db1220e7a7f1b6776223aa4d40a3f246)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
