I'm a bit confused here.

I just did 'find tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-grpc/1.56.2/ -name "protoc*"' and I see protoc binary only in recipe-sysroot-native. That tells me that protoc, which is a part of nativesdk-protobuf-compiler, is not installed to recipe-sysroot.

What am I missing here?

Slava

On 20.10.2023 09:35, Martin Jansa wrote:
do_prepare_recipe_sysroot doesn't install any packages to RSS. Only package manager on target or in do_rootfs uses packages.

It installs the files from dependency populate_sysroot task.

On Fri, Oct 20, 2023 at 9:11 AM Samuli Piippo <samuli.pii...@gmail.com> wrote:

    Dependency to the recipe name will always install all packages to RSS.
    You can verify this by checking that the libprotoc.so from the
    nativesdk-protobuf-compile package is in the sysroot.
    The problem you are facing is the fact that binaries are not
    installed into the sysroot (for nativesdk builds), so you are only
    missing the bin/protoc-23.4.0 file.
    The proposed and twice reverted fix for this is the aforementioned
    SYSROOT_DIRS.

    -samuli

    On Fri, 20 Oct 2023 at 09:17, Vyacheslav Yurkov
    <uvv.m...@gmail.com> wrote:

        I think the problem goes down to how dependencies are
        populated in the sysroot. I raised this question in oe-core
        mailing list
        https://lists.openembedded.org/g/openembedded-core/message/189324
        , but didn't get an answer yet.

        DEPENDS += "protobuf" will only install the main package of
        protobuf to the sysroot, because it assumes that
        nativesdk-protobuf-compiler is also part of the main package
        (which is not). I guess the part of the system populating
        sysroot deals with recipes only, and not with packages. I'm
        still trying to understand how that should be addressed properly.
        My understanding is that either all packages should be
        installed to sysroot (which recipe claims it provides), or we
        need a way to indicate a package level dependency (i.e.
        nativesdk-protobuf-compiler in this case)

        Any ideas?

        Slava

        On 18.10.2023 14:28, Samuli Piippo wrote:
        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
        <uvv.m...@gmail.com> 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


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#105628): 
https://lists.openembedded.org/g/openembedded-devel/message/105628
Mute This Topic: https://lists.openembedded.org/mt/101679410/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to