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 (#105450):
https://lists.openembedded.org/g/openembedded-devel/message/105450
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]]
-=-=-=-=-=-=-=-=-=-=-=-
