Hi Martin, On Sun, 1 Oct 2023 at 12:11, Martin Jansa <[email protected]> wrote: > > well, target bindir isn't in default PATH so it wont get executed by default
Is it a reason to allow mixing executable arch/tune? How do you handle it when you want to install protoc/grpc-cpp-plugin for the target too? > > I have used this work around in some meta-ros recipes where the .cmake file was checking the binary existence even when this .cmake was used only to get right list of libraries to link with (and the binary was not called at all - which imho can happen with protobuf as well) As you say it's a workaround, and it's an issue with the CMake recipe. If we can properly fix it at the recipe level, then why should we keep this workaround/hack? Also if you really need it, you can have a .bbappend for protoc/grpc in the downstream layer. But I would be in favor to avoid this by default no? Clement > > On Sun, 1 Oct 2023, 05:03 Khem Raj, <[email protected]> wrote: >> >> >> >> On Sat, Sep 30, 2023 at 5:48 PM Vyacheslav Yurkov <[email protected]> wrote: >>> >>> I agree, protoc should _not_ be in sysroot, because target binary can't >>> run on host system. >> >> >> Yeah this seems correct approach to me >>> >>> >>> Vyacheslav >>> >>> On 30.09.2023 19:30, Clément Péron wrote: >>> > This reverts commit a0557fe5433620717eeb00d3b16801711337b1a4. >>> > >>> > As said by Ross[Ø]: >>> > "Putting the _target_ protoc into the sysroot for executation at _build_ >>> > time isn't useful because even if it has the right architecture, the >>> > tune might be incompatible. Recipes which want protoc should just depend >>> > on protobuf-native." >>> > >>> > This has been reverted recently by Samuli[1]: >>> > "If protoc is enabled for the build, recipes using protobuf will >>> > fail when protoc is not available in the recipe sysroot" >>> > >>> > Be the revert is incorret as This is an issue coming from qtgrpc >>> > other recipes that use protobuf or gRPC compiler, proplery looks for >>> > the binary in the correct sysroot folder. >>> > >>> > Qtgrpc recipe should fix this issue at the recipe level, for example this >>> > is what I've done for "etcd-cpp-apiv3" recipe[2] that doesn't need this >>> > patch to properly compile. >>> > >>> > So keeping this hack doesn't seems to be a correct fix. >>> > >>> > Note that qtgrpc recipe isn't available on meta-oe nor any other public >>> > layers. >>> > >>> > 0: https://patchwork.yoctoproject.org/project/oe/patch/[email protected]/ >>> > 1: https://patchwork.yoctoproject.org/project/oe/patch/[email protected]/ >>> > 2: https://github.com/etcd-cpp-apiv3/etcd-cpp-apiv3/commit/47f0d9e0326f3cc31c801a0ecf7312d1049ece3e >>> > >>> > CC: Samuli Piippo <[email protected]> >>> > CC: Ross Burton <[email protected]> >>> > Signed-off-by: Clément Péron <[email protected]> >>> > --- >>> > meta-oe/recipes-devtools/protobuf/protobuf_4.23.4.bb | 3 --- >>> > 1 file changed, 3 deletions(-) >>> > >>> > diff --git a/meta-oe/recipes-devtools/protobuf/protobuf_4.23.4.bb b/meta-oe/recipes-devtools/protobuf/protobuf_4.23.4.bb >>> > index 06d73d648..1edc21cdf 100644 >>> > --- a/meta-oe/recipes-devtools/protobuf/protobuf_4.23.4.bb >>> > +++ b/meta-oe/recipes-devtools/protobuf/protobuf_4.23.4.bb >>> > @@ -101,9 +101,6 @@ PACKAGE_BEFORE_PN = "${PN}-compiler ${PN}-lite" >>> > FILES:${PN}-compiler = "${bindir} ${libdir}/libprotoc${SOLIBS}" >>> > FILES:${PN}-lite = "${libdir}/libprotobuf-lite${SOLIBS}" >>> > >>> > -# CMake requires binaries to exist in sysroot, even if they have wrong architecture. >>> > -SYSROOT_DIRS += "${bindir}" >>> > - >>> > RDEPENDS:${PN}-compiler = "${PN}" >>> > RDEPENDS:${PN}-dev += "${PN}-compiler" >>> > RDEPENDS:${PN}-ptest = "bash ${@bb.utils.contains('PACKAGECONFIG', 'python', 'python3-protobuf', '', d)}" >>> > >>> > >>> > >>> >>> >>> >>> >> >> >>
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#105295): https://lists.openembedded.org/g/openembedded-devel/message/105295 Mute This Topic: https://lists.openembedded.org/mt/101679410/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
