This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

populate_sdk in arago fido fails because of libgcov dependency

Hi I deployed the arago toolchain coording to the wiki entry.

I created a distro conf for my platform, which builds fine. I replaced u-boot and kernel sources. The system builds and is bootable.

When I try the populate_sdk command in bitbake, it fails in the last task (do_populate_sdk) with this message:

Collected errors:
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for packagegroup-core-standalone-sdk-target:
 * 	libgcov-dev * 
 * opkg_install_cmd: Cannot install package packagegroup-core-standalone-sdk-target.

During the build I see "external-linaro-toolchain" is built and the corresponding .bb file lists libgcov-dev under PROVIDES.

Is there something I am missing?

  • Over night I tried the same with the stock distro according to the arago wiki:
    arago-project.org/.../Setting_Up_Build_Environment

    In the last step I did
    $ MACHINE=am335x-evm bitbake -c populate_sdk core-image-minimal

    Did anyone succeed deploying an SDK with arago?
  • Have you tried to bitbake the libgcov-dev separately?

    MACHINE=am335x-evm bitbake libgcov-dev
    MACHINE=am335x-evm bitbake -c populate_sdk core-image-minimal
  • Yes, actually the outcome is the same.

    in the first step I get this additional Warning:
    WARNING: QA Issue: non -staticdev package contains static .a library: libgcc-dev path '/work/cortexa8hf-vfp-neon-linux-gnueabi/external-linaro-toolchain/4.9-2015.05-r0-arago28/packages-split/libgcc-dev/usr/lib/libgcc.a' [staticdev]

    But the SDK build fails in the same way.
  • I foind something else quite suspicious.
    when I just bitbake libgcov dev. In the sysroot-providers directory for my target there is a "libgcov-dev" file with the contents "external-linaro-toolchain"
    in the sysroot-providers directory for my sdk (x86_64-linux), there is no such file. isn't this needed for the target sysroot?
  • for now I found some kind of workaraound: I overlayed packagegroup-core-standalone-sdk-target.bb with a new version in my layer.
    I removed the dependency to libgcov-dev like this:

    #start here
    SUMMARY = "Target packages for the standalone SDK"
    PR = "r8"
    LICENSE = "MIT"

    inherit packagegroup

    RDEPENDS_${PN} = "\
    libgcc \
    libgcc-dev \
    libstdc++ \
    libstdc++-dev \
    ${LIBC_DEPENDENCIES} \
    qemuwrapper-cross \
    "
    #ends here

    now at least the populate_sdk command runs through. lets see what is created.

    May be somebody could point me to a guide on how to create an own SDK with arago. I tried the same with yocto/poky, there the problem was to correctly implement the linaro toolchain. Also there were dependency errors when building the SDK.
  • I found this patch which adds this libgcov-dev to fix a link error.
    patchwork.openembedded.org/.../

    There is an another patch, which removes the libgcov-dev to provide only one dev and dbg package.
    patchwork.openembedded.org/.../

    So, please contact their mailing list to get their final decision.

  • finally I had to add an addition <myarch>-sdk-image.bb recipe with contents like this:

    #start here
    require recipes-core/images/core-image-minimal.bb

    IMAGE_FEATURES += "ssh-server-dropbear"
    SDKIMAGE_FEATURES = "dev-pkgs dbg-pkgs staticdev-pkgs"

    COMPATIBLE_MACHINE = "<myarch>"

    IMAGE_INSTALL += "\
    packagegroup-core-standalone-sdk-target \
    "

    BAD_RECOMMENDATIONS += " \
    ti-llvm3.6-dev \
    opencl-monitor-dev \
    libulm-dev \
    gdbserver-c6x-dev \
    coreutils \
    coreutils-dev \
    "

    export IMAGE_BASENAME = "<myarch>-sdk-image"

    #ends here

    I ran the created .sh script from the deploy dir and was able to use it!!
    To make it comatible with the yocto eclipse plugin I syminked x86_64-arago-linux to x86_64-sdk-linux. Now I have the Hello world up and running.

    On to some further customizations...
    If anybody could comment on my procedure, I would appreciate this.

    regards Thomas
  • thanks. The First patch led me to the experiment to remove this dependency, which then actually brought me a buildable SDK.
    For now I will go without this lib and see how far I get. I will also check the impact of the second patch.

    regards Thomas