Re: [yocto] [meta-mingw][sumo][PATCH 1/1] openssl: build for mingw
> Does this also work for rocko and master if the bbappend used a > wildcard? Or is it not required for rocko and master? Good question. I am inclined to think it should work. (I will test it). Juro -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-mingw][PATCH] qemu_2.11.%.bbappend: fix broken qemu build for mingw
yes, I've done it before: https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=sumo&id=bc112b8368eb3842ccb2430fdf17e736ea39a742 I'll do it gain. Hopefully it will last longer this time. From: Burton, Ross [ross.bur...@intel.com] Sent: Friday, April 13, 2018 5:50 AM To: Bystricky, Juro Cc: Yocto-mailing-list; Juro Bystricky; Alistair Francis Subject: Re: [yocto] [meta-mingw][PATCH] qemu_2.11.%.bbappend: fix broken qemu build for mingw Is it feasible to fix the original patch? Ross On 13 April 2018 at 00:55, Juro Bystricky wrote: > The commit "qemu: Bump to version 2.11.0" in oe-core broke the > build of qemu for mingw, due to using "socketpair", which is > not supported by mingw. "socketpair" is used in a local patch, > not in the qemu upstream code. The original local patch had > conditional code to exclude "socketpair" for _WIN32, but the > modified patch for qemu 2.11.0 removed this. > > The fix is to simply remove the offending patch. > > Signed-off-by: Juro Bystricky > --- > recipes-devtools/qemu/qemu_2.11.%.bbappend | 4 > 1 file changed, 4 insertions(+) > create mode 100644 recipes-devtools/qemu/qemu_2.11.%.bbappend > > diff --git a/recipes-devtools/qemu/qemu_2.11.%.bbappend > b/recipes-devtools/qemu/qemu_2.11.%.bbappend > new file mode 100644 > index 000..764b500 > --- /dev/null > +++ b/recipes-devtools/qemu/qemu_2.11.%.bbappend > @@ -0,0 +1,4 @@ > + > + > +SRC_URI_remove_mingw32 = > "file://chardev-connect-socket-to-a-spawned-command.patch" > + > -- > 2.7.4 > > -- > ___ > 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] QA cycle report for 2.2.2 rc2
I checked out 2.2_M3 2679a347c576f5411fbe802d2f6201c94036ecb2. The recipes for gzip and slang do not contain any ptest code, so that explains why the tests are missing. However, flex recipe has a code for ptest. So there is a bit of mystery left. From: akuster808 [akuster...@gmail.com] Sent: Friday, September 15, 2017 1:06 PM To: Bystricky, Juro; Cruz, Libertad; Richard Purdie; yocto@yoctoproject.org; Jolley, Stephen K; Zhang, Jessica Cc: Cruz Alcaraz, Juan M; Jordan, Robin L Subject: Re: [yocto] QA cycle report for 2.2.2 rc2 On 09/15/2017 01:01 PM, Bystricky, Juro wrote: > The commit is for 2.4 M3 (5f6945f5031e1a4ca116cc1eccf4c2f9dc228547) > 2.4 does contain the ptests for gzip, slang and flex. (Although there are > some other mysteries, like sed-ptest is missing) > It would seem that 2.2 had never contained (or lost a while ago) those ptests. Thanks for looking into this. Is there any action I need to follow up on? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] QA cycle report for 2.2.2 rc2
The commit is for 2.4 M3 (5f6945f5031e1a4ca116cc1eccf4c2f9dc228547) 2.4 does contain the ptests for gzip, slang and flex. (Although there are some other mysteries, like sed-ptest is missing) It would seem that 2.2 had never contained (or lost a while ago) those ptests. Juro From: Cruz, Libertad Sent: Friday, September 15, 2017 12:50 PM To: Bystricky, Juro; Richard Purdie; yocto@yoctoproject.org; Jolley, Stephen K; Zhang, Jessica Cc: Perez Carranza, Jose; Cruz Alcaraz, Juan M; Jordan, Robin L Subject: RE: QA cycle report for 2.2.2 rc2 Hello, Regarding 12080: this was a QA documentation error on the test steps, verified it again and changed the bug to not a bug, documented the correct steps for the QA. Regarding 12081: To open bugs on ptest we make a comparison from the last run in this case the comparison was made with 2.2.2 rc1 Ptest 5f6945f5031e1a4ca116cc1eccf4c2f9dc228547 which in turn was compared with Ptest 9ed748a542b520c1cb763d981969233c0f5efd4e which was compared with Ptest 8e15e9b6e478f6368034519b2a8fd3c7ea71d23b which was compared with Ptest 6bd890d9e011014cf323e61267f8b256949d44aa, they all hold this packages. Best Regards Libertad G. -Original Message- From: Bystricky, Juro Sent: Friday, September 15, 2017 1:04 PM To: Richard Purdie ; Cruz, Libertad ; yocto@yoctoproject.org; Jolley, Stephen K ; Zhang, Jessica Cc: Perez Carranza, Jose ; Cruz Alcaraz, Juan M ; Jordan, Robin L Subject: RE: QA cycle report for 2.2.2 rc2 Regarding 12081: Looking at some previous ptest results in: https://wiki.yoctoproject.org/wiki/QA_sanity_history we can see that the offending tests (gzip, flex, slang) were not present in: https://wiki.yoctoproject.org/wiki/Ptest_62d7d4130202d8ede16abf9e7d779361ca70847e but started to appear after https://wiki.yoctoproject.org/wiki/Ptest_6e20b31d5d17133e0fca086e12a0ad06ab5c4cc8 (flex) Also checking the manifest file, the offending test were also missing in http://downloads.yoctoproject.org/releases/yocto/yocto-2.2.1/machines/genericx86-64/core-image-sato-sdk-ptest-genericx86-64.manifest So this is not a regression issue. Juro From: Richard Purdie [richard.pur...@linuxfoundation.org] Sent: Friday, September 15, 2017 9:50 AM To: Cruz, Libertad; yocto@yoctoproject.org; Jolley, Stephen K; Zhang, Jessica; Bystricky, Juro Cc: Perez Carranza, Jose; Cruz Alcaraz, Juan M; Jordan, Robin L Subject: Re: QA cycle report for 2.2.2 rc2 This is a tricky one to evaluate. Going through the bugs in the QA report: Bug 12075 - think this is ok to fix on the branch and release note Bug 12080 - we think minimal eSDK never worked in morty therefore this is a QA testing error? Bug 12073 - we continue to see various gpg errors even with master, propose not to block release on this and only fix master Bug 12009 - resolved and already fixed in 2.2.2 (I marked it resolved) Bug 11150 - was a bug with 2.2.1 but should be fixed in 2.2.2? Bug 11611 - was this found in 2.2.2? Bug 11064 - marked as resolved as per QA comment, fix was in 2.2.2 Bug 11597 - fix was added to 2.2.2 (marked as resolved) Bug 10460 - open and unresolved with master but not release blocker IMO Bug 11797 - can't see any backport but not a release blocker as the source mirrors work Bug 11109 - No backport afaict but not release blocker Which leave us with 12081 to understand before we can decide whether to release this or not. So the decision to release or not depends on QA agreeing with the resolution of 12080 and figuring out what happened with 12081. [Thanks to Ross for helping with some of this] Cheers, Richard On Thu, 2017-09-14 at 16:53 -0700, Cruz, Libertad wrote: > Here is the report for the 2.2.2 point release test cycle. > Full Report : https://wiki.yoctoproject.org/wiki/WW37_-_2017-09-13_- > _Full_Point_Release_Test_Cycle_2.2.2_rc2 > === Summary > The QA cycle for point release 2.2.2 rc2 is complete. There are 3 new > bugs: bug 12080[2] blocks testing to the eSDK component since eSDK > functionalities cannot be executed. Bugs 12075[1], 12073[3], 12081[4] > don’t block full functionalities. > > LPT results are waiting to be updated by Windriver. > > Performance > Compared with 2.2.2 rc1 there was a regression of 14.71 while building > rootfs on Ubuntu, there was also a regression on Fedora while building > sato of 7.46% and a regression on kernel of 12.12%. > > > Ubuntu Test 2.2.2_rc1 > 2.2.2_rc2 % > sato 1:00:42 > 1:01:16 0.93 > rootfs2:16 > 2:36 14.71 > rmwork 0:59:29 0:59:51 > 0.62 > kernel5:01 > 5:00 -0.33 > eSDK 3:
Re: [yocto] QA cycle report for 2.2.2 rc2
Regarding 12081: Looking at some previous ptest results in: https://wiki.yoctoproject.org/wiki/QA_sanity_history we can see that the offending tests (gzip, flex, slang) were not present in: https://wiki.yoctoproject.org/wiki/Ptest_62d7d4130202d8ede16abf9e7d779361ca70847e but started to appear after https://wiki.yoctoproject.org/wiki/Ptest_6e20b31d5d17133e0fca086e12a0ad06ab5c4cc8 (flex) Also checking the manifest file, the offending test were also missing in http://downloads.yoctoproject.org/releases/yocto/yocto-2.2.1/machines/genericx86-64/core-image-sato-sdk-ptest-genericx86-64.manifest So this is not a regression issue. Juro From: Richard Purdie [richard.pur...@linuxfoundation.org] Sent: Friday, September 15, 2017 9:50 AM To: Cruz, Libertad; yocto@yoctoproject.org; Jolley, Stephen K; Zhang, Jessica; Bystricky, Juro Cc: Perez Carranza, Jose; Cruz Alcaraz, Juan M; Jordan, Robin L Subject: Re: QA cycle report for 2.2.2 rc2 This is a tricky one to evaluate. Going through the bugs in the QA report: Bug 12075 - think this is ok to fix on the branch and release note Bug 12080 - we think minimal eSDK never worked in morty therefore this is a QA testing error? Bug 12073 - we continue to see various gpg errors even with master, propose not to block release on this and only fix master Bug 12009 - resolved and already fixed in 2.2.2 (I marked it resolved) Bug 11150 - was a bug with 2.2.1 but should be fixed in 2.2.2? Bug 11611 - was this found in 2.2.2? Bug 11064 - marked as resolved as per QA comment, fix was in 2.2.2 Bug 11597 - fix was added to 2.2.2 (marked as resolved) Bug 10460 - open and unresolved with master but not release blocker IMO Bug 11797 - can't see any backport but not a release blocker as the source mirrors work Bug 11109 - No backport afaict but not release blocker Which leave us with 12081 to understand before we can decide whether to release this or not. So the decision to release or not depends on QA agreeing with the resolution of 12080 and figuring out what happened with 12081. [Thanks to Ross for helping with some of this] Cheers, Richard On Thu, 2017-09-14 at 16:53 -0700, Cruz, Libertad wrote: > Here is the report for the 2.2.2 point release test cycle. > Full Report : https://wiki.yoctoproject.org/wiki/WW37_-_2017-09-13_- > _Full_Point_Release_Test_Cycle_2.2.2_rc2 > === Summary > The QA cycle for point release 2.2.2 rc2 is complete. There are 3 > new bugs: bug 12080[2] blocks testing to the eSDK component since > eSDK functionalities cannot be executed. Bugs 12075[1], 12073[3], > 12081[4] don’t block full functionalities. > > LPT results are waiting to be updated by Windriver. > > Performance > Compared with 2.2.2 rc1 there was a regression of 14.71 while > building rootfs on Ubuntu, there was also a regression on Fedora > while building sato of 7.46% and a regression on kernel of 12.12%. > > > Ubuntu Test 2.2.2_rc1 > 2.2.2_rc2 % > sato 1:00:42 > 1:01:16 0.93 > rootfs2:16 > 2:36 14.71 > rmwork 0:59:29 0:59:51 > 0.62 > kernel5:01 > 5:00 -0.33 > eSDK 3:22 > 3:19 -1.49 > > > > > Fedora Test 2.2.2_rc1 > 2.2.2_rc2 % > sato 1:01:55 > 1:06:32 7.46 > rootfs2:49 > 2:51 1.18 > rmwork 0:59:52 1:01:32 > 2.78 > kernel6:03 > 6:47 12.12 > eSDK 3:44 > 3:54 4.46 > > > ptest > There was an improvement on the pass rate in the following packages > in comparison with 2.2.2 rc1: > gdk-pixbuf with 5% > libxml2 with 4.20% > lttng-tools with 3.20% > > On the other side there was a regression on the pass rate in > comparison with 2.2.2 rc1: > acl with 6.80% > e2fsprogs with 100% regression > gawk with .10% > quilt with 1.80% > valgrind of 53.10% > > > Compliance > Results are yet to be documented by Windriver. > > === QA-Hints > > There is only one concern on the eSDK component it cannot execute. QA > recommends an 2.2.2 rc3 to only verify the eSDK component. > > === Bugs > >New Bugs > -12075[1] [morty] testimage quemux86/qemux86-64 lsb > tcgetattr: Input/output error^M > -12080[2] [Morty][Test Case 1605] > TCTEMP_2.3_AUTO_sdkext_eSDK_devtool_build_mak
Re: [yocto] [meta-mingw] Morty branch?
The LTO patch is needed, see for example: https://lists.yoctoproject.org/pipermail/yocto/2016-October/032490.html The SDK builds without it just fine, but the error pops up while running under Windows Juro From: Mark Hatle [mark.ha...@windriver.com] Sent: Wednesday, January 25, 2017 10:46 AM To: Bystricky, Juro; Yocto Project Subject: Re: [meta-mingw] Morty branch? On 1/25/17 9:29 AM, Bystricky, Juro wrote: > Hello Mark, > the meta-mingw morty branch was created a few moments ago. > Please have a look. Great. This seems to be the stuff that was working for me. One comment if anyone else comes on this in the future. The LTO commit. It's not completely clearly to me if this is actually needed or if there is a problem somewhere else (binutils perhaps). At some point, someone with a bit more knowledge of mingw/windows and gcc/binutils probably should take a look at it -- if the LTO stuff is desired. --Mark > Thanks > > Juro > > >> -Original Message- >> From: Mark Hatle [mailto:mark.ha...@windriver.com] >> Sent: Wednesday, January 11, 2017 9:57 AM >> To: Yocto Project >> Cc: Bystricky, Juro >> Subject: [meta-mingw] Morty branch? >> >> I don't see any specific Morty branch available for meta-mingw. Also many >> of >> the patches that were in progress have not been integrated to the master >> branch >> either. >> >> I've posted the Wind River version of meta-mingw for use with Morty based >> products to: >> >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-mingw-contrib/ >> >> git://git.yoctoproject.org/meta-mingw-contrib >> >> The 'mgh/morty' branch. >> >> --Mark -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-mingw] Morty branch?
Hello Mark, the meta-mingw morty branch was created a few moments ago. Please have a look. Thanks Juro > -Original Message- > From: Mark Hatle [mailto:mark.ha...@windriver.com] > Sent: Wednesday, January 11, 2017 9:57 AM > To: Yocto Project > Cc: Bystricky, Juro > Subject: [meta-mingw] Morty branch? > > I don't see any specific Morty branch available for meta-mingw. Also many > of > the patches that were in progress have not been integrated to the master > branch > either. > > I've posted the Wind River version of meta-mingw for use with Morty based > products to: > > http://git.yoctoproject.org/cgit/cgit.cgi/meta-mingw-contrib/ > > git://git.yoctoproject.org/meta-mingw-contrib > > The 'mgh/morty' branch. > > --Mark -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-zephyr layer
Hello Josef, I will find a better place for the meta-zephyr repository eventually. As for your patches, I would definitely like to see them. I added the cortex-m3 tune as one of the last steps, just to get the Zephyr ARM test suite to pass. It works well, but probably not an optimal implementation. > -Original Message- > From: Josef Holzmayr [mailto:holzm...@rsi-elektrotechnik.de] > Sent: Tuesday, December 13, 2016 5:51 AM > To: yocto@yoctoproject.org; Bystricky, Juro > Subject: Re: [yocto] meta-zephyr layer > > Hello Juro, > > first off, thanks for taking the kick, whatever its count is. > > On 12.12.2016 23:15, Bystricky, Juro wrote: > > Building of Zephyr images in Yocto can now be done fairly unobtrusively > > via a new layer "meta-zephyr" and specifying a new distro in local.conf: > > DISTRO="zephyr" > > Leaving out the poky/non-poky discussion, zephyr.conf currently contains > an include for tune-cortexm3.conf which certainly should not be there, > as it is machine specific. My local fix here is to create a warped > version of qemuarm.conf named qemuarmm3.conf which fixes that. > > > > > The repository for the meta-zephyr is here: > > http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=juro/meta- > zephyr. > > > > The new meta-zephyr layer contains several recipes to build (and run > > in QEMUs) various Zephyr tests. There is also a sample recipe to build > > Zephyr sample "philosophers" with instructions how to run it in QEMU. > > The instructions seem to be missing that poky-contrib/meta is also > needed in the bblayers for the tune-cortexm3 include. > > > The new meta-zephyr is work based on previous original work by > > Randy Witt and Richard Purdie, so it is actually a second kick at the > can. > > Thanks to those too, of course. > > > > > This is a work in progress, any feedback is appreciated. > > Feedback was above - do you also want patches? ;-) > > Greetz > > -- > Josef Holzmayr > Software Developer Embedded Systems > > Tel: +49 8444 9204-48 > Fax: +49 8444 9204-50 > > R-S-I Elektrotechnik GmbH & Co. KG > Woelkestrasse 11 > D-85301 Schweitenkirchen > www.rsi-elektrotechnik.de > --- > Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170393 > Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg > Ust-IdNr: DE 128592548 > > _ > Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 > Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg > USt-IdNr.: DE 128592548 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-zephyr layer
Thanks, good point. The need for is poky.conf historic, not really needed at all anymore. From: Burton, Ross [mailto:ross.bur...@intel.com] Sent: Monday, December 12, 2016 4:00 PM To: Bystricky, Juro Cc: Philip Balister ; yocto@yoctoproject.org Subject: Re: [yocto] meta-zephyr layer On 12 December 2016 at 22:52, Bystricky, Juro mailto:juro.bystri...@intel.com>> wrote: you need poky to build QEMUs and toolchains You should just need *OpenEmbedded* to build the qemus and toolchains. Why does zephyr.conf include poky.conf? I'd say that any variables that are useful - such as using the Yocto source mirrors - should just be copied into zephyr.conf (or even better, moved into oe-core). Ross Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-zephyr layer
you need poky to build QEMUs and toolchains > -Original Message- > From: Philip Balister [mailto:phi...@balister.org] > Sent: Monday, December 12, 2016 2:19 PM > To: Bystricky, Juro ; yocto@yoctoproject.org > Subject: Re: [yocto] meta-zephyr layer > > Does that work without poky? > > Philip > > On 12/12/2016 02:15 PM, Bystricky, Juro wrote: > > There is interest in the community to support building Zephyr images > > ( https://www.zephyrproject.org/ )in Yocto via bitbake recipes. > > AFAIK the only way thus far to build Zephyr images is based on command > > line/Kconfig, similar to building Linux kernel images. > > > > Building of Zephyr images in Yocto can now be done fairly unobtrusively > > via a new layer "meta-zephyr" and specifying a new distro in local.conf: > > DISTRO="zephyr" > > > > The repository for the meta-zephyr is here: > > http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=juro/meta- > zephyr. > > > > The new meta-zephyr layer contains several recipes to build (and run > > in QEMUs) various Zephyr tests. There is also a sample recipe to build > > Zephyr sample "philosophers" with instructions how to run it in QEMU. > > > > This is the first kick at the can. > > At present, only x86 and ARM CortexM3 toolchains are supported, with > > more coming eventually. (Zephyr also supports BSPs for ARC, Nios2, IAMCU, > > and Xtensa and RISC-V coming in the next release) > > > > The new meta-zephyr is work based on previous original work by > > Randy Witt and Richard Purdie, so it is actually a second kick at the > can. > > > > This is a work in progress, any feedback is appreciated. > > > > Juro > > > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] meta-zephyr layer
There is interest in the community to support building Zephyr images ( https://www.zephyrproject.org/ )in Yocto via bitbake recipes. AFAIK the only way thus far to build Zephyr images is based on command line/Kconfig, similar to building Linux kernel images. Building of Zephyr images in Yocto can now be done fairly unobtrusively via a new layer "meta-zephyr" and specifying a new distro in local.conf: DISTRO="zephyr" The repository for the meta-zephyr is here: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=juro/meta-zephyr. The new meta-zephyr layer contains several recipes to build (and run in QEMUs) various Zephyr tests. There is also a sample recipe to build Zephyr sample "philosophers" with instructions how to run it in QEMU. This is the first kick at the can. At present, only x86 and ARM CortexM3 toolchains are supported, with more coming eventually. (Zephyr also supports BSPs for ARC, Nios2, IAMCU, and Xtensa and RISC-V coming in the next release) The new meta-zephyr is work based on previous original work by Randy Witt and Richard Purdie, so it is actually a second kick at the can. This is a work in progress, any feedback is appreciated. Juro -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-mingw
Most likely the error is caused by the change from TARGET_ARCH -> SDK_SYS Try this: https://lists.yoctoproject.org/pipermail/yocto/2016-October/032306.html > -Original Message- > From: Mark Hatle [mailto:mark.ha...@windriver.com] > Sent: Tuesday, November 1, 2016 3:41 PM > To: Yocto Project > Cc: Bystricky, Juro > Subject: meta-mingw > > I was trying to build meta-mingw (master) with oe-core (morty). I'm > getting a > failure: > > | ERROR: Function failed: do_configure (log file is located at > .../nativesdk-mingw-w64-runtime/3.1.0-r0/temp/log.do_configure.208815) > ERROR: Task > (/.../oe-core/meta-mingw/recipes-devtools/mingw-w64/nativesdk-mingw-w64- > runtime_3.1.0.bb:do_configure) > failed with exit code '1' > > The more detailed log shows that it was unable to find the compiler. > > Any suggestions from anyone? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-mingw
I sent a set of patches a while ago for meta-mingw/master branch. "krogoth" and "morty/master" need separate branches. "krogoth" branch exists, but I think morty branch needs to be created yet. > -Original Message- > From: Mark Hatle [mailto:mark.ha...@windriver.com] > Sent: Tuesday, November 1, 2016 3:41 PM > To: Yocto Project > Cc: Bystricky, Juro > Subject: meta-mingw > > I was trying to build meta-mingw (master) with oe-core (morty). I'm > getting a > failure: > > | ERROR: Function failed: do_configure (log file is located at > .../nativesdk-mingw-w64-runtime/3.1.0-r0/temp/log.do_configure.208815) > ERROR: Task > (/.../oe-core/meta-mingw/recipes-devtools/mingw-w64/nativesdk-mingw-w64- > runtime_3.1.0.bb:do_configure) > failed with exit code '1' > > The more detailed log shows that it was unable to find the compiler. > > Any suggestions from anyone? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-mingw] Patch needed to let linker find lto plugin
Thanks. I will re-run some basic tests again and
send the patch by Mark Hatle (applied to meta-mingw/krogoth) to the mailing
list.
> -Original Message-
> From: winfried.do...@xmsnet.nl [mailto:winfried.do...@xmsnet.nl]
> Sent: Friday, October 14, 2016 11:35 AM
> To: Bystricky, Juro ; yocto@yoctoproject.org
> Cc: Hatle, Mark G (Wind River)
> Subject: RE: [meta-mingw] Patch needed to let linker find lto plugin
>
> Hi Juro,
>
> My Yocto environment is for the Congatec QMX6 SoM that is built around a
> quadcore i.MX6.
> I use the Yocto layers from the Congatec repository
> (https://git.congatec.com/public), which includes the meta-fsl-arm and
> meta-fsl-arm-extra layers.
>
> My bblayers.conf is:
>
> BBLAYERS = " \
>${BSPDIR}/sources/poky/meta \
>${BSPDIR}/sources/poky/meta-poky \
>\
>${BSPDIR}/sources/meta-openembedded/meta-oe \
>${BSPDIR}/sources/meta-openembedded/meta-multimedia \
>${BSPDIR}/sources/meta-openembedded/meta-python \
>${BSPDIR}/sources/meta-openembedded/meta-networking \
>\
>${BSPDIR}/sources/meta-fsl-arm \
>${BSPDIR}/sources/meta-fsl-arm-extra \
>${BSPDIR}/sources/meta-fsl-demos \
>\
>${BSPDIR}/sources/meta-mingw \
>\
>${BSPDIR}/sources/meta-peek \
>${BSPDIR}/sources/meta-peek-ecng \
> "
>
> The image I normally build (peek-image-ecng-acu-default) is based upon
> the core-image-full-cmdline image.
>
> I built the MinGW SDK by adding SDKMACHINE="x86_64-mingw32" to my
> local.conf and typing the command "bitbake peek-image-ecng-acu-default
> -c populate_sdk".
>
> I attended the Yocto developer day in Berlin last week. When I showed
> the MinGW linker LTO plugin error to Mark Hatle, he suggested applying
> his patch.
>
> best regards,
>
> Winfried
>
>
> Bystricky, Juro schreef op 14.10.2016 20:04:
> > Could you please elaborate on what do you mean by "built it as-is".
> > I tested the meta layer with some cases I considered typical
> > or most common. (I think I enumerated them in my original
> > message). Apparently I missed one.
> >
> > Thanks
> >
> > Juro
> >
> >
> >> -Original Message-
> >> From: Winfried [mailto:winfried_...@xmsnet.nl]
> >> Sent: Friday, October 14, 2016 10:26 AM
> >> To: yocto@yoctoproject.org
> >> Cc: Bystricky, Juro
> >> Subject: [meta-mingw] Patch needed to let linker find lto plugin
> >>
> >> Recently the meta-mingw layer was updated to krogoth by Juro
> >> Bystricky.
> >> Thanks !
> >> However when I build it as-is, the linker fails because it can't load
> >> the lto plugin.
> >>
> >> After applying commit a06e473590207f72b11d273a09de2c8a889c381e from
> >> meta-mingw-contrib (by Mark Hatle), the error disappeared.
> >>
> >> See:
> >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-mingw-
> >> contrib/commit/?h=mgh/jetho/meta-
> >> mingw&id=a06e473590207f72b11d273a09de2c8a889c381e
> >>
> >> regards,
> >> W. Dobbe
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-mingw] Patch needed to let linker find lto plugin
Could you please elaborate on what do you mean by "built it as-is". I tested the meta layer with some cases I considered typical or most common. (I think I enumerated them in my original message). Apparently I missed one. Thanks Juro > -Original Message- > From: Winfried [mailto:winfried_...@xmsnet.nl] > Sent: Friday, October 14, 2016 10:26 AM > To: yocto@yoctoproject.org > Cc: Bystricky, Juro > Subject: [meta-mingw] Patch needed to let linker find lto plugin > > Recently the meta-mingw layer was updated to krogoth by Juro Bystricky. > Thanks ! > However when I build it as-is, the linker fails because it can't load > the lto plugin. > > After applying commit a06e473590207f72b11d273a09de2c8a889c381e from > meta-mingw-contrib (by Mark Hatle), the error disappeared. > > See: > http://git.yoctoproject.org/cgit/cgit.cgi/meta-mingw- > contrib/commit/?h=mgh/jetho/meta- > mingw&id=a06e473590207f72b11d273a09de2c8a889c381e > > regards, > W. Dobbe -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Cortex-M4 build support
You can also have a look at the Zephyr project https://www.zephyrproject.org/ Zephyr Project is a small, scalable real-time operating system for use on resource-constrained systems supporting multiple architectures. It does come with Cortex m0,m1,m2,m3,m4 baremetal Yocto based toolchain. https://gerrit.zephyrproject.org/r/p/meta-zephyr-sdk.git > -Original Message- > From: yocto-boun...@yoctoproject.org [mailto:yocto- > boun...@yoctoproject.org] On Behalf Of Zhenhua Luo > Sent: Tuesday, September 20, 2016 7:39 AM > To: Trevor Woerner ; Khem Raj > Cc: robert.berger@gmane ; > yocto@yoctoproject.org; yocto-EtnWKYl6rD/WsZ/bqmp...@public.gmane.org > > Subject: Re: [yocto] Cortex-M4 build support > > Thank you so much for your suggestion, Trevor. > > > Best Regards, > > Zhenhua > > > -Original Message- > > From: yocto-boun...@yoctoproject.org [mailto:yocto- > > boun...@yoctoproject.org] On Behalf Of Trevor Woerner > > Sent: Friday, September 16, 2016 4:07 AM > > To: Khem Raj > > Cc: robert.berger@gmane ; > > yocto@yoctoproject.org; yocto- > > EtnWKYl6rD/WsZ/bqmp...@public.gmane.org > EtnWKYl6rD/WsZ/bqmp...@plane.gmane.org> > > Subject: Re: [yocto] Cortex-M4 build support > > > > On Tue 2016-09-13 @ 01:15:49 PM, Khem Raj wrote: > > > > > > > On Sep 13, 2016, at 10:31 AM, robert.berger@gmane > > wrote: > > > > > > > > Hi, > > > > > > > > Shouldn't it be possible to build a bare-metal Cortex-M4 compiler > with the YP > > and build a small RTOS like FreeRTOS with this compiler? > > > > > > > > > > yes it should be possible. you can also look into meta-ti where I > > > think they try to have their DSP toolchain build some code using OE > > > recipe model > > > > Perhaps other things to consider (I'm not entirely sure if these apply, > but maybe > > worth investigating?) > > > > The ROS project has a meta layer: > > https://layers.openembedded.org/layerindex/branch/master/layer/meta-ros/ > > > > If your CortexM board has enough RAM (e.g. http://www.emcraft.com/) you > > can run (a version of) Linux (uClinux) right on your CortexM target: > > https://github.com/EmcraftSystems/linux-emcraft > > > > The Emcraft website appears to provide Linux support for NXP-based > CortexM > > boards too: http://www.emcraft.com/products/456 > > http://www.emcraft.com/products/88 > > -- > > ___ > > 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 mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] baremetal cross-compiler
sorry for the late reply, somehow this mail fell through the cracks. Indeed, setting TCLIBC="baremetal" is all you should need to do. FWIW, I use these values in my local.conf: MACHINE = "qemuarm" TCLIBC = "baremetal" TUNE_FEATURES = "armv7m cortexm3" PACKAGE_CLASSES = "package_ipk" bitbake meta-toolchain Juro > -Original Message- > From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] > Sent: Wednesday, July 6, 2016 8:33 PM > To: Robert Berger > Cc: yocto@yoctoproject.org; Bystricky, Juro > Subject: Re: [yocto] baremetal cross-compiler > > Hi Robert, > > On Tue, 05 Jul 2016 12:02:11 Robert Berger wrote: > > According to the release notes it should be possible to build a > > baremetal (no glibc/Linux) cross compiler with the YP. I just can't find > > any information how this could be done. > > > > I would like to build a native compiler e.g. for a Cortex-A3 and compile > > FreeRTOS with it. > > It looks like all you should need to do would be to set TCLIBC = > "baremetal" > and build the toolchain. Juro, is there any more to it than that? > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PSPLASH 0/2] Few fixes for psplash
Thanks. I’ll mark the bug 7236 as resolved/fixed. Juro From: Burton, Ross [mailto:ross.bur...@intel.com] Sent: Tuesday, November 24, 2015 8:58 AM To: Bystricky, Juro Cc: yocto@yoctoproject.org; Juro Bystricky Subject: Re: [yocto] [PSPLASH 0/2] Few fixes for psplash On 24 November 2015 at 16:39, Juro Bystricky mailto:juro.bystri...@intel.com>> wrote: These patches fix https://bugzilla.yoctoproject.org/show_bug.cgi?id=7236 Considering there was a bug in the BGR888 detection, it is probaly safe to assume it was never used. I modified handling of 24BPP modes somewhat as well, but did not test it. 24BPP changes only affect big endian mode, little endian should be the same as before. (If you are aware of anybody actually using 24BPP modes, please let me know) Tested with jethro/core-image-sato (qemuppc, qemumips, qemuarm). Thanks Juro. Merged to psplash master. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] PSPLASH PPC Colors
This is a known bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=7236 Juro > -Original Message- > From: yocto-boun...@yoctoproject.org [mailto:yocto- > boun...@yoctoproject.org] On Behalf Of Smith, Daniel W > Sent: Tuesday, September 29, 2015 1:57 PM > To: Gary Thomas; yocto@yoctoproject.org > Subject: Re: [yocto] PSPLASH PPC Colors > > > > Does this happen on qemuppc or only on real hardware? > > I have only tried it on qemuppc & qemuarm at this point. The colors are all > correct once busybox is running, so I suspect it is an edianness issue with > images generated on a PC and then installed on a PPC. > > -Daniel Smith > > > > This message and any enclosures are intended only for the addressee. > Please notify the sender by email if you are not the intended recipient. If > you are not the intended recipient, you may not use, copy, disclose, or > distribute this message or its contents or enclosures to any other person and > any such actions may be unlawful. Ball reserves the right to monitor and > review all messages and enclosures sent to or from this email address. > -- > ___ > 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] [meta-darwin][PATCH] osx-runtime: OSX Yosemite v10.10
yes, I ran into the same libgcc problem, I plan on tackling it eventually. Likely some paths are not set correctly. For what is worth, try to build the SDK against the poky "dizzy" branch. I was able to build Darwin SDK with it. You may need to patch some other files though. Anyway, there is new repo https://git.yoctoproject.org/cgit/cgit.cgi/meta-darwin-contrib/ where I will place some Darwin patches, most notably those I used to build the "dizzy" SDK (later next week). > -Original Message- > From: Trevor Woerner [mailto:twoer...@gmail.com] > Sent: Wednesday, August 12, 2015 11:22 AM > To: Bystricky, Juro; yocto@yoctoproject.org > Cc: richard.pur...@linuxfoundation.org > Subject: Re: [meta-darwin][PATCH] osx-runtime: OSX Yosemite v10.10 > > On 08/11/15 17:48, Juro Bystricky wrote: > > Set of patches to allow building against OSX Yosemite v10.10 runtime. > > Excellent! My build failed, then I noticed your patches. > > Even with this patch applied, however, my build fails with native-libffi in > do_patch. It appears the existing "darwinfix.patch" no longer applies. I > updated the patch so libffi can now do_patch successfully, but I don't know if > it builds since gcc-crosssdk-i386 fails in do_compile. > > | > /z/layerindex/firefly/tmp/work/i386-linux/gcc-crosssdk-i386/4.9.3-r0/gcc- > 4.9.3/build.x86_64-linux.i386-pokysdk-darwin/./gcc/xgcc > -B/z/layerindex/firefly/tmp/work/i386-linux/gcc-crosssdk-i386/4.9.3-r0/gcc- > 4.9.3/build.x86_64-linux.i386-pokysdk-darwin/./gcc/ > -B/z/layerindex/firefly/tmp/sysroots/x86_64-linux/usr/i386-pokysdk- > darwin/bin/ > -B/z/layerindex/firefly/tmp/sysroots/x86_64-linux/usr/i386-pokysdk- > darwin/lib/ > -isystem > /z/layerindex/firefly/tmp/sysroots/x86_64-linux/usr/i386-pokysdk- > darwin/include > -isystem > /z/layerindex/firefly/tmp/sysroots/x86_64-linux/usr/i386-pokysdk- > darwin/sys-include > --sysroot=/z/layerindex/firefly/tmp/sysroots/i386-nativesdk-darwin- > pokysdk-darwin > -O2 -g -Os -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno- > narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes > -Wmissing-prototypes -Wold-style-definition -isystem ./include -pipe > -fno-common -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector - > dynamiclib -nodefaultlibs -install_name > /z/layerindex/firefly/tmp/sysroots/x86_64-linux/usr/i386-pokysdk- > darwin/lib/libgcc_s.1.dylib > -single_module -o ./libgcc_s.dylib -Wl,-exported_symbols_list,libgcc.map > -compatibility_version 1 -current_version 1.0 -g -Os -B./ _muldi3_s.o > _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o > _ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o > _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o > _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o > _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o > _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o > _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o > _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o > _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o > _clrsbdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o > _fixdfdi_s.o _fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o > _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o > _floatundixf_s.o _fixsfti_s.o _fixdfti_s.o _fixxfti_s.o _fixtfti_s.o > _fixunssfti_s.o _fixunsdfti_s.o _fixunsxfti_s.o _fixunstfti_s.o _floattisf_s.o > _floattidf_s.o _floattixf_s.o _floattitf_s.o _floatuntisf_s.o _floatuntidf_s.o > _floatuntixf_s.o _floatuntitf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o > _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o darwin-64_s.o > cpuinfo_s.o tf-signs_s.o sfp-exceptions_s.o addtf3_s.o divtf3_s.o eqtf2_s.o > getf2_s.o letf2_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o > fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o > floatditf_s.o floatunditf_s.o extendsftf2_s.o extenddftf2_s.o > extendxftf2_s.o trunctfsf2_s.o trunctfdf2_s.o trunctfxf2_s.o enable- > execute-stack_s.o unwind-dw2_s.o unwind-dw2-fde-darwin_s.o unwind- > sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lc > | ld: library not found for -ldylib1.o > > It's strange that it says "library not found for -ldylib1.o" because that > library is > in my sdk's sysroot: > > $ find . -name "*dylib1*" -print > ./tmp/sysroots/i386-nativesdk-darwin-pokysdk-darwin/usr/lib/dylib1.o > ./tmp/sysroots/i386-nativesdk-darwin-pokysdk-darwin/usr/lib/dylib1.10.5.o > ./tmp/sysroots/i386-nativesdk-darwin-pokysdk-darwin/usr/lib/lazydylib1.o > > > Have you had any su
