Following simple test recipe will fail now when trying to use Protobuf with
CMake.
inherit cmake
DEPENDS += "protobuf"
do_configure:prepend() {
echo "find_package(Protobuf CONFIG)" > ${S}/CMakeLists.txt
}
BBCLASSEXTEND = "nativesdk"
---
CMake Error at
tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-test/1.0/recipe-sysroot/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/usr/lib/cmake/protobuf/protobuf-targets.cmake:107
(message):
The imported target "protobuf::protoc" references the file
"tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-test/1.0/recipe-sysroot/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/usr/bin/protoc-23.4.0"
but this file does not exist.
---
I don't quite see why every project/recipe should fix this independently
when the simple workaround for this yocto-specific issue is available
(namely the use of SYSROOT_DIRS).
-samuli
ps. qtgrpc recipe and other Qt6 recipes are now visible in the layerindex
https://layers.openembedded.org/layerindex/recipe/348210/
On Thu, 12 Oct 2023 at 15:06, Vyacheslav Yurkov <[email protected]> wrote:
> I'd like to follow-up on this and say that I see this issue now with
> nativesdk build, in particular nativesdk-grpc recipe fails in master with
> the same error. I hope that's partially related to the issue everybody is
> confused about, but I'd like understand how to properly fix it.
>
> | The imported target "protobuf::protoc" references the file
> |
> |
> "/home/uvv/projects/poky/build/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-grpc/1.56.2/recipe-sysroot/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/usr/bin/protoc-23.4.0"
> |
> | but this file does not exist. Possible reasons include:
> |
> | * The file was deleted, renamed, or moved to another location.
>
> The protoc-23.4.0 file already exists in the recipe-sysroot-native.
>
> And we do want protoc to be present in the SDK, but nativesdk build is a
> cross-compilation, because SDKMACHINE and HOST might be different.
> In this particular grpc case there's an option to say where the actual
> protoc executable is (
> -D_gRPC_PROTOBUF_PROTOC_EXECUTABLE=/home/uvv/projects/poky/build/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-grpc/1.56.2/recipe-sysroot-native/usr/bin/protoc
> is passed to grpc).
>
> So there shouldn't be any issues here, but nativesdk build still fails.
>
> Looking into it further I see that protoc is actually packaged by
> protobuf-compiler package, but when I try to add a package dependency to
> grpc recipe I get this:
>
> nativesdk-protobuf RPROVIDES nativesdk-protobuf-compiler
>
> Moreover, if I go into devshell and forcefully install
> nativesdk-libprotobuf-compiler, then `bitbake nativesdk-grpc` is happy and
> compiles!
>
> So something wrong with the dependencies in protobuf recipe, but I can't
> figure out yet what exactly. Any ideas?
>
> Regards,
> Slava
>
> On 02.10.2023 18:25, Vyacheslav Yurkov via lists.openembedded.org wrote:
>
> On 01.10.2023 20:22, Martin Jansa wrote:
>
>
> Issue with .cmake file from protobuf, right?
>
>
> No, it's the issue with the cmake of the project that uses protobuf. But
> that depends on a user case, perhaps I didn't get it properly.
>
>
>
>> 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?
>>
>
> I haven't seen any proper fix for this exact issue. Yes you can patch
> .cmake generation not to include bindir when building for target (while it
> needs it for native build), but then that change will break possible use of
> protobuf on target, so the SYSROOT_DIRS still seems like lesser evil here.
>
> Here are some examples from meta-ros:
>
> https://github.com/ros/meta-ros/commit/875ceed4b1c693c2eb0f2b7ea85385be576a62cc
>
> https://github.com/ros/meta-ros/commit/67c03755543655ad0634e078bc30d8ab9969a16c
>
> https://github.com/ros/meta-ros/commit/5e61eb0520d2841c0da7e14eecc833b3c4104533
>
> https://github.com/ros/meta-ros/commit/a53bb7cc8b45a72b704e75311d68b37a6db50cdf
>
> I don't care about protobuf, but the explanation from Samuli looks like
> the same issue as what I remember from above and I don't see how
> SYSROOT_DIRS causes mixing executables or any issues for installing them
> for target.
>
>
> I didn't look at the original issue of Samuli, but your issue is also
> fixed by a workaround. IMHO, the proper fix would be not to make CMake
> "happy" by providing a binary it can't use, but a proper export of
> cross-compiled tools for
> https://github.com/geographiclib/geographiclib/blob/main/CMakeLists.txt
> library. I'd say the workflow should be similar to protobuf/grpc recipes,
> i.e. a native recipe builds the libraries only, and the target recipe
> builds tools and libraries.
>
> Regards,
> Slava
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#105575):
https://lists.openembedded.org/g/openembedded-devel/message/105575
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]]
-=-=-=-=-=-=-=-=-=-=-=-
