Re: [yocto] master-next : QA issue with glibc locale
On Mon, Oct 22, 2018 at 11:01 AM Belisko Marek wrote: > > Hi Khem, > On Mon, Oct 22, 2018 at 12:31 AM Khem Raj wrote: > > > > On Sun, Oct 21, 2018 at 7:42 PM Belisko Marek > > wrote: > > > > > > Hi Khem, > > > > > > On Sun, Oct 21, 2018 at 8:40 PM Khem Raj wrote: > > > > > > > > > > > > > > > > On Sun, Oct 21, 2018 at 7:27 PM Belisko Marek > > > > wrote: > > > >> > > > >> Hi, > > > >> > > > >> I had problem with rocko see here [1] but issue is still present in > > > >> poky master-next also: > > > > > > > > > > > > Is it using stock poky or are there any customizations if yes then > > > > please share those too > > > Nope any customizations just stock poky (master-next > > > 32bfcbed083622de7462d0c563a7070acd7efe9b) > > > > interesting, I dont have is reproducble so cant see much through the > > issue . but does > > the workaround suggested in > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=12265 > > help where you disable cross-localedef > I tried suggested workaround (wipe all stuff except downloads and > re-run again) and hit this: > > ERROR: core-image-base-1.0-r0 do_rootfs: Unable to install packages. > Command > '/home/marek/projects/yocto/poky/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/core-image-base/1.0-r0/recipe-sysroot-native/usr/bin/opkg > --volatile-cache -f > /home/marek/projects/yocto/poky/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/core-image-base/1.0-r0/opkg.conf > -t > /home/marek/projects/yocto/poky/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/core-image-base/1.0-r0/temp/ipktemp/ > -o > /home/marek/projects/yocto/poky/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/core-image-base/1.0-r0/rootfs > --force_postinstall --prefer-arch-to-version install > locale-base-en-gb locale-base-en-us' returned 255: > Collected errors: > * opkg_prepare_url_for_install: Couldn't find anything to satisfy > 'locale-base-en-gb'. > * rm_r: Failed to open dir > /home/marek/projects/yocto/poky/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/core-image-base/1.0-r0/temp/ipktemp//opkg-o8sLzj: > No such file or directory. > > ERROR: core-image-base-1.0-r0 do_rootfs: Function failed: do_rootfs > ERROR: Logfile of failure stored in: > /home/marek/projects/yocto/poky/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/core-image-base/1.0-r0/temp/log.do_rootfs.2729 > ERROR: Task > (/home/marek/projects/yocto/poky//meta/recipes-core/images/core-image-base.bb:do_rootfs) > failed with exit code '1' > > I have same with below patch (when workaround QA issue). I have > meta-java in bblayers and building openjdk-8 (but I don't think this > could have some influence). Thanks. Looks like issue is with core-image-base. When build core-image-minimal issue vanished (with workaround from bugzilla) > > > > > >> > > > >> > > > >> > > > >> ERROR: glibc-locale-2.28-r0 do_package: QA Issue: glibc-locale: > > > >> Files/directories were installed but not shipped in any package: > > > >> /usr/share/i18n > > > >> /usr/share/i18n/charmaps > > > >> /usr/share/i18n/locales > > > >> /usr/share/i18n/charmaps/ISO-8859-2.gz > > > >> /usr/share/i18n/charmaps/T.61-8BIT.gz > > > >> /usr/share/i18n/charmaps/IBM855.gz > > > >> /usr/share/i18n/charmaps/IBM1163.gz > > > >> /usr/share/i18n/charmaps/IBM1129.gz > > > >> /usr/share/i18n/charmaps/SHIFT_JIS.gz > > > >> /usr/share/i18n/charmaps/CWI.gz > > > >> /usr/share/i18n/charmaps/CP1253.gz > > > >> /usr/share/i18n/charmaps/IBM880.gz > > > >> /usr/share/i18n/charmaps/T.101-G2.gz > > > >> /usr/share/i18n/charmaps/ISO-8859-5.gz > > > >> /usr/share/i18n/charmaps/CP1250.gz > > > >> /usr/share/i18n/charmaps/INIS-8.gz > > > >> /usr/share/i18n/charmaps/SHIFT_JISX0213.gz > > > >> /usr/share/i18n/charmaps/IBM297.gz > > > >> /usr/share/i18n/charmaps/ISO_10367-BOX.gz > > > >> /usr/share/i18n/charmaps/CP1257.gz > > > >> /usr/share/i18n/charmaps/JIS_C6220-1969-RO.gz > > > >> /usr/share/i18n/charmaps/IBM278.gz > > > >> /usr/share/i18n/charmaps/IBM858.gz > > > >> /usr/share/i18n/charmaps/KSC5636.gz > > > >> /usr/share/i18n/charmaps/IBM285.gz > > > >> /usr/share/i18n/charmaps/INIS.gz > > > >> /usr/share/i18n/charmaps/EUC-TW.gz > > > >> /usr/share/i18n/charmaps/IBM274.gz > > > >> /usr/share/i18n/charmaps/IBM038.gz > > > >> /usr/share/i18n/charmaps/DS_2089.gz > > > >> /usr/share/i18n/charmaps/GB2312.gz > > > >> /usr/share/i18n/charmaps/EBCDIC-UK.gz > > > >> /usr/share/i18n/charmaps/GOST_19768-74.gz > > > >> /usr/share/i18n/charmaps/ISO-IR-209.gz > > > >> /usr/share/i18n/charmaps/BS_4730.gz > > > >> /usr/share/i18n/charmaps/IT.gz > > > >> /usr/share/i18n/charmaps/IBM918.gz > > > >> /usr/share/i18n/charmaps/MAC-CYRILLIC.gz > > > >> /usr/share/i18n/charmaps/CP10007.gz > > > >> /usr/share/i18n/charmaps/BS_VIEWDATA.gz > > > >> /usr/share/i18n/charmaps/ISO_646.IRV.gz > > > >> /usr/share/i18n/charmaps/EBCDIC-FI-SE.gz > > > >> /usr/share/i18n/charmaps/NF_Z_62-010.gz > > > >> /usr/share/i18n/cha
[yocto] Busybox_1.23.2 fails at do_compile on Poky-Sumo
Hello Yocto, I'm currently building an image with the busybox_1.23.2.bb recipe included, using Yocto Sumo 2.5 with the Bitbake version 1.37.0. It is running on a CentOS host building images for the target ARM cortexa8. This busybox recipe is placed in another custom layer. Though this recipe compiles without errors in Poky-Fido, in Poky-Sumo I get compilation errors due to missing header files. Please take a look at the link below for the log.do_compile output. https://pastebin.com/yYXJnC2e Both limits.h and byteswap.h don't exist in Poky-Fido as well, but compiles without problems, unlike on Sumo. Does this have to do with the wrong Toolchains used or due to glibc (FYI: glibc_2.27 is been used)? If it has to do with the Toolchains, which one should I be using and how do I go about it? Could someone please point me in the right direction? Here is the Build Config: Build Configuration: BB_VERSION = "1.37.0" BUILD_SYS= "x86_64-linux" NATIVELSBSTRING = "universal-4.8" TARGET_SYS = "arm-poky-linux-gnueabi" MACHINE = "arm-cortex-a8" DISTRO = "poky" DISTRO_VERSION = "2.5" TUNE_FEATURES= "arm armv7a vfp neon callconvention-hard cortexa8" TARGET_FPU = "hard" meta-networking meta-python = "master:45ee3c0e98bd3ed81419aaeae1e7324e486161a2" meta-userbsp-ti meta meta-poky meta-yocto-bsp meta-user-common = ":" meta-oe = "master:45ee3c0e98bd3ed81419aaeae1e7324e486161a2" workspace= ":" Thanks in advance! Regards, Mit freundlichen Grüßen / Best Regards, Dhanush -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] NAME missing in mpc8315e-rdb.conf
A quick grep over all of the native config files shows that of all the "#@TYPE: Machine", only one lacks a "#@NAME", mpc8315e-rdb.conf. It appears that the file OE version of the file has a real name and description. See http://git.openembedded.org/openembedded/plain/conf/machine/mpc8315e-rdb.conf Is there a reason to not at least copy this and have it provide some useful information? Thanks, Jon -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] ARM Cross Compiler SDK Toolchain
Hi Yocto, I am running Yocto 2.5 (Poky Sumo) on the host system CentOS 7.1 to build images for the target system ARM cortexa8 with a Target_FPU configured to hard. I would like to use a Cross Compiler SDK Toolchain in order to build the images, as the current toolchain fails with a few recipes during compilation due to missing include files. I tried building the toolchain using "bitbake meta-toolchain", but unfortunately that failed as well at do_generate_content_debug. But also, as far as I understand this command builds the SDK with compilers for the host system and not for the target system. I would like to use a pre-built SDK, if one is available for ARM cortex A8 architecture. I have looked all around and haven't found one. Could some Yocto Experts point me in the right direction? How can go about finding a Cross Compiler Toolchain in order to overcome the compilation errors. Thanks in advance for your help. Regards, Mit freundlichen Grüßen / Best Regards, Dhanush -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto Project Status WW43’18
Current Dev Position: YP 2.6 M4. Next Deadline: YP 2.6 M4 Build Target was Oct. 1, 2018 SWAT Team Rotation: · SWAT lead is currently: Amanda · SWAT team rotation: Amanda -> Tracy on Oct. 26, 2018 · SWAT team rotation: Tracy -> Chen on Nov. 2, 2018 · https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Key Status/Updates: · YP 2.6 M3 rc1 was released. · We have branched for thud at this point and the new release branches have been created. We have not started working on master patches yet though, we’re still concentrating on the 2.6 release. · Any ptest regressions have been fixed, thanks to Ross and Wind River in particular for helping with that. We should have similar results to M2 for M4 now based on this. · We continue to hold building M4 until we have the oeqa results handling code merged. This is because it should help us better handle maintaining and QAing 2.6 as a stable release. · There was an issue found with the recent _remove changes and a fix is now in master. If anyone does see any other odd behaviour around that operator please to report it ASAP. · A report of potential M4 issues was sent earlier in the week. · 2.6 M4 is due to be built as soon as we have the oeqa reporting patches merged. Oher changes which put the release at risk will be deferred to master. Planned Releases for YP 2.6: · YP 2.6 M4 Build Target is Oct. 1, 2018 · YP 2.6 M4 Release Target is Oct. 26, 2018 Planned upcoming dot releases: · YP 2.4.4 (Rocko) will be targeted after YP 2.6 M4 is done. · YP 2.5.2 (Sumo) will be targeted after YP 2.4.4 is done. Tracking Metrics: · WDD 2387 (last week 2462) (https://wiki.yoctoproject.org/charts/combo.html) · Poky Patch Metrics oTotal patches found: 1690 (last week 1682) oPercentage of patches in the Pending State: 738 (44%) [last week 736 (44%)] Key Status Links for YP: https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.6_Status https://wiki.yoctoproject.org/wiki/Yocto_2.6_Schedule https://wiki.yoctoproject.org/wiki/Yocto_2.6_Features The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status [If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!] Thanks, Stephen K. Jolley Yocto Project Program Manager INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 •Cell:(208) 244-4460 • Email: stephen.k.jol...@intel.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Busybox_1.23.2 fails at do_compile on Poky-Sumo
On Tue, Oct 23, 2018 at 2:58 AM, Dhanush K.S wrote: > Hello Yocto, > > I'm currently building an image with the busybox_1.23.2.bb recipe included, > using Yocto Sumo 2.5 with the Bitbake version 1.37.0. It is running on a > CentOS host building images for the target ARM cortexa8. This busybox recipe > is placed in another custom layer. Though this recipe compiles without > errors in Poky-Fido, in Poky-Sumo I get compilation errors due to missing > header files. Please take a look at the link below for the log.do_compile > output. > > https://pastebin.com/yYXJnC2e From the log of the failing command, the cross compiler is being called without a --sysroot option, which usually means the CC value set by the build environment is being ignored or over-ridden. I guess your custom busybox recipe is missing the following update: http://git.openembedded.org/openembedded-core/commit/?id=b7c265e1edd5c82126c1f3915ba5ca9efef57c00 Which is required in order to work correctly with versions of OE containing the following change: http://git.openembedded.org/openembedded-core/commit/?id=aeb653861a0ec39ea7a014c0622980edcbf653fa > Both limits.h and byteswap.h don't exist in Poky-Fido as well, but compiles > without problems, unlike on Sumo. Does this have to do with the wrong > Toolchains used or due to glibc (FYI: glibc_2.27 is been used)? If it has to > do with the Toolchains, which one should I be using and how do I go about > it? Could someone please point me in the right direction? Generally you should not expect a third party layer originally created for fido to "just work" with sumo. Perhaps ask whoever maintains your custom layers and recipes whether they have a version which has been tested with sumo. > Here is the Build Config: > > Build Configuration: > BB_VERSION = "1.37.0" > BUILD_SYS= "x86_64-linux" > NATIVELSBSTRING = "universal-4.8" > TARGET_SYS = "arm-poky-linux-gnueabi" > MACHINE = "arm-cortex-a8" > DISTRO = "poky" > DISTRO_VERSION = "2.5" > TUNE_FEATURES= "arm armv7a vfp neon callconvention-hard cortexa8" > TARGET_FPU = "hard" > meta-networking > meta-python = "master:45ee3c0e98bd3ed81419aaeae1e7324e486161a2" > meta-userbsp-ti > meta > meta-poky > meta-yocto-bsp > meta-user-common = ":" > meta-oe = "master:45ee3c0e98bd3ed81419aaeae1e7324e486161a2" > workspace= ":" > > Thanks in advance! > Regards, > Mit freundlichen Grüßen / Best Regards, > Dhanush > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] NAME missing in mpc8315e-rdb.conf
On Tuesday, 23 October 2018 11:12:34 PM NZDT Jon Mason wrote: > A quick grep over all of the native config files shows that of all the > "#@TYPE: Machine", only one lacks a "#@NAME", mpc8315e-rdb.conf. > > It appears that the file OE version of the file has a real name and > description. See > http://git.openembedded.org/openembedded/plain/conf/machine/mpc8315e-rdb.conf > > Is there a reason to not at least copy this and have it provide some > useful information? Yes please - this would show up in the layer index so it is worth having: http://layers.openembedded.org/layerindex/branch/master/machines/? q=mpc8315e&search=1 Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] 2.6 migration guide
Hi folks When Scott prepares the migration guide for a release, he usually looks to me to collate the notable changes for it (those requiring user intervention). I haven't prepared anything yet though and the 2.6 release is fast approaching. Can anyone who has been involved in or is aware of such changes in master for upcoming 2.6 (thud) make a note of it on the wiki in raw form on this page: https://wiki.yoctoproject.org/wiki/FutureMigrationGuide Scott and I will take care of cleaning it up, so things added there don't need to be perfect. I will also be doing my usual trawl through the commits in the release for the more general changelog, so most things will get picked up that way, but it's really helpful if people with first-hand knowledge of the implications of some of these changes are involved in how they get documented. Thanks, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] master branch build failing with error 'update_font_cache' failed
I am trying to build core-image-minimal for qemu86, I am always getting the following error. I have seen this message with sumo branch also, but there it was coming as warning. ERROR: core-image-minimal-1.0-r0 do_rootfs: The postinstall intercept hook 'update_font_cache' failed, details in /mnt/DATA_PARTITION2/qemu/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/temp/log.do_rootfs ERROR: core-image-minimal-1.0-r0 do_rootfs: Function failed: do_rootfs ERROR: Logfile of failure stored in: /mnt/DATA_PARTITION2/qemu/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/temp/log.do_rootfs.29330 ERROR: Task (/mnt/DATA_PARTITION/poky/meta/recipes-core/images/core-image-minimal.bb:do_rootfs) failed with exit code '1' Please help me to resolve this issue. -- *RegardsSanjay* -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Openjdk-8(Version 162b12) crash during runtime
I want to run latest java (version 162b12) which is given in latest meta-java branch (sumo) for the colibri-imx6 module(armv7 architecture) from Toradex. Currently I'm using latest poky version Sumo, and all the latest branch for different layers. I'm able to compile latest java successfully., but when i'm trying to run on module its show following error. GCC version: 7.3.0 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (os_linux_zero.cpp:254), pid=14001, tid=0x7683a460 # fatal error: caught unhandled signal 11 # # JRE version: (8.0_162-b12) (build ) # Java VM: OpenJDK Zero VM (25.162-b12 interpreted mode linux-arm ) # Core dump written. Default location: /home/root/core or core.14001 # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # for more information you can check attachment. please help me on this issue. Regards, Hitendra Prajapati # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (os_linux_zero.cpp:254), pid=1810, tid=0x767d1460 # fatal error: caught unhandled signal 11 # # JRE version: (8.0_162-b12) (build ) # Java VM: OpenJDK Zero VM (25.162-b12 interpreted mode linux-arm ) # Core dump written. Default location: /home/root/core or core.1810 # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # --- T H R E A D --- Current thread (0x76506670): JavaThread "main" [_thread_in_Java, id=1811, stack(0x76653000,0x767d2000)] Stack: [0x76653000,0x767d2000], sp=0x76714184, free space=772k Java frames: 0x767d0730: stack_word[6] = 0x767d06e8 0x767d0734: stack_word[5] = 0x6e407608 0x767d0738: stack_word[4] = 0x0001 0x767d073c: stack_word[3] = 0x6e4075b8 0x767d0740: stack_word[2] = 0x6e4075b8 0x767d0744: stack_word[1] = 0x6e407448 0x767d0748: stack_word[0] = 0x6e407590 0x767d074c: istate->_thread = 0x76506670 0x767d0750: istate->_bcp = 0x6e034e09 (bci 25) 0x767d0754: istate->_locals = 0x767d0798 0x767d0758: istate->_constants= 0x6e034f90 0x767d075c: istate->_method = sun.reflect.Reflection.()V 0x767d0760: istate->_mdx = 0x 0x767d0764: istate->_stack= 0x767d073c 0x767d0768: istate->_msg = 0x0008 0x767d076c: istate->_result = 0x6e036100 0x767d0770: (istate->_result) = 0x744b5140 0x767d0774: (istate->_result) = 0x0003 0x767d0778: istate->_prev_link= 0x 0x767d077c: istate->_oop_temp = 0x 0x767d0780: istate->_stack_base = 0x767d074c 0x767d0784: istate->_stack_limit = 0x767d072c 0x767d0788: istate->_monitor_base = 0x767d074c 0x767d078c: istate->_self_link= 0x767d074c 0x767d0790: frame_type= INTERPRETER_FRAME 0x767d0794: next_frame= 0x767d07a4 0x767d0798: local[0] = 0x6e407590 0x767d079c: call_wrapper = 0x767148f0 0x767d07a0: frame_type= ENTRY_FRAME 0x767d07a4: next_frame= 0x767d0808 0x767d07a8: local[5] = 0x767d0774 0x767d07ac: local[4] = 0x6e407418 0x767d07b0: local[3] = 0x 0x767d07b4: local[2] = 0x6e407408 0x767d07b8: local[1] = 0x6e407408 0x767d07bc: local[0] = 0x6e402b28 0x767d07c0: istate->_thread = 0x76506670 0x767d07c4: istate->_bcp = 0x6dfee4fe (bci 14) 0x767d07c8: istate->_locals = 0x767d0808 0x767d07cc: istate->_constants= 0x6e00ce60 0x767d07d0: istate->_method = sun.misc.Unsafe.()V 0x767d07d4: istate->_mdx = 0x 0x767d07d8: istate->_stack= 0x767d07b4 0x767d07dc: istate->_msg = 0x0003 0x767d07e0: istate->_result = 0x6dfeb648 0x767d07e4: (istate->_result) = 0x744b517c 0x767d07e8: (istate->_result) = 0x0003 0x767d07ec: istate->_prev_link= 0x 0x767d07f0: istate->_oop_temp = 0x 0x767d07f4: istate->_stack_base = 0x767d07c0 0x767d07f8: istate->_stack_limit = 0x767d07a4 0x767d07fc: istate->_monitor_base = 0x767d07c0 0x767d0800: istate->_self_link= 0x767d07c0 0x767d0804: frame_type= INTERPRETER_FRAME 0x767d0808: next_frame= 0x767d0814 0x767d080c: call_wrapper = 0x76714f98 0x767d0810: frame_type= ENTRY_FRAME 0x767d0814: next_frame= 0x767d0868 0x767d0818: local[1] = 0x 0x767d081c: local[0] = 0x767d07e8 0x767d0820: istate->_thread = 0x76506670 0x767d0824: istate->_bcp = 0x6e033320 (bci 0) 0x767d0828: istate->_locals = 0x767d0868 0x767d082c: istate->_constants= 0x6e033470 0x767d0830: istate->_method = sun.misc.SharedSecrets.()V 0x767d0834: istate->_mdx = 0x 0x767d0838: istate->_stack= 0x767d081c 0x767d083c: istate->_
Re: [yocto] ARM Cross Compiler SDK Toolchain
I usually build using bitbake -c populate_ext_sdk core-image-minimal This builds the SDK in tmp/deploy/sdk in the form of a shell script (which is actually a tar file with a script wrapper as a preamble). running the script installs the sdk (interactively). Hope this helps. Thanks Sunil Mukundan On Tue, Oct 23, 2018 at 7:28 PM Dhanush K.S wrote: > > Hi Yocto, > > I am running Yocto 2.5 (Poky Sumo) on the host system CentOS 7.1 to build > images for the target system ARM cortexa8 with a Target_FPU configured to > hard. > > I would like to use a Cross Compiler SDK Toolchain in order to build the > images, as the current toolchain fails with a few recipes during compilation > due to missing include files. > > I tried building the toolchain using "bitbake meta-toolchain", but > unfortunately that failed as well at do_generate_content_debug. But also, as > far as I understand this command builds the SDK with compilers for the host > system and not for the target system. > > I would like to use a pre-built SDK, if one is available for ARM cortex A8 > architecture. I have looked all around and haven't found one. > > Could some Yocto Experts point me in the right direction? How can go about > finding a Cross Compiler Toolchain in order to overcome the compilation > errors. > > Thanks in advance for your help. > Regards, > > Mit freundlichen Grüßen / Best Regards, > Dhanush > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] eSDK installation failing with sig computed mismatch with sig locked
Hi Chen Qi
We got some help from the Yocto team and this seems to be a known issue.
Basically the recipe had these two lines below
SRCREV = "${AUTOREV}"
PV = "master+git${SRCPV}"
These lines force the eSDK to pull the latest code if there is a change in
the revision in the upstream git repo.
Looks like this is a known issue (
https://bugzilla.yoctoproject.org/show_bug.cgi?id=11350). We are looking at
using specific
revisions of the upstream repo to fix this.
Thanks for your help
Best
Sunil Mukundan
On Tue, Oct 23, 2018 at 8:58 AM Sunil Mukundan
wrote:
> Thanks Chen Qi for the response. Please find my response below
>
> >What does the SRC_URI for the recipe look like?
>
> SRC_URI = "git://github.com/luigirizzo/netmap.git"
>
> Thanks
> Sunil Mukundan
> On Tue, Oct 23, 2018 at 6:58 AM ChenQi wrote:
> >
> > I think the main problem is do_fetch sig mismatch.
> > What does the SRC_URI for the recipe look like?
> >
> > Best Regards,
> > Chen Qi
> >
> >
> > On 10/22/2018 08:47 PM, Sunil Mukundan wrote:
> > > Hi
> > >
> > > I built an extensible SDK and when installing the SDK, i see the
> > > following WARNINGS first
> > >
> > > WARNING: The netmap-modules:do_fetch sig is computed to be
> > > b53fa14a73271b9f0ce564e413f32468, but the sig is locked to
> > > 614da4fb9135f1f97b291ff05494f53c in SIGGEN_LOCKEDSIGS_t-genericx86-64
> > > The netmap:do_fetch sig is computed to be
> > > b53fa14a73271b9f0ce564e413f32468, but the sig is locked to
> > > 614da4fb9135f1f97b291ff05494f53c in SIGGEN_LOCKEDSIGS_t-genericx86-64
> > > The netmap:do_populate_lic sig is computed to be
> > > 45b8ffb273c02b2fcd201347e4137e19, but the sig is locked to
> > > d4c3de4ecfdc1d70a4129dfbcc68b71d in SIGGEN_LOCKEDSIGS_t-genericx86-64
> > > The netmap-modules:do_populate_lic sig is computed to be
> > > 45b8ffb273c02b2fcd201347e4137e19, but the sig is locked to
> > > d4c3de4ecfdc1d70a4129dfbcc68b71d in SIGGEN_LOCKEDSIGS_t-genericx86-64
> > >
> > > These WARNINGS then (probably) result in the following errors
> > > ERROR: Task netmap.do_prepare_recipe_sysroot attempted to execute
> unexpectedly
> > > ERROR: Task netmap.do_configure attempted to execute unexpectedly
> > > ERROR: Task netmap.do_compile attempted to execute unexpectedly
> > > ERROR: Task netmap.do_install attempted to execute unexpectedly
> > > ERROR: Task netmap.do_package attempted to execute unexpectedly and
> > > should have been setscened
> > > ERROR: Task netmap.do_packagedata attempted to execute unexpectedly
> > > and should have been setscened
> > > ERROR: Task netmap-modules.do_populate_lic attempted to execute
> > > unexpectedly and should have been setscened
> > > ERROR: Task netmap.do_populate_lic attempted to execute unexpectedly
> > > and should have been setscened
> > >
> > > Could someone help me with what could be going wrong?
> > >
> > > I used the usual 'bitbake -c populate_sdk_ext core-image-minimal'
> > > command to build the SDK.
> > >
> > > thanks,
> > > Sunil Mukundan
> >
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] help required to build 32-bit executable using yocto gcc
Hi, I am looking to use gcc built by yocto sdk with –m32 option. I changed MACHINE to genericx86-64 local.conf and also added these lines to be able to add multilib support with gcc. IMAGE_INSTALL_append = " glibc-staticdev" NO32LIBS = "0" require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "x86" But I get these these errors. I am using dizzy branch, a bit old but I believe this branch also support –m32 in gcc that it build internally. Gcc can generate 64 bit binaries but not 32-bit binaries. [dizzy@dizzy-centos7 core-minimal]$ x86_64-poky-linux-gcc -m32 -march=core2 -mtune=core2 -msse3 -mfpmath=sse --sysroot=/home/dizzy/poky/build/tmp/deploy/sdk/core-minimal/sysroots/core2-64-poky-linux ~/thread.c /home/dizzy/poky/build/tmp/deploy/sdk/core-minimal/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/4.9.1/ld: skipping incompatible /home/dizzy/poky/build/tmp/deploy/sdk/core-minimal/sysroots/core2-64-poky-linux/usr/lib64/x86_64-poky-linux/4.9.1/libgcc.a when searching for -lgcc /home/dizzy/poky/build/tmp/deploy/sdk/core-minimal/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/4.9.1/ld: cannot find -lgcc /home/dizzy/poky/build/tmp/deploy/sdk/core-minimal/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/4.9.1/ld: skipping incompatible /home/dizzy/poky/build/tmp/deploy/sdk/core-minimal/sysroots/core2-64-poky-linux/usr/lib64/libc.so when searching for -lc /home/dizzy/poky/build/tmp/deploy/sdk/core-minimal/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/4.9.1/ld: skipping incompatible /home/dizzy/poky/build/tmp/deploy/sdk/core-minimal/sysroots/core2-64-poky-linux/usr/lib64/libc.a when searching for -lc /home/dizzy/poky/build/tmp/deploy/sdk/core-minimal/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/4.9.1/ld: cannot find -lc /home/dizzy/poky/build/tmp/deploy/sdk/core-minimal/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/4.9.1/ld: skipping incompatible /home/dizzy/poky/build/tmp/deploy/sdk/core-minimal/sysroots/core2-64-poky-linux/usr/lib64/x86_64-poky-linux/4.9.1/libgcc.a when searching for -lgcc /home/dizzy/poky/build/tmp/deploy/sdk/core-minimal/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/4.9.1/ld: cannot find -lgcc /home/dizzy/poky/build/tmp/deploy/sdk/core-minimal/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/4.9.1/ld: skipping incompatible /home/dizzy/poky/build/tmp/deploy/sdk/core-minimal/sysroots/core2-64-poky-linux/lib64/libgcc_s.so when searching for -lgcc_s /home/dizzy/poky/build/tmp/deploy/sdk/core-minimal/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/4.9.1/ld: cannot find -lgcc_s collect2: error: ld returned 1 exit status [dizzy@dizzy-centos7 core-minimal]$ Thanks for your help in advance. Thanks Ram Regar -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
