OpenEmbedded

openembedded@lists.linaro.org

106 discussions

[PATCH] optee: use nonarch_base_libdir instead of /lib

by Ricardo Salveti

Hardcoded /lib is not compatible with usrmerge. Signed-off-by: Ricardo Salveti <ricardo(a)opensourcefoundries.com> --- meta-optee/recipes-security/optee/optee-os_git.bb | 8 ++++---- meta-optee/recipes-security/optee/optee-test_git.bb | 6 +++--- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/meta-optee/recipes-security/optee/optee-os_git.bb b/meta-optee/recipes-security/optee/optee-os_git.bb index 4f6be1e..c5f38fb 100644 --- a/meta-optee/recipes-security/optee/optee-os_git.bb +++ b/meta-optee/recipes-security/optee/optee-os_git.bb @@ -39,9 +39,9 @@ do_compile() { do_install() { #install core on boot directory - install -d ${D}/lib/firmware/ + install -d ${D}${nonarch_base_libdir}/firmware/ - install -m 644 ${B}/out/arm-plat-${OPTEEOUTPUTMACHINE}/core/*.bin ${D}/lib/firmware/ + install -m 644 ${B}/out/arm-plat-${OPTEEOUTPUTMACHINE}/core/*.bin ${D}${nonarch_base_libdir}/firmware/ #install TA devkit install -d ${D}/usr/include/optee/export-user_ta/ @@ -54,14 +54,14 @@ PACKAGE_ARCH = "${MACHINE_ARCH}" do_deploy() { install -d ${DEPLOYDIR}/optee - for f in ${D}/lib/firmware/*; do + for f in ${D}${nonarch_base_libdir}/firmware/*; do install -m 644 $f ${DEPLOYDIR}/optee/ done } addtask deploy before do_build after do_install -FILES_${PN} = "/lib/firmware/" +FILES_${PN} = "${nonarch_base_libdir}/firmware/" FILES_${PN}-dev = "/usr/include/optee" INSANE_SKIP_${PN}-dev = "staticdev" diff --git a/meta-optee/recipes-security/optee/optee-test_git.bb b/meta-optee/recipes-security/optee/optee-test_git.bb index 2d85d89..e2c49cc 100644 --- a/meta-optee/recipes-security/optee/optee-test_git.bb +++ b/meta-optee/recipes-security/optee/optee-test_git.bb @@ -40,11 +40,11 @@ do_install () { # install path should match the value set in optee-client/tee-supplicant # default TEEC_LOAD_PATH is /lib - mkdir -p ${D}/lib/optee_armtz/ - install -D -p -m0444 ${S}/out/ta/*/*.ta ${D}/lib/optee_armtz/ + mkdir -p ${D}${nonarch_base_libdir}/optee_armtz/ + install -D -p -m0444 ${S}/out/ta/*/*.ta ${D}${nonarch_base_libdir}/optee_armtz/ } -FILES_${PN} += "/lib/optee_armtz/" +FILES_${PN} += "${nonarch_base_libdir}/optee_armtz/" # Imports machine specific configs from staging to build PACKAGE_ARCH = "${MACHINE_ARCH}" -- 2.7.4

7 years, 4 months

Over-writing files from another package

by Ryan Harkin

Hello, I am seeing this error in my build: Configuring aCollected errors: * check_data_file_clashes: Package linux-firmware-bcm43430 wants to install file /linaro/mbl/workspace-arm/build-mbl/tmp-mbl-glibc/work/imx7s _warp-oe-linux-gnueabi/mbl-console-image-test/1.0-r0/root fs/lib/firmware/brcm/brcmfmac43430-sdio.bin But that file is already provided by package * firmware-imx * check_data_file_clashes: Package linux-firmware-bcm43430 wants to install file /linaro/mbl/workspace-arm/build-mbl/tmp-mbl-glibc/work/imx7s _warp-oe-linux-gnueabi/mbl-console-image-test/1.0-r0/root fs/lib/firmware/brcm/brcmfmac43430-sdio.txt But that file is already provided by package * firmware-imx In my build, I'm including meta-raspberrypi and meta-freescale-3rdparty in my manifest. These two meta layers include the following two files into the rootfs in various ways: /lib/firmware/brcm/brcmfmac43430-sdio.txt /lib/firmware/brcm/brcmfmac43430-sdio.bin For example, in the following files define a way of adding the firmware into the rootfs (there will be more ways they get into the build, saying as one is a .inc file): meta-freescale-3rdparty/recipes-bsp/broadcom-nvram-config/ broadcom-nvram-config.inc meta-raspberrypi/recipes-kernel/linux-firmware/linux-firmware_%.bbappend openembedded-core/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb My meta-layer is included after meta-freescale* and meta-raspberrypi, but before openembedded-core/meta in my BBLAYERS setup. However, I want to provide a newer version of these two files in my build. So we created this recipe in our meta layer: file: recipes-bsp/firmware-imx/firmware-imx_%.bbappend ------------------------------------------------------------ -------------------------- SRCREV_linuxfirmware = "a61ac5cf8374edbfe692d12f805a1b194f7fead2" SRCREV_recalboxbuildroot = "f648e4b54eb5e4be593746d6cc51375b22a7efbd" SRC_URI += "git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linu x-firmware.git;branch=${SRCBRANCH};destsuffix=${S}/git1;name=linuxfirmware <http://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git;…> \ git://github.com/recalbox/recalbox-buildroot.git;protocol= https;branch=${SRCBRANCH};destsuffix=${S}/git2;name=recalboxbuildroot <http://github.com/recalbox/recalbox-buildroot.git;protocol=https;branch=$%7…> " LIC_FILES_CHKSUM += "file://git1/LICENCE.broadcom_ bcm43xx;md5=3160c14df7228891b868060e1951dfbc \ file://git2/COPYING;md5=e4edbc78b8892db416b6a07e0d97309a " do_install_append() { install -d ${D}${base_libdir}/firmware install -d ${D}${base_libdir}/firmware/brcm cp -rfv git1/brcm/brcmfmac43430-sdio.bin ${D}${base_libdir}/firmware/br cm cp -rfv git2/board/warp7/rootfs_overlay/lib/firmware/brcm/brcmfmac43430-sdio.txt ${D}${base_libdir}/firmware/brcm } FILES_${PN} += "${base_libdir}/firmware/brcm/brcmfmac43430*" COMPATIBLE_MACHINE = "(imx7s-warp)" ------------------------------------------------------------ -------------------------- It builds fine in a "normal" configuration. However, in a "test" build, where "dev-pkgs" is added to IMAGE_FEATURES, I get the error as above. So how do I work around this issue? Am I doing the wrong thing by providing a bbappend to overlay these files? Any advice appreciated. Regards, Ryan.

7 years, 7 months

[Dragonboard410c] Regarding Kernel clean and build

by Sunny Bhayani

Hi All, I am new to the OpenEmbedded framework and kindly do let me know if this is not the right forum for such query. I am using the Dragonboard410c with the Linaro OpenEmbedded Release (Steps to build the sources is: https://github.com/96boards/oe-rpb-manifest) I want to do a clean build and incremental build of only the kernel sources. I checked articles for the same and found the below commands: bitbake -c cleansstate virtual/kernel bitbake -c clean virtual/kernel But the above commands are giving error like below: ******* Error Start ******* ERROR: Nothing PROVIDES 'linux-linaro-aarch64' ERROR: linux-linaro-aarch64 was skipped: We shouldn't have multilib variants for the kernel ERROR: linux-linaro-aarch64 was skipped: PREFERRED_PROVIDER_virtual/kernel set to linux-linaro-qcomlt, not linux-linaro-aarch64 ******* Error End ******* I also tried the below: bitbake -c cleansstate linux-linaro-qcomlt bitbake -c cleansstate linux-linaro-aarch64 But that also does not work. So can you please suggest from where can I know, how to build the kernel without triggering the whole build. Thanks & Regards, Sunny ************************************************************************************************************************************************************* eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. *************************************************************************************************************************************************************

7 years, 8 months

[meta-linaro][PATCH] python-wand: Add patch to ensure our built ImageMagick is used

by Tom Rini

It can be slightly tricky to build a copy of python-wand that will also function. A problem is that without additional logic (MAGICK_HOME), the python code will not look outside of system paths for a copy of the imagemagick library. However, even with this path added to the search list, the code will still try a 'naked' load of the library it wants. This can result in a visible failure if you have a new enough imagemagic-6 installed (such as 6.9.7) as the date string checking logic will fail. Work around these problems by setting MAGICK_HOME globally to the correct location and patch the api code to look for the form of imagemagick that we build first, rather than last, so that we are going to first search for what we know we built. Signed-off-by: Tom Rini <trini(a)konsulko.com> --- This patch should be applied to at least master, pyro and rocko. Arguably this should also be applied further back as without MAGICK_HOME it will never be looking in our sysroot. .../0001-wand-api.py-Change-search-order.patch | 32 ++++++++++++++++++++++ .../recipes-devtools/python/python-wand_0.4.4.bb | 7 ++++- 2 files changed, 38 insertions(+), 1 deletion(-) create mode 100644 meta-optee/recipes-devtools/python/python-wand/0001-wand-api.py-Change-search-order.patch diff --git a/meta-optee/recipes-devtools/python/python-wand/0001-wand-api.py-Change-search-order.patch b/meta-optee/recipes-devtools/python/python-wand/0001-wand-api.py-Change-search-order.patch new file mode 100644 index 000000000000..ac2c0b0622c0 --- /dev/null +++ b/meta-optee/recipes-devtools/python/python-wand/0001-wand-api.py-Change-search-order.patch @@ -0,0 +1,32 @@ +From 7691ebcf38c59332eb819f909250a22ba5e8e50b Mon Sep 17 00:00:00 2001 +From: Tom Rini <trini(a)konsulko.com> +Date: Tue, 24 Oct 2017 12:01:51 -0400 +Subject: [PATCH 1/1] wand/api.py: Change search order + +In addition to specifying MAGICK_HOME to ensure that we will even look +within our desired paths, we need to also check for the type of library +that we know we have. Otherwise we may find a different form of the +library in one of the system paths before we try ours. + +Upstream-Status: Inappropriate [configuration] +Signed-off-by: Tom Rini <trini(a)konsulko.com> +--- + wand/api.py | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/wand/api.py b/wand/api.py +index 19cf6d2..dde9c5e 100644 +--- a/wand/api.py ++++ b/wand/api.py +@@ -55,7 +55,7 @@ def library_paths(): + """ + libwand = None + libmagick = None +- versions = '', '-6', '-Q16', '-Q8', '-6.Q16' ++ versions = '-6.Q16', '-6', '-Q16', '-Q8', '' + options = '', 'HDRI', 'HDRI-2' + system = platform.system() + magick_home = os.environ.get('MAGICK_HOME') +-- +2.11.0 + diff --git a/meta-optee/recipes-devtools/python/python-wand_0.4.4.bb b/meta-optee/recipes-devtools/python/python-wand_0.4.4.bb index 9679b9c9f658..605bc59e2707 100644 --- a/meta-optee/recipes-devtools/python/python-wand_0.4.4.bb +++ b/meta-optee/recipes-devtools/python/python-wand_0.4.4.bb @@ -7,7 +7,8 @@ LIC_FILES_CHKSUM = "file://LICENSE;md5=170eafd687d4a2b950819cd5e067e6d5" SRCNAME = "wand" SRCREV = "c731c620c3c96c409a194dafab396ffbb97d6702" -SRC_URI = "git://github.com/dahlia/wand.git" +SRC_URI = "git://github.com/dahlia/wand.git \ + file://0001-wand-api.py-Change-search-order.patch" S = "${WORKDIR}/git" inherit setuptools @@ -33,6 +34,10 @@ inherit setuptools DEPENDS += " imagemagick-native" +# Tell python-wand where to look for our imagemagick and it must be +# one level up from where 'lib' resides. +export MAGICK_HOME="${STAGING_LIBDIR_NATIVE}/.." + BBCLASSEXTEND = "native" FILES_${PN} += "${datadir}" -- 2.7.4

7 years, 8 months

external-linaro-toolchain and TI's meta-arago/meta-argao-extra

by chris.laplante＠agilent.com

Hello all, It seems that the external-linaro-toolchain recipe (in meta-linaro/meta-linaro-toolchain) doesn't work unless TI's meta-arago/meta-arago-extras layer is also present. That layer contains, among other things: meta-arago-extras/recipes-devtools/meta/ * external-linaro-toolchain.bbappend - seems to fix a variety of packaging errors, and relaxes the requirement that external-linaro-toolchain itself provide libc Linux headers * external-linaro-sdk-toolchain.bb - provides the cross-canadian toolchain, for building nativesdk packages. My understanding is that part is useable when the host machine is the same as the SDK machine (e.g. both x86_64-linux), since otherwise you would need two external toolchains. * external-linaro-toolchain-cross.bb - seems to just provides some tweaks * external-linaro-bfd-version.inc - populates ELT_VER_BFD with the detected version meta-arago-extras/conf/distro/include/ * tclibc-external-linaro-toolchain.inc - the TCLIBC configuration that tells Yocto you're using the external Linaro glibc, instead of having Yocto built it. Is my understanding correct? If so, I'd be curious to know why these files are in meta-arago, as opposed to just being moved into meta-linaro-toolchain itself. If it's just due to a lack of time, then I'd be more than willing to help out. As things currently exist, I find the 'external-linaro-toolchain' recipe in meta-linaro to be a bit of a "carrot on a stick" - it looks really promising and enticing, but you can't get it to work without lots of effort. That effort ultimately amounts to implementing the changes that are present in meta-arago-extras... Thank you, Chris Laplante

7 years, 8 months

[PATCH] python-wand: add SRCREV, fix QA issue and add comment about imagemagick version

by Martin Jansa

* use SRCREV instead of tag name, so that bitbake doesn't translate tag to SRCREV every time it's parsing this recipe * fix QA issue: ERROR: QA Issue: python-wand: Files/directories were installed but not shipped in any package: /usr/share /usr/share/README.rst * add comment about imagemagick version needed to use python-wand-native otherwise it will use imagemagick from host Signed-off-by: Martin Jansa <Martin.Jansa(a)gmail.com> --- This is needed in all 3 branches: [morty][pyro][master] But for pyro you'll need to first backport from master (or forward port from pyro) the upgrade to 0.4.4 from: commit 7ed523b06bde259f99b21a15e8c936af4f18c752 Author: Fathi Boudra <fathi.boudra(a)linaro.org> Date: Thu Oct 5 22:46:48 2017 +0300 meta-optee: python-wand: upgrade to latest release 0.4.4 Latest python-wand release is from October 2016. Update to latest release: 0.4.4. Change-Id: I23dc1fbb817bbb26357c3ab6dcc86b251eea36e6 Signed-off-by: Fathi Boudra <fathi.boudra(a)linaro.org> .../recipes-devtools/python/python-wand_0.4.4.bb | 24 +++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/meta-optee/recipes-devtools/python/python-wand_0.4.4.bb b/meta-optee/recipes-devtools/python/python-wand_0.4.4.bb index 1043987..9679b9c 100644 --- a/meta-optee/recipes-devtools/python/python-wand_0.4.4.bb +++ b/meta-optee/recipes-devtools/python/python-wand_0.4.4.bb @@ -6,11 +6,33 @@ LIC_FILES_CHKSUM = "file://LICENSE;md5=170eafd687d4a2b950819cd5e067e6d5" SRCNAME = "wand" -SRC_URI = "git://github.com/dahlia/wand.git;tag=${PV}" +SRCREV = "c731c620c3c96c409a194dafab396ffbb97d6702" +SRC_URI = "git://github.com/dahlia/wand.git" S = "${WORKDIR}/git" inherit setuptools +# Requires imagemagick-6 while meta-oe morty and newer provides imagemagick-7 which isn't compatible with wand +# +# You can import imagemagick-5 from older meta-oe, before this upgrade: +# commit ec660639ecea3fcb6e554b6f1bafc504e8f2fc78 +# Author: Randy MacLeod <randy.macleod(a)windriver.com> +# Date: Mon Aug 8 17:41:34 2016 -0400 +# imagemagick: upgrade from 6.9.2 to 7.0.2 +# and add this commit on top of that: +# commit dfcb67af35936a351789044039a55e3fad299c1a +# Author: Andreas Müller <schnitzeltony(a)googlemail.com> +# Date: Sun Sep 18 02:47:26 2016 +0200 +# imagemagick: depend on fftw not virtual/fftw +# +# We need this old version becase python-wand-native used here +# depends on older imagemagick-native as discussed here: +# https://stackoverflow.com/questions/37011291/python-wand-image-is-not-recog… +# there still isn't newer python-wand supporting 7.* version: +# https://github.com/dahlia/wand/blob/4fe2c6ba9cb0d4105361cea6e9e9e8311608047… + DEPENDS += " imagemagick-native" BBCLASSEXTEND = "native" + +FILES_${PN} += "${datadir}" -- 2.7.4

7 years, 8 months

Possible issue in meta-linaro (http://git.linaro.org/openembedded/meta-linaro)

by Christian Haettich

Hi, I am not sure if this is the right place to provide this info. I came across an issue, which might be caused by a wrong entry in meta-linaro. See https://github.com/Angstrom-distribution/angstrom-manifest/issues/31 It seems that inheriting from image_types_uboot.bbclass is not required anymore and causes a error with a newer openembedde-core. The following seems to fix this little issue: diff --git a/meta-linaro/recipes-linaro/images/linaro-image-minimal-initramfs.bb b/meta-linaro/recipes-linaro/images/linaro-image-minimal-initramfs.bb index f928797..d83de70 100644 --- a/meta-linaro/recipes-linaro/images/linaro-image-minimal-initramfs.bb +++ b/meta-linaro/recipes-linaro/images/linaro-image-minimal-initramfs.bb @@ -36,4 +36,4 @@ IMAGE_LINGUAS = "" IMAGE_ROOTFS_SIZE = "8192" -inherit core-image image_types_uboot +inherit core-image Regards Feddischson

7 years, 10 months

Failed to build perf package with meta-linaro/receipes-kernel/perf

by Masami Hiramatsu

Hello, I tried to build my distro with meta-linaro/meta-linaro, I've found an issue on "perf". When I added "perf" to IMAGE_INSTALL, it causes an error as below; ---- NOTE: Running task 1452 of 2124 (/home/linaro/vsbu/openembedded-core/meta/recipes-kernel/perf/perf.bb:do_patch) NOTE: Running task 1453 of 2124 (/home/linaro/vsbu/meta-uniphier/recipes-kernel/linux/linux-uniphier-arm64_4.4.bb:do_populate_lic) NOTE: recipe linux-uniphier-arm64-4.4.8-AUTOINC+5f1a02e66c-r0: task do_kernel_configme: Started NOTE: recipe perf-4.2-r9: task do_patch: Started NOTE: recipe linux-uniphier-arm64-4.4.8-AUTOINC+5f1a02e66c-r0: task do_populate_lic: Started NOTE: recipe perf-4.2-r9: task do_patch: Succeeded NOTE: Running task 1454 of 2124 (/home/linaro/vsbu/openembedded-core/meta/recipes-kernel/perf/perf.bb:do_populate_lic) NOTE: recipe linux-uniphier-arm64-4.4.8-AUTOINC+5f1a02e66c-r0: task do_populate_lic: Succeeded NOTE: recipe perf-4.2-r9: task do_populate_lic: Started WARNING: perf-4.2-r9 do_populate_lic: Could not copy license file /home/linaro/vsbu/develop/tmp-glibc/work/ph1_ld20_global-oe-linux/perf/4.2-r9/linux-tools-4.2/COPYING to /home/linaro/vsbu/develop/tmp-glibc/work/ph1_ld20_global-oe-linux/perf/4.2-r9/license-destdir/perf/COPYING: [Errno 2] No such file or directory: '/home/linaro/vsbu/develop/tmp-glibc/work/ph1_ld20_global-oe-linux/perf/4.2-r9/linux-tools-4.2/COPYING' ERROR: perf-4.2-r9 do_populate_lic: QA Issue: perf: LIC_FILES_CHKSUM points to an invalid file: /home/linaro/vsbu/develop/tmp-glibc/work/ph1_ld20_global-oe-linux/perf/4.2-r9/linux-tools-4.2/COPYING [license-checksum] NOTE: recipe perf-4.2-r9: task do_populate_lic: Succeeded [...] NOTE: Running task 2084 of 2124 (/home/linaro/vsbu/openembedded-core/meta/recipes-kernel/perf/perf.bb:do_prepare_recipe_sysroot) NOTE: recipe perf-4.2-r9: task do_prepare_recipe_sysroot: Started NOTE: recipe perf-4.2-r9: task do_prepare_recipe_sysroot: Succeeded NOTE: Running task 2085 of 2124 (/home/linaro/vsbu/openembedded-core/meta/recipes-kernel/perf/perf.bb:do_configure) NOTE: recipe perf-4.2-r9: task do_configure: Started ERROR: perf-4.2-r9 do_configure: Function failed: do_configure (log file is located at /home/linaro/vsbu/develop/tmp-glibc/work/ph1_ld20_global-oe-linux/perf/4.2-r9/temp/log.do_configure.4060) ERROR: Logfile of failure stored in: /home/linaro/vsbu/develop/tmp-glibc/work/ph1_ld20_global-oe-linux/perf/4.2-r9/temp/log.do_configure.4060 NOTE: recipe perf-4.2-r9: task do_configure: Failed ERROR: Task (/home/linaro/vsbu/openembedded-core/meta/recipes-kernel/perf/perf.bb:do_configure) failed with exit code '1' NOTE: recipe bind-9.10.3-P3-r0: task do_install: Succeeded NOTE: recipe perl-5.24.1-r0: task do_package: Succeeded NOTE: Tasks Summary: Attempted 2085 tasks of which 6 didn't need to be rerun and 1 failed. --- So it seems that it doesn't do do_fetch and just failed. I've found you tried to re-enable do_fetch by d.delVarFlag() in meta-linaro/meta-linaro/recipes-kernel/perf/perf.bbappend as below, ----- LICENSE = "GPL-2" LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7" PV = "4.2" FILESEXTRAPATHS_prepend := "${THISDIR}/files:" SRC_URI = "http://snapshot.debian.org/archive/debian/20150926T032755Z/pool/main/l/linu…" SRC_URI[md5sum] = "9a4a83c22368281b85e4ab12dcc3ec95" SRC_URI[sha256sum] = "78b336fca5e250f205fe5bc10cc77943dc95c2d66899f0bc95963b3aab8ef644" S = "${WORKDIR}/linux-tools-${PV}" B = "${WORKDIR}/linux-tools-${PV}-build" do_compile_prepend() { mkdir -p ${S}/include/generated echo "#define UTS_RELEASE \"${PV}\"" > ${S}/include/generated/utsrelease.h } # Ensure the above tarball gets fetched, unpackaged and patched python () { d.delVarFlag("do_fetch", "noexec") d.delVarFlag("do_unpack", "noexec") d.delVarFlag("do_patch", "noexec") } ----- But it seems not work correctly. Actually, when I just removed the perf.bbappend file from meta-linaro (just for debugging) bitbake completed to build rootfs image with perf. I actually would like to know below - Is there any recommended configuration for perf? - Was that tested with any configure before? - Is that tested (built) in nightly test build? If it is clear, I can dig deeper by comparing configurations by myself. Thank you, -- Masami Hiramatsu

7 years, 11 months

[meta-optee][PATCH] optee-client: Respect LDFLAGS set from OE build

by Martin Jansa

* Unify LFLAGS/LDFLAGS variable names (only tee-supplicant was using LDFLAGS). * Fixes: ERROR: optee-client-2.4.0+gitAUTOINC+1df4046bd7-r0 do_package_qa: QA Issue: No GNU_HASH in the elf binary: 'optee-client/2.4.0+gitAUTOINC+1df4046bd7-r0/packages-split/optee-client/usr/bin/tee-supplicant' No GNU_HASH in the elf binary: 'optee-client/2.4.0+gitAUTOINC+1df4046bd7-r0/packages-split/optee-client/usr/lib/libteec.so.1.0' [ldflags] ERROR: optee-client-2.4.0+gitAUTOINC+1df4046bd7-r0 do_package_qa: QA run found fatal errors. Please consider fixing them. ERROR: optee-client-2.4.0+gitAUTOINC+1df4046bd7-r0 do_package_qa: Function failed: do_package_qa ERROR: Logfile of failure stored in: optee-client/2.4.0+gitAUTOINC+1df4046bd7-r0/temp/log.do_package_qa.31246 Signed-off-by: Martin Jansa <Martin.Jansa(a)gmail.com> --- meta-optee/recipes-security/optee/optee-client.bb | 1 + .../0001-Respect-LDFLAGS-set-from-OE-build.patch | 105 +++++++++++++++++++++ 2 files changed, 106 insertions(+) create mode 100644 meta-optee/recipes-security/optee/optee-client/0001-Respect-LDFLAGS-set-from-OE-build.patch diff --git a/meta-optee/recipes-security/optee/optee-client.bb b/meta-optee/recipes-security/optee/optee-client.bb index 7b471f3..4c5ac1a 100644 --- a/meta-optee/recipes-security/optee/optee-client.bb +++ b/meta-optee/recipes-security/optee/optee-client.bb @@ -9,6 +9,7 @@ PV = "2.4.0+git${SRCPV}" inherit pythonnative systemd SRC_URI = "git://github.com/OP-TEE/optee_client.git \ + file://0001-Respect-LDFLAGS-set-from-OE-build.patch \ file://tee-supplicant.service" S = "${WORKDIR}/git" diff --git a/meta-optee/recipes-security/optee/optee-client/0001-Respect-LDFLAGS-set-from-OE-build.patch b/meta-optee/recipes-security/optee/optee-client/0001-Respect-LDFLAGS-set-from-OE-build.patch new file mode 100644 index 0000000..4d25b76 --- /dev/null +++ b/meta-optee/recipes-security/optee/optee-client/0001-Respect-LDFLAGS-set-from-OE-build.patch @@ -0,0 +1,105 @@ +From 73cb675c16bd63ee0e760a4067ffda4b050d19fa Mon Sep 17 00:00:00 2001 +From: Martin Jansa <Martin.Jansa(a)gmail.com> +Date: Thu, 15 Jun 2017 17:20:35 -0700 +Subject: [PATCH] Respect LDFLAGS set from OE build + +* Unify LFLAGS/LDFLAGS variable names (only tee-supplicant was using LDFLAGS). +* Fixes: + ERROR: optee-client-2.4.0+gitAUTOINC+1df4046bd7-r0 do_package_qa: QA Issue: No GNU_HASH in the elf binary: 'optee-client/2.4.0+gitAUTOINC+1df4046bd7-r0/packages-split/optee-client/usr/bin/tee-supplicant' + No GNU_HASH in the elf binary: 'optee-client/2.4.0+gitAUTOINC+1df4046bd7-r0/packages-split/optee-client/usr/lib/libteec.so.1.0' [ldflags] + ERROR: optee-client-2.4.0+gitAUTOINC+1df4046bd7-r0 do_package_qa: QA run found fatal errors. Please consider fixing them. + ERROR: optee-client-2.4.0+gitAUTOINC+1df4046bd7-r0 do_package_qa: Function failed: do_package_qa + ERROR: Logfile of failure stored in: optee-client/2.4.0+gitAUTOINC+1df4046bd7-r0/temp/log.do_package_qa.31246 + +Upstream-Status: Pending +Signed-off-by: Martin Jansa <Martin.Jansa(a)gmail.com> + +--- + libsqlfs/Makefile | 2 +- + libsqlite3/Makefile | 2 +- + libteec/Makefile | 2 +- + tee-supplicant/Makefile | 10 +++++----- + 4 files changed, 8 insertions(+), 8 deletions(-) + +diff --git a/libsqlfs/Makefile b/libsqlfs/Makefile +index b53ccde..7a3bde6 100644 +--- a/libsqlfs/Makefile ++++ b/libsqlfs/Makefile +@@ -38,7 +38,7 @@ SQLFS_CFLAGS := $(addprefix -I, $(SQLFS_INCLUDES)) \ + $(filter-out $(SQLFS_CFLAGS_REMOVE),$(CFLAGS)) \ + -Wno-missing-format-attribute + +-SQLFS_LFLAGS := -lpthread ++SQLFS_LFLAGS := $(LDFLAGS) -lpthread + SQLFS_LIBS := $(OUT_DIR)/../libsqlite3/libsqlite3.a + SQLFS_LIBRARY := $(OUT_DIR)/$(LIB_MAJ_MIN) + +diff --git a/libsqlite3/Makefile b/libsqlite3/Makefile +index a69aabd..6a6d833 100644 +--- a/libsqlite3/Makefile ++++ b/libsqlite3/Makefile +@@ -19,7 +19,7 @@ SQLITE3_CFLAGS_REMOVE := -Wall -Wbad-function-cast -Wswitch-default \ + -Wfloat-equal -Werror -Wwrite-strings -Wcast-align + SQLITE3_CFLAGS := $(addprefix -I, $(SQLITE3_INCLUDES)) \ + $(filter-out $(SQLITE3_CFLAGS_REMOVE),$(CFLAGS)) +-SQLITE3_LFLAGS := ++SQLITE3_LFLAGS := $(LDFLAGS) + SQLITE3_LIBRARY := $(OUT_DIR)/$(LIB_NAME) + + libsqlite3: $(SQLITE3_LIBRARY) +diff --git a/libteec/Makefile b/libteec/Makefile +index 66055a7..d3eb2a1 100644 +--- a/libteec/Makefile ++++ b/libteec/Makefile +@@ -29,7 +29,7 @@ TEEC_CFLAGS := $(addprefix -I, $(TEEC_INCLUDES)) $(CFLAGS) -D_GNU_SOURCE \ + -DDEBUGLEVEL_$(CFG_TEE_CLIENT_LOG_LEVEL) \ + -DBINARY_PREFIX=\"TEEC\" + +-TEEC_LFLAGS := -lpthread ++TEEC_LFLAGS := $(LDFLAGS) -lpthread + TEEC_LIBRARY := $(OUT_DIR)/$(LIB_MAJ_MIN) + + libteec: $(TEEC_LIBRARY) +diff --git a/tee-supplicant/Makefile b/tee-supplicant/Makefile +index 204273f..40df763 100644 +--- a/tee-supplicant/Makefile ++++ b/tee-supplicant/Makefile +@@ -57,7 +57,7 @@ ifeq ($(CFG_TA_TEST_PATH),y) + TEES_CFLAGS += -DCFG_TA_TEST_PATH=1 + endif + TEES_FILE := $(OUT_DIR)/$(PACKAGE_NAME) +-TEES_LDFLAGS := -L$(OUT_DIR)/../libteec -lteec ++TEES_LFLAGS := $(LDFLAGS) -L$(OUT_DIR)/../libteec -lteec + + ifeq ($(CFG_SQL_FS),y) + TEES_CFLAGS += -DCFG_SQL_FS +@@ -67,22 +67,22 @@ TEES_CFLAGS_sql_fs.c := -Wno-strict-prototypes \ + # Note: explicitly requesting a shared library (.so) here, because statically + # linking a LGPL library has licensing implications. Make sure you review + # and comply with libsqlfs/COPYING section 6 before doing so. +-TEES_LDFLAGS += -L$(OUT_DIR)/../libsqlfs -l:libsqlfs.so -ldl ++TEES_LFLAGS += -L$(OUT_DIR)/../libsqlfs -l:libsqlfs.so -ldl + endif + + ifeq ($(CFG_TA_GPROF_SUPPORT),y) + TEES_CFLAGS += -DCFG_TA_GPROF_SUPPORT + endif + +-TEES_LDFLAGS += -lpthread ++TEES_LFLAGS += -lpthread + # Needed to get clock_gettime() for for glibc versions before 2.17 +-TEES_LDFLAGS += -lrt ++TEES_LFLAGS += -lrt + + tee-supplicant: $(TEES_FILE) + + $(TEES_FILE): $(TEES_OBJS) + @echo " LINK $@" +- $(VPREFIX)$(CC) -o $@ $+ $(TEES_LDFLAGS) ++ $(VPREFIX)$(CC) -o $@ $+ $(TEES_LFLAGS) + @echo "" + + $(TEES_OBJ_DIR)/%.o: $(TEES_SRC_DIR)/%.c +-- +1.9.1 + -- 2.13.1

7 years, 11 months

external-linaro-toolchain issues in master

by Denys Dmytriyenko

I'm still trying to get the external-linaro-toolchain going in master after all the recent changes... First of all, I'm seeing these: ERROR: external-linaro-toolchain-2017.02-r0.arago35 do_install: oe_multilib_header: Unable to find header bits/long-double.h. ERROR: external-linaro-toolchain-2017.02-r0.arago35 do_install: oe_multilib_header: Unable to find header bits/fp-fast.h. They are coming from these changes: http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-core/gli… http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-core/gli… I believe (please correct me) those are due to Linaro toolchain 6.3 still using glibc 2.23... But the real problem comes when I try to build gcc (either "linaro-6.3" from meta-linaro-toolchain, or "6.3" from oe-core) for the target using external-linaro-toolchain: | g++: error: gengtype-lex.c: No such file or directory | g++: fatal error: no input files It seems to come from oe-core gcc-source.inc, which removes gengtype-lex.c in order to re-generate it: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/g… Has anyone looked into fixing these issues? What's the status of external-linaro-toolchain in master? Will this be looked at for 6.3 version, or not until 7.x gets integrated? Thanks. -- Denys

8 years

← Newer
1
...
4
5
6
7
8
9
10
11
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

OpenEmbedded