port should have gone to the openembedded-devel mailing list as
> > > libcamera is in meta-oe. But I guess Khem will have a look anyway.
> > >
> > >
> > > On 20/03/2024 09:10:05-0700, Joel Winarske wrote:
> > > > In master there is a problem running the
https://bugzilla.yoctoproject.org/show_bug.cgi?id=15449
On Wed, Mar 20, 2024 at 9:10 AM Joel Winarske
wrote:
> In master there is a problem running the libcamera "cam" app on a RISC-V
> device:
>
> *** stack smashing detected ***: terminated
>
> If I remove the pat
In master there is a problem running the libcamera "cam" app on a RISC-V
device:
*** stack smashing detected ***: terminated
If I remove the patches in the libcamera recipe, it builds and runs on
target without issue.
libcamera bug has the details:
https://bugs.libcamera.org/show_bug.cgi?id=214
This resolved the issue - native compilation pass. Found a clue in
python3-setuptools-rust-native_1.1.2.bb.
cargo_do_compile:class-native() {
cd ${S}/${CARGO_SRC_DIR}
export CARGO_BUILD_TARGET="${HOST_SYS}"
export CARGO_TARGET_DIR=${S}
export RUSTFLAGS
"${CARGO}" build run
I'm putting together a recipe that requires two passes, native, then
target. I'm hitting a python error only in the native pass. I can cross
compile the tool without error, so the problem is isolated to native. Any
ideas?
Recipe is progress:
Actually the recipe pkgconfig_git.bb points to the freedesktop pkg-config
repo, which is used by default.
On Wed, Dec 1, 2021 at 3:27 PM Joel Winarske via lists.openembedded.org
wrote:
> Forgot the reply all, not intentional :)
>
> Looks like the build is using the pkgconfig flavo
you have just shown.
>
> I'm not sure how pkgconf is able to decide that includedir is a path
> (short of hardcoding that inside the source somewhere), but such logic
> needs to be carefully investigated before we make use of it, e.g. by
> switching to pkgconf in oe-core.
>
> Al
-cross.txt:pkgconfig =
'/usr/bin/x86_64-w64-mingw32-pkg-config'
I think adding a wrapper makes sense.
5.2 Tool Calling Conventions -
https://autotools.io/pkgconfig/cross-compiling.html
On Tue, Nov 30, 2021 at 12:13 PM Alexander Kanavin
wrote:
> On Tue, 30 Nov 2021 at 21:00, Joel Winarske
>
Also all of the above requires this change:
https://github.com/KhronosGroup/Vulkan-Loader/pull/756
On Tue, Nov 30, 2021 at 12:00 PM Joel Winarske
wrote:
> Yes, if the sys_root key value in meson.cross is present
> PKG_CONFIG_SYSROOT_DIR gets set. Honister patch I confirmed with:
>
if sysroot:
> env['PKG_CONFIG_SYSROOT_DIR'] = sysroo
>
> So we probably need to ensure this 'sys_root' is correctly set, and then
> things will simply work?
>
> Alex
>
> On Tue, 30 Nov 2021 at 20:15, Joel Winarske
> wrote:
>
>> https://github.
https://github.com/vkmark/vkmark/blob/master/src/meson.build#L9
On Tue, Nov 30, 2021 at 10:53 AM Alexander Kanavin
wrote:
> I do not quite understand the use case. What is being done with the full
> path to the header?
>
> Alex
>
> On Tue, 30 Nov 2021 at 19:26, Joel
thread) would fix the behavior. I
believe the proper fix is for meson to address upstream. Still waiting on
a response from them: https://github.com/mesonbuild/meson/issues/9674
Joel
On Tue, Nov 30, 2021 at 9:49 AM Alexander Kanavin
wrote:
> On Tue, 30 Nov 2021 at 18:20, Joel Winarske
>
Meson does not expose PKG_CONFIG_SYSROOT_DIR to the pkg-config process.
Currently meson.cross as generated in meson.bbclass points directly to the
pkg-config executable (no wrapper script).
PKG_CONFIG_SYSROOT_DIR behaves like a simple string prepend to all package
config variable queries. So if
is now fixed.
Joel
On Mon, Nov 29, 2021 at 10:58 PM Alexander Kanavin
wrote:
> Can you show what vulkan.pc contains please, and why is that a problem?
>
> Alex
>
> On Tue, 30 Nov 2021 at 00:51, Joel Winarske
> wrote:
>
>> I discovered an upstream problem with vulkan-load
On Mon, Nov 29, 2021, 10:58 PM Alexander Kanavin
wrote:
> Can you show what vulkan.pc contains please, and why is that a problem?
>
> Alex
>
> On Tue, 30 Nov 2021 at 00:51, Joel Winarske
> wrote:
>
>> I discovered an upstream problem with vulkan-loader today.
>
I discovered an upstream problem with vulkan-loader today.
Effectively since 1.2.162 vulkan.pc is broken for cross compilation
scenarios.
This example illustrates current problem with vulkan.pc installed by
vulkan-loader:
$ pkg-config --print-errors --define-variable=prefix=/opt
Enables building the Vulkan 1.1 compliant v3d driver.
Signed-off-by: Joel Winarske
---
meta/recipes-graphics/mesa/mesa.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-graphics/mesa/mesa.inc
b/meta/recipes-graphics/mesa/mesa.inc
index cc71114992..b687f8e4ab 100644
This addresses cases where the platform doesn't depend on Mesa. The NVIDIA
Tegra is one example.
>From 427d6248379bf37f5522d4bb1013b8c0b7a26b5b Mon Sep 17 00:00:00 2001
From: Joel Winarske
Date: Fri, 28 May 2021 12:10:46 -0700
Subject: [PATCH] VirGL depends on gbm.h
Signed-off-by: J
18 matches
Mail list logo
