* [RFT] GCC 8.1 @ 2018-05-05 0:26 Khem Raj 2018-05-05 7:31 ` Zoran Stojsavljevic ` (3 more replies) 0 siblings, 4 replies; 74+ messages in thread From: Khem Raj @ 2018-05-05 0:26 UTC (permalink / raw) To: Patches and discussions about the oe-core layer, openembeded-devel, Yocto Project Hi All As you might have noticed that gcc 8.1 was released this week, I am calling out for some testing help on testing branch so we can weed out issues you might see in your setups. so if you have your builders idling over weekend, then you know what they can do this weekend :) Highlighted changes are https://gcc.gnu.org/gcc-8/changes.html and porting doc is https://gcc.gnu.org/gcc-8/porting_to.html The branch is here http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8 Its uptodate on top of current master oe-core May fourth be with you !! Cheers! -Khem ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFT] GCC 8.1 2018-05-05 0:26 [RFT] GCC 8.1 Khem Raj @ 2018-05-05 7:31 ` Zoran Stojsavljevic 2018-05-10 19:21 ` [yocto] " Khem Raj 2018-05-09 9:38 ` Martin Jansa ` (2 subsequent siblings) 3 siblings, 1 reply; 74+ messages in thread From: Zoran Stojsavljevic @ 2018-05-05 7:31 UTC (permalink / raw) To: Khem Raj Cc: Yocto Project, openembeded-devel, Patches and discussions about the oe-core layer > May fourth be with you !! @off topic! Who is here (and in wider context) Darth Vader? Bourne Kingpin (BK)? ;-) Zoran _______ On Sat, May 5, 2018 at 2:26 AM, Khem Raj <raj.khem@gmail.com> wrote: > Hi All > > As you might have noticed that gcc 8.1 was released this week, I am > calling out for some testing help on testing branch so we can weed out > issues you might see in your setups. so if you have your > builders idling over weekend, then you know what they can do this weekend :) > > Highlighted changes are > > https://gcc.gnu.org/gcc-8/changes.html > > and porting doc is > > https://gcc.gnu.org/gcc-8/porting_to.html > > The branch is here > > http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8 > > Its uptodate on top of current master oe-core > > May fourth be with you !! > > Cheers! > > -Khem > -- > _______________________________________________ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFT] GCC 8.1 2018-05-05 7:31 ` Zoran Stojsavljevic @ 2018-05-10 19:21 ` Khem Raj 0 siblings, 0 replies; 74+ messages in thread From: Khem Raj @ 2018-05-10 19:21 UTC (permalink / raw) To: Zoran Stojsavljevic Cc: Yocto Project, openembeded-devel, Patches and discussions about the oe-core layer On 5/5/18 12:31 AM, Zoran Stojsavljevic wrote: >> May fourth be with you !! > > @off topic! > > Who is here (and in wider context) Darth Vader? Bourne Kingpin (BK)? ;-) Well the message was sent on "may 4th" hence it was meant to be a light-hearted encouragement to test the patchset > > Zoran > _______ > > On Sat, May 5, 2018 at 2:26 AM, Khem Raj <raj.khem@gmail.com> wrote: >> Hi All >> >> As you might have noticed that gcc 8.1 was released this week, I am >> calling out for some testing help on testing branch so we can weed out >> issues you might see in your setups. so if you have your >> builders idling over weekend, then you know what they can do this weekend :) >> >> Highlighted changes are >> >> https://gcc.gnu.org/gcc-8/changes.html >> >> and porting doc is >> >> https://gcc.gnu.org/gcc-8/porting_to.html >> >> The branch is here >> >> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8 >> >> Its uptodate on top of current master oe-core >> >> May fourth be with you !! >> >> Cheers! >> >> -Khem >> -- >> _______________________________________________ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [yocto] [RFT] GCC 8.1 @ 2018-05-10 19:21 ` Khem Raj 0 siblings, 0 replies; 74+ messages in thread From: Khem Raj @ 2018-05-10 19:21 UTC (permalink / raw) To: Zoran Stojsavljevic Cc: Yocto Project, openembeded-devel, Patches and discussions about the oe-core layer On 5/5/18 12:31 AM, Zoran Stojsavljevic wrote: >> May fourth be with you !! > > @off topic! > > Who is here (and in wider context) Darth Vader? Bourne Kingpin (BK)? ;-) Well the message was sent on "may 4th" hence it was meant to be a light-hearted encouragement to test the patchset > > Zoran > _______ > > On Sat, May 5, 2018 at 2:26 AM, Khem Raj <raj.khem@gmail.com> wrote: >> Hi All >> >> As you might have noticed that gcc 8.1 was released this week, I am >> calling out for some testing help on testing branch so we can weed out >> issues you might see in your setups. so if you have your >> builders idling over weekend, then you know what they can do this weekend :) >> >> Highlighted changes are >> >> https://gcc.gnu.org/gcc-8/changes.html >> >> and porting doc is >> >> https://gcc.gnu.org/gcc-8/porting_to.html >> >> The branch is here >> >> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8 >> >> Its uptodate on top of current master oe-core >> >> May fourth be with you !! >> >> Cheers! >> >> -Khem >> -- >> _______________________________________________ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [OE-core] [RFT] GCC 8.1 2018-05-05 0:26 [RFT] GCC 8.1 Khem Raj 2018-05-05 7:31 ` Zoran Stojsavljevic @ 2018-05-09 9:38 ` Martin Jansa 2018-05-10 14:34 ` Dan McGregor 2018-05-11 22:05 ` Burton, Ross 3 siblings, 0 replies; 74+ messages in thread From: Martin Jansa @ 2018-05-09 9:38 UTC (permalink / raw) To: Khem Raj Cc: Yocto Project, openembeded-devel, Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 3791 bytes --] My initial tests show couple issues, but usually caused by other changes in that branch, not the gcc-8 itself. 1) strace-4.22 from http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654 fails to build with ptest enabled (it builds with 4.20 version if I revert this change) ../../strace-4.22/tests/inject-nf.c: In function 'main': ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in asm here } ^ Makefile:6313: recipe for target 'inject-nf.o' failed make: *** [inject-nf.o] Error 1 make: Leaving directory 'strace/4.22-r0/build/tests' 2) glibc with obsolete rpc disabled from: http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=0cd820424d4bdb5cc68e7503e09a0359fd21150a causes busybox's mount applet to fail building: util-linux/mount.c:252:11: fatal error: rpc/rpc.h: No such file or directory # include <rpc/rpc.h> ^~~~~~~~~~~ compilation terminated. make[1]: *** [util-linux/mount.o] Error 1 make: *** [util-linux] Error 2 3) grub and grub-efi fails to build with gcc8: In file included from ../grub-2.02/grub-core/partmap/gpt.c:26: ../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of 'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned] } GRUB_PACKED; ^ In file included from ../grub-2.02/grub-core/disk/ldm.c:26: ../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of 'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned] } GRUB_PACKED; ^ .. ../grub-2.02/grub-core/fs/btrfs.c:186:1: error: alignment 1 of 'struct grub_btrfs_inode' is less than 4 [-Werror=packed-not-aligned] } GRUB_PACKED; ^ 4) iotivity fails to build with gcc8: service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp: In lambda function: service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp:164:30: error: 'value' is not captured ocRep[KEY] = value; ^~~~~ 5) nativesdk-libxcrypt fails to build (not sure which change caused this, it build OK with sumo since the -std=gnu99 addition. ../git/crypt-sunmd5.c:189:13: error: 'snprintf' output may be truncated before the last format character [-Werror=format-truncation=] "$" CRYPT_ALGNAME "," ROUNDS "%u$%s$", ^~~ 6) couple internal components which usually fail to build with gcc8, because of more strict warnings + Werror. I didn't get very far in testing, because our old kernel fails to build with gcc8 and there are some other issues caused by other master changes. But it doesn't look too bad (in my small test, lets see what bitbake world will show), thanks a lot for new gcc. Cheers, On Sat, May 5, 2018 at 2:26 AM, Khem Raj <raj.khem@gmail.com> wrote: > Hi All > > As you might have noticed that gcc 8.1 was released this week, I am > calling out for some testing help on testing branch so we can weed out > issues you might see in your setups. so if you have your > builders idling over weekend, then you know what they can do this weekend > :) > > Highlighted changes are > > https://gcc.gnu.org/gcc-8/changes.html > > and porting doc is > > https://gcc.gnu.org/gcc-8/porting_to.html > > The branch is here > > http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8 > > Its uptodate on top of current master oe-core > > May fourth be with you !! > > Cheers! > > -Khem > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > [-- Attachment #2: Type: text/html, Size: 11610 bytes --] ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [OE-core] [RFT] GCC 8.1 @ 2018-05-09 9:38 ` Martin Jansa 0 siblings, 0 replies; 74+ messages in thread From: Martin Jansa @ 2018-05-09 9:38 UTC (permalink / raw) To: Khem Raj Cc: Yocto Project, openembeded-devel, Patches and discussions about the oe-core layer My initial tests show couple issues, but usually caused by other changes in that branch, not the gcc-8 itself. 1) strace-4.22 from http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654 fails to build with ptest enabled (it builds with 4.20 version if I revert this change) ../../strace-4.22/tests/inject-nf.c: In function 'main': ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in asm here } ^ Makefile:6313: recipe for target 'inject-nf.o' failed make: *** [inject-nf.o] Error 1 make: Leaving directory 'strace/4.22-r0/build/tests' 2) glibc with obsolete rpc disabled from: http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=0cd820424d4bdb5cc68e7503e09a0359fd21150a causes busybox's mount applet to fail building: util-linux/mount.c:252:11: fatal error: rpc/rpc.h: No such file or directory # include <rpc/rpc.h> ^~~~~~~~~~~ compilation terminated. make[1]: *** [util-linux/mount.o] Error 1 make: *** [util-linux] Error 2 3) grub and grub-efi fails to build with gcc8: In file included from ../grub-2.02/grub-core/partmap/gpt.c:26: ../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of 'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned] } GRUB_PACKED; ^ In file included from ../grub-2.02/grub-core/disk/ldm.c:26: ../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of 'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned] } GRUB_PACKED; ^ .. ../grub-2.02/grub-core/fs/btrfs.c:186:1: error: alignment 1 of 'struct grub_btrfs_inode' is less than 4 [-Werror=packed-not-aligned] } GRUB_PACKED; ^ 4) iotivity fails to build with gcc8: service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp: In lambda function: service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp:164:30: error: 'value' is not captured ocRep[KEY] = value; ^~~~~ 5) nativesdk-libxcrypt fails to build (not sure which change caused this, it build OK with sumo since the -std=gnu99 addition. ../git/crypt-sunmd5.c:189:13: error: 'snprintf' output may be truncated before the last format character [-Werror=format-truncation=] "$" CRYPT_ALGNAME "," ROUNDS "%u$%s$", ^~~ 6) couple internal components which usually fail to build with gcc8, because of more strict warnings + Werror. I didn't get very far in testing, because our old kernel fails to build with gcc8 and there are some other issues caused by other master changes. But it doesn't look too bad (in my small test, lets see what bitbake world will show), thanks a lot for new gcc. Cheers, On Sat, May 5, 2018 at 2:26 AM, Khem Raj <raj.khem@gmail.com> wrote: > Hi All > > As you might have noticed that gcc 8.1 was released this week, I am > calling out for some testing help on testing branch so we can weed out > issues you might see in your setups. so if you have your > builders idling over weekend, then you know what they can do this weekend > :) > > Highlighted changes are > > https://gcc.gnu.org/gcc-8/changes.html > > and porting doc is > > https://gcc.gnu.org/gcc-8/porting_to.html > > The branch is here > > http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8 > > Its uptodate on top of current master oe-core > > May fourth be with you !! > > Cheers! > > -Khem > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFT] GCC 8.1 @ 2018-05-09 9:38 ` Martin Jansa 0 siblings, 0 replies; 74+ messages in thread From: Martin Jansa @ 2018-05-09 9:38 UTC (permalink / raw) To: Khem Raj Cc: Yocto Project, openembeded-devel, Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 3791 bytes --] My initial tests show couple issues, but usually caused by other changes in that branch, not the gcc-8 itself. 1) strace-4.22 from http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654 fails to build with ptest enabled (it builds with 4.20 version if I revert this change) ../../strace-4.22/tests/inject-nf.c: In function 'main': ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in asm here } ^ Makefile:6313: recipe for target 'inject-nf.o' failed make: *** [inject-nf.o] Error 1 make: Leaving directory 'strace/4.22-r0/build/tests' 2) glibc with obsolete rpc disabled from: http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=0cd820424d4bdb5cc68e7503e09a0359fd21150a causes busybox's mount applet to fail building: util-linux/mount.c:252:11: fatal error: rpc/rpc.h: No such file or directory # include <rpc/rpc.h> ^~~~~~~~~~~ compilation terminated. make[1]: *** [util-linux/mount.o] Error 1 make: *** [util-linux] Error 2 3) grub and grub-efi fails to build with gcc8: In file included from ../grub-2.02/grub-core/partmap/gpt.c:26: ../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of 'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned] } GRUB_PACKED; ^ In file included from ../grub-2.02/grub-core/disk/ldm.c:26: ../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of 'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned] } GRUB_PACKED; ^ .. ../grub-2.02/grub-core/fs/btrfs.c:186:1: error: alignment 1 of 'struct grub_btrfs_inode' is less than 4 [-Werror=packed-not-aligned] } GRUB_PACKED; ^ 4) iotivity fails to build with gcc8: service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp: In lambda function: service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp:164:30: error: 'value' is not captured ocRep[KEY] = value; ^~~~~ 5) nativesdk-libxcrypt fails to build (not sure which change caused this, it build OK with sumo since the -std=gnu99 addition. ../git/crypt-sunmd5.c:189:13: error: 'snprintf' output may be truncated before the last format character [-Werror=format-truncation=] "$" CRYPT_ALGNAME "," ROUNDS "%u$%s$", ^~~ 6) couple internal components which usually fail to build with gcc8, because of more strict warnings + Werror. I didn't get very far in testing, because our old kernel fails to build with gcc8 and there are some other issues caused by other master changes. But it doesn't look too bad (in my small test, lets see what bitbake world will show), thanks a lot for new gcc. Cheers, On Sat, May 5, 2018 at 2:26 AM, Khem Raj <raj.khem@gmail.com> wrote: > Hi All > > As you might have noticed that gcc 8.1 was released this week, I am > calling out for some testing help on testing branch so we can weed out > issues you might see in your setups. so if you have your > builders idling over weekend, then you know what they can do this weekend > :) > > Highlighted changes are > > https://gcc.gnu.org/gcc-8/changes.html > > and porting doc is > > https://gcc.gnu.org/gcc-8/porting_to.html > > The branch is here > > http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8 > > Its uptodate on top of current master oe-core > > May fourth be with you !! > > Cheers! > > -Khem > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > [-- Attachment #2: Type: text/html, Size: 11610 bytes --] ^ permalink raw reply [flat|nested] 74+ messages in thread
* [PATCH] busybox: Enable FEATURE_MOUNT_NFS and use libtirpc 2018-05-09 9:38 ` Martin Jansa (?) (?) @ 2018-05-10 12:20 ` Martin Jansa 2018-05-10 13:01 ` Burton, Ross -1 siblings, 1 reply; 74+ messages in thread From: Martin Jansa @ 2018-05-10 12:20 UTC (permalink / raw) To: openembedded-core * We dropped in-tree obsoleted rpc from glibc and now busybox builds which had CONFIG_FEATURE_MOUNT_NFS enabled were failing with: | util-linux/mount.c:252:11: fatal error: rpc/rpc.h: No such file or directory | # include <rpc/rpc.h> | ^~~~~~~~~~~ | compilation terminated. | make[1]: *** [util-linux/mount.o] Error 1 Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> --- meta/recipes-core/busybox/busybox.inc | 6 +++--- meta/recipes-core/busybox/busybox/defconfig | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/meta/recipes-core/busybox/busybox.inc b/meta/recipes-core/busybox/busybox.inc index d1675c37aa..2db19ed317 100644 --- a/meta/recipes-core/busybox/busybox.inc +++ b/meta/recipes-core/busybox/busybox.inc @@ -3,7 +3,7 @@ DESCRIPTION = "BusyBox combines tiny versions of many common UNIX utilities into HOMEPAGE = "http://www.busybox.net" BUGTRACKER = "https://bugs.busybox.net/" -DEPENDS += "kern-tools-native" +DEPENDS += "kern-tools-native libtirpc" # bzip2 applet in busybox is based on lightly-modified bzip2 source # the GPL is version 2 only @@ -15,8 +15,8 @@ SECTION = "base" # Whether to split the suid apps into a seperate binary BUSYBOX_SPLIT_SUID ?= "1" -export EXTRA_CFLAGS = "${CFLAGS}" -export EXTRA_LDFLAGS = "${LDFLAGS}" +export EXTRA_CFLAGS = "${CFLAGS} -I${STAGING_INCDIR}/tirpc" +export EXTRA_LDFLAGS = "${LDFLAGS} -ltirpc" EXTRA_OEMAKE = "CC='${CC}' LD='${CCLD}' V=1 ARCH=${TARGET_ARCH} CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y HOSTCC='${BUILD_CC}' HOSTCPP='${BUILD_CPP}'" diff --git a/meta/recipes-core/busybox/busybox/defconfig b/meta/recipes-core/busybox/busybox/defconfig index fbb5fd852c..816555fc21 100644 --- a/meta/recipes-core/busybox/busybox/defconfig +++ b/meta/recipes-core/busybox/busybox/defconfig @@ -638,7 +638,7 @@ CONFIG_MOUNT=y # CONFIG_FEATURE_MOUNT_VERBOSE is not set # CONFIG_FEATURE_MOUNT_HELPERS is not set # CONFIG_FEATURE_MOUNT_LABEL is not set -# CONFIG_FEATURE_MOUNT_NFS is not set +CONFIG_FEATURE_MOUNT_NFS=y # CONFIG_FEATURE_MOUNT_CIFS is not set CONFIG_FEATURE_MOUNT_FLAGS=y CONFIG_FEATURE_MOUNT_FSTAB=y -- 2.17.0 ^ permalink raw reply related [flat|nested] 74+ messages in thread
* Re: [PATCH] busybox: Enable FEATURE_MOUNT_NFS and use libtirpc 2018-05-10 12:20 ` [PATCH] busybox: Enable FEATURE_MOUNT_NFS and use libtirpc Martin Jansa @ 2018-05-10 13:01 ` Burton, Ross 2018-05-10 18:21 ` Khem Raj 0 siblings, 1 reply; 74+ messages in thread From: Burton, Ross @ 2018-05-10 13:01 UTC (permalink / raw) To: Martin Jansa; +Cc: OE-core Fails to build here: coreutils/lib.a(mktemp.o): In function `mktemp_main': | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/coreutils/mktemp.c:105: warning: the use of `mktemp' is dangerous, better use `mkstemp' or `mkdtemp' | util-linux/lib.a(mount.o): In function `xdr_fhstatus': | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1057: undefined reference to `xdr_u_int' | util-linux/lib.a(mount.o): In function `xdr_fhandle': | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1052: undefined reference to `xdr_opaque' | util-linux/lib.a(mount.o): In function `xdr_mountstat3': | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1089: undefined reference to `xdr_enum' | util-linux/lib.a(mount.o): In function `xdr_fhandle3': | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1071: undefined reference to `xdr_bytes' | util-linux/lib.a(mount.o): In function `xdr_mountres3_ok': | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1080: undefined reference to `xdr_int' | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1080: undefined reference to `xdr_array' | util-linux/lib.a(mount.o): In function `xdr_dirpath': | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1066: undefined reference to `xdr_string' | util-linux/lib.a(mount.o): In function `get_mountport': | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1145: undefined reference to `pmap_getmaps' | util-linux/lib.a(mount.o): In function `nfsmount': | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1662: undefined reference to `clnttcp_create' | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1677: undefined reference to `authunix_create_default' | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1652: undefined reference to `clntudp_create' | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1672: undefined reference to `clnt_spcreateerror' | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1702: undefined reference to `clnt_sperror' | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1707: undefined reference to `clnt_sperror' | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1788: undefined reference to `pmap_getport' Ross On 10 May 2018 at 13:20, Martin Jansa <martin.jansa@gmail.com> wrote: > * We dropped in-tree obsoleted rpc from glibc and now busybox builds > which had CONFIG_FEATURE_MOUNT_NFS enabled were failing with: > | util-linux/mount.c:252:11: fatal error: rpc/rpc.h: No such file or directory > | # include <rpc/rpc.h> > | ^~~~~~~~~~~ > | compilation terminated. > | make[1]: *** [util-linux/mount.o] Error 1 > > Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> > --- > meta/recipes-core/busybox/busybox.inc | 6 +++--- > meta/recipes-core/busybox/busybox/defconfig | 2 +- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/meta/recipes-core/busybox/busybox.inc b/meta/recipes-core/busybox/busybox.inc > index d1675c37aa..2db19ed317 100644 > --- a/meta/recipes-core/busybox/busybox.inc > +++ b/meta/recipes-core/busybox/busybox.inc > @@ -3,7 +3,7 @@ DESCRIPTION = "BusyBox combines tiny versions of many common UNIX utilities into > HOMEPAGE = "http://www.busybox.net" > BUGTRACKER = "https://bugs.busybox.net/" > > -DEPENDS += "kern-tools-native" > +DEPENDS += "kern-tools-native libtirpc" > > # bzip2 applet in busybox is based on lightly-modified bzip2 source > # the GPL is version 2 only > @@ -15,8 +15,8 @@ SECTION = "base" > # Whether to split the suid apps into a seperate binary > BUSYBOX_SPLIT_SUID ?= "1" > > -export EXTRA_CFLAGS = "${CFLAGS}" > -export EXTRA_LDFLAGS = "${LDFLAGS}" > +export EXTRA_CFLAGS = "${CFLAGS} -I${STAGING_INCDIR}/tirpc" > +export EXTRA_LDFLAGS = "${LDFLAGS} -ltirpc" > > EXTRA_OEMAKE = "CC='${CC}' LD='${CCLD}' V=1 ARCH=${TARGET_ARCH} CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y HOSTCC='${BUILD_CC}' HOSTCPP='${BUILD_CPP}'" > > diff --git a/meta/recipes-core/busybox/busybox/defconfig b/meta/recipes-core/busybox/busybox/defconfig > index fbb5fd852c..816555fc21 100644 > --- a/meta/recipes-core/busybox/busybox/defconfig > +++ b/meta/recipes-core/busybox/busybox/defconfig > @@ -638,7 +638,7 @@ CONFIG_MOUNT=y > # CONFIG_FEATURE_MOUNT_VERBOSE is not set > # CONFIG_FEATURE_MOUNT_HELPERS is not set > # CONFIG_FEATURE_MOUNT_LABEL is not set > -# CONFIG_FEATURE_MOUNT_NFS is not set > +CONFIG_FEATURE_MOUNT_NFS=y > # CONFIG_FEATURE_MOUNT_CIFS is not set > CONFIG_FEATURE_MOUNT_FLAGS=y > CONFIG_FEATURE_MOUNT_FSTAB=y > -- > 2.17.0 > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH] busybox: Enable FEATURE_MOUNT_NFS and use libtirpc 2018-05-10 13:01 ` Burton, Ross @ 2018-05-10 18:21 ` Khem Raj 2018-05-10 18:24 ` Khem Raj 0 siblings, 1 reply; 74+ messages in thread From: Khem Raj @ 2018-05-10 18:21 UTC (permalink / raw) To: Burton, Ross, Martin Jansa; +Cc: OE-core On 5/10/18 6:01 AM, Burton, Ross wrote: > Fails to build here: > > coreutils/lib.a(mktemp.o): In function `mktemp_main': > | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/coreutils/mktemp.c:105: > warning: the use of `mktemp' is dangerous, better use `mkstemp' or > `mkdtemp' > | util-linux/lib.a(mount.o): In function `xdr_fhstatus': > | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1057: > undefined reference to `xdr_u_int' > | util-linux/lib.a(mount.o): In function `xdr_fhandle': > | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1052: > undefined reference to `xdr_opaque' > | util-linux/lib.a(mount.o): In function `xdr_mountstat3': > | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1089: > undefined reference to `xdr_enum' > | util-linux/lib.a(mount.o): In function `xdr_fhandle3': > | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1071: > undefined reference to `xdr_bytes' > | util-linux/lib.a(mount.o): In function `xdr_mountres3_ok': > | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1080: > undefined reference to `xdr_int' > | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1080: > undefined reference to `xdr_array' > | util-linux/lib.a(mount.o): In function `xdr_dirpath': > | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1066: > undefined reference to `xdr_string' > | util-linux/lib.a(mount.o): In function `get_mountport': > | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1145: > undefined reference to `pmap_getmaps' > | util-linux/lib.a(mount.o): In function `nfsmount': > | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1662: > undefined reference to `clnttcp_create' > | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1677: > undefined reference to `authunix_create_default' > | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1652: > undefined reference to `clntudp_create' > | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1672: > undefined reference to `clnt_spcreateerror' > | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1702: > undefined reference to `clnt_sperror' > | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1707: > undefined reference to `clnt_sperror' > | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1788: > undefined reference to `pmap_getport' > We need to specify CONFIG_EXTRA_LDLIBS="tirpc" along with CONFIG_FEATURE_MOUNT_NFS=y secondly in v2 please delete # CONFIG_FEATURE_MOUNT_NFS is not set from meta/recipes-core/busybox/busybox/musl.cfg as well > Ross > > On 10 May 2018 at 13:20, Martin Jansa <martin.jansa@gmail.com> wrote: >> * We dropped in-tree obsoleted rpc from glibc and now busybox builds >> which had CONFIG_FEATURE_MOUNT_NFS enabled were failing with: >> | util-linux/mount.c:252:11: fatal error: rpc/rpc.h: No such file or directory >> | # include <rpc/rpc.h> >> | ^~~~~~~~~~~ >> | compilation terminated. >> | make[1]: *** [util-linux/mount.o] Error 1 >> >> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> >> --- >> meta/recipes-core/busybox/busybox.inc | 6 +++--- >> meta/recipes-core/busybox/busybox/defconfig | 2 +- >> 2 files changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/meta/recipes-core/busybox/busybox.inc b/meta/recipes-core/busybox/busybox.inc >> index d1675c37aa..2db19ed317 100644 >> --- a/meta/recipes-core/busybox/busybox.inc >> +++ b/meta/recipes-core/busybox/busybox.inc >> @@ -3,7 +3,7 @@ DESCRIPTION = "BusyBox combines tiny versions of many common UNIX utilities into >> HOMEPAGE = "http://www.busybox.net" >> BUGTRACKER = "https://bugs.busybox.net/" >> >> -DEPENDS += "kern-tools-native" >> +DEPENDS += "kern-tools-native libtirpc" >> >> # bzip2 applet in busybox is based on lightly-modified bzip2 source >> # the GPL is version 2 only >> @@ -15,8 +15,8 @@ SECTION = "base" >> # Whether to split the suid apps into a seperate binary >> BUSYBOX_SPLIT_SUID ?= "1" >> >> -export EXTRA_CFLAGS = "${CFLAGS}" >> -export EXTRA_LDFLAGS = "${LDFLAGS}" >> +export EXTRA_CFLAGS = "${CFLAGS} -I${STAGING_INCDIR}/tirpc" >> +export EXTRA_LDFLAGS = "${LDFLAGS} -ltirpc" >> >> EXTRA_OEMAKE = "CC='${CC}' LD='${CCLD}' V=1 ARCH=${TARGET_ARCH} CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y HOSTCC='${BUILD_CC}' HOSTCPP='${BUILD_CPP}'" >> >> diff --git a/meta/recipes-core/busybox/busybox/defconfig b/meta/recipes-core/busybox/busybox/defconfig >> index fbb5fd852c..816555fc21 100644 >> --- a/meta/recipes-core/busybox/busybox/defconfig >> +++ b/meta/recipes-core/busybox/busybox/defconfig >> @@ -638,7 +638,7 @@ CONFIG_MOUNT=y >> # CONFIG_FEATURE_MOUNT_VERBOSE is not set >> # CONFIG_FEATURE_MOUNT_HELPERS is not set >> # CONFIG_FEATURE_MOUNT_LABEL is not set >> -# CONFIG_FEATURE_MOUNT_NFS is not set >> +CONFIG_FEATURE_MOUNT_NFS=y >> # CONFIG_FEATURE_MOUNT_CIFS is not set >> CONFIG_FEATURE_MOUNT_FLAGS=y >> CONFIG_FEATURE_MOUNT_FSTAB=y >> -- >> 2.17.0 >> >> -- >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH] busybox: Enable FEATURE_MOUNT_NFS and use libtirpc 2018-05-10 18:21 ` Khem Raj @ 2018-05-10 18:24 ` Khem Raj 2018-05-10 19:16 ` Martin Jansa 0 siblings, 1 reply; 74+ messages in thread From: Khem Raj @ 2018-05-10 18:24 UTC (permalink / raw) To: Burton, Ross, Martin Jansa; +Cc: OE-core On 5/10/18 11:21 AM, Khem Raj wrote: > > > On 5/10/18 6:01 AM, Burton, Ross wrote: >> Fails to build here: >> >> coreutils/lib.a(mktemp.o): In function `mktemp_main': >> | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/coreutils/mktemp.c:105: >> warning: the use of `mktemp' is dangerous, better use `mkstemp' or >> `mkdtemp' >> | util-linux/lib.a(mount.o): In function `xdr_fhstatus': >> | >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1057: >> undefined reference to `xdr_u_int' >> | util-linux/lib.a(mount.o): In function `xdr_fhandle': >> | >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1052: >> undefined reference to `xdr_opaque' >> | util-linux/lib.a(mount.o): In function `xdr_mountstat3': >> | >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1089: >> undefined reference to `xdr_enum' >> | util-linux/lib.a(mount.o): In function `xdr_fhandle3': >> | >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1071: >> undefined reference to `xdr_bytes' >> | util-linux/lib.a(mount.o): In function `xdr_mountres3_ok': >> | >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1080: >> undefined reference to `xdr_int' >> | >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1080: >> undefined reference to `xdr_array' >> | util-linux/lib.a(mount.o): In function `xdr_dirpath': >> | >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1066: >> undefined reference to `xdr_string' >> | util-linux/lib.a(mount.o): In function `get_mountport': >> | >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1145: >> undefined reference to `pmap_getmaps' >> | util-linux/lib.a(mount.o): In function `nfsmount': >> | >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1662: >> undefined reference to `clnttcp_create' >> | >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1677: >> undefined reference to `authunix_create_default' >> | >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1652: >> undefined reference to `clntudp_create' >> | >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1672: >> undefined reference to `clnt_spcreateerror' >> | >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1702: >> undefined reference to `clnt_sperror' >> | >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1707: >> undefined reference to `clnt_sperror' >> | >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1788: >> undefined reference to `pmap_getport' >> > > We need to specify > > CONFIG_EXTRA_LDLIBS="tirpc" > > along with > > CONFIG_FEATURE_MOUNT_NFS=y > > secondly in v2 please delete > > # CONFIG_FEATURE_MOUNT_NFS is not set > > from meta/recipes-core/busybox/busybox/musl.cfg as well > On second thought, this probably should be enabled using a config fragment, since its not gonna link in another library it may not be common case to justify for a default config. >> Ross >> >> On 10 May 2018 at 13:20, Martin Jansa <martin.jansa@gmail.com> wrote: >>> * We dropped in-tree obsoleted rpc from glibc and now busybox builds >>> which had CONFIG_FEATURE_MOUNT_NFS enabled were failing with: >>> | util-linux/mount.c:252:11: fatal error: rpc/rpc.h: No such file >>> or directory >>> | # include <rpc/rpc.h> >>> | ^~~~~~~~~~~ >>> | compilation terminated. >>> | make[1]: *** [util-linux/mount.o] Error 1 >>> >>> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> >>> --- >>> meta/recipes-core/busybox/busybox.inc | 6 +++--- >>> meta/recipes-core/busybox/busybox/defconfig | 2 +- >>> 2 files changed, 4 insertions(+), 4 deletions(-) >>> >>> diff --git a/meta/recipes-core/busybox/busybox.inc >>> b/meta/recipes-core/busybox/busybox.inc >>> index d1675c37aa..2db19ed317 100644 >>> --- a/meta/recipes-core/busybox/busybox.inc >>> +++ b/meta/recipes-core/busybox/busybox.inc >>> @@ -3,7 +3,7 @@ DESCRIPTION = "BusyBox combines tiny versions of many >>> common UNIX utilities into >>> HOMEPAGE = "http://www.busybox.net" >>> BUGTRACKER = "https://bugs.busybox.net/" >>> >>> -DEPENDS += "kern-tools-native" >>> +DEPENDS += "kern-tools-native libtirpc" >>> >>> # bzip2 applet in busybox is based on lightly-modified bzip2 source >>> # the GPL is version 2 only >>> @@ -15,8 +15,8 @@ SECTION = "base" >>> # Whether to split the suid apps into a seperate binary >>> BUSYBOX_SPLIT_SUID ?= "1" >>> >>> -export EXTRA_CFLAGS = "${CFLAGS}" >>> -export EXTRA_LDFLAGS = "${LDFLAGS}" >>> +export EXTRA_CFLAGS = "${CFLAGS} -I${STAGING_INCDIR}/tirpc" >>> +export EXTRA_LDFLAGS = "${LDFLAGS} -ltirpc" >>> >>> EXTRA_OEMAKE = "CC='${CC}' LD='${CCLD}' V=1 ARCH=${TARGET_ARCH} >>> CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y HOSTCC='${BUILD_CC}' >>> HOSTCPP='${BUILD_CPP}'" >>> >>> diff --git a/meta/recipes-core/busybox/busybox/defconfig >>> b/meta/recipes-core/busybox/busybox/defconfig >>> index fbb5fd852c..816555fc21 100644 >>> --- a/meta/recipes-core/busybox/busybox/defconfig >>> +++ b/meta/recipes-core/busybox/busybox/defconfig >>> @@ -638,7 +638,7 @@ CONFIG_MOUNT=y >>> # CONFIG_FEATURE_MOUNT_VERBOSE is not set >>> # CONFIG_FEATURE_MOUNT_HELPERS is not set >>> # CONFIG_FEATURE_MOUNT_LABEL is not set >>> -# CONFIG_FEATURE_MOUNT_NFS is not set >>> +CONFIG_FEATURE_MOUNT_NFS=y >>> # CONFIG_FEATURE_MOUNT_CIFS is not set >>> CONFIG_FEATURE_MOUNT_FLAGS=y >>> CONFIG_FEATURE_MOUNT_FSTAB=y >>> -- >>> 2.17.0 >>> >>> -- >>> _______________________________________________ >>> Openembedded-core mailing list >>> Openembedded-core@lists.openembedded.org >>> http://lists.openembedded.org/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH] busybox: Enable FEATURE_MOUNT_NFS and use libtirpc 2018-05-10 18:24 ` Khem Raj @ 2018-05-10 19:16 ` Martin Jansa 2018-05-10 19:26 ` Khem Raj 0 siblings, 1 reply; 74+ messages in thread From: Martin Jansa @ 2018-05-10 19:16 UTC (permalink / raw) To: Khem Raj; +Cc: OE-core [-- Attachment #1: Type: text/plain, Size: 6634 bytes --] On Thu, May 10, 2018 at 11:24:02AM -0700, Khem Raj wrote: > > > On 5/10/18 11:21 AM, Khem Raj wrote: > > > > > > On 5/10/18 6:01 AM, Burton, Ross wrote: > >> Fails to build here: > >> > >> coreutils/lib.a(mktemp.o): In function `mktemp_main': > >> | /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/coreutils/mktemp.c:105: > >> warning: the use of `mktemp' is dangerous, better use `mkstemp' or > >> `mkdtemp' > >> | util-linux/lib.a(mount.o): In function `xdr_fhstatus': > >> | > >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1057: > >> undefined reference to `xdr_u_int' > >> | util-linux/lib.a(mount.o): In function `xdr_fhandle': > >> | > >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1052: > >> undefined reference to `xdr_opaque' > >> | util-linux/lib.a(mount.o): In function `xdr_mountstat3': > >> | > >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1089: > >> undefined reference to `xdr_enum' > >> | util-linux/lib.a(mount.o): In function `xdr_fhandle3': > >> | > >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1071: > >> undefined reference to `xdr_bytes' > >> | util-linux/lib.a(mount.o): In function `xdr_mountres3_ok': > >> | > >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1080: > >> undefined reference to `xdr_int' > >> | > >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1080: > >> undefined reference to `xdr_array' > >> | util-linux/lib.a(mount.o): In function `xdr_dirpath': > >> | > >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1066: > >> undefined reference to `xdr_string' > >> | util-linux/lib.a(mount.o): In function `get_mountport': > >> | > >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1145: > >> undefined reference to `pmap_getmaps' > >> | util-linux/lib.a(mount.o): In function `nfsmount': > >> | > >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1662: > >> undefined reference to `clnttcp_create' > >> | > >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1677: > >> undefined reference to `authunix_create_default' > >> | > >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1652: > >> undefined reference to `clntudp_create' > >> | > >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1672: > >> undefined reference to `clnt_spcreateerror' > >> | > >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1702: > >> undefined reference to `clnt_sperror' > >> | > >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1707: > >> undefined reference to `clnt_sperror' > >> | > >> /usr/src/debug/busybox/1.27.2-r0/busybox-1.27.2/util-linux/mount.c:1788: > >> undefined reference to `pmap_getport' > >> > > > > We need to specify > > > > CONFIG_EXTRA_LDLIBS="tirpc" > > > > along with > > > > CONFIG_FEATURE_MOUNT_NFS=y > > > > secondly in v2 please delete > > > > # CONFIG_FEATURE_MOUNT_NFS is not set > > > > from meta/recipes-core/busybox/busybox/musl.cfg as well > > > > On second thought, this probably should be enabled using a config > fragment, since its not gonna link in another library it may not be > common case to justify for a default config. That's true, I've enabled CONFIG_FEATURE_MOUNT_NFS mostly to show how to reproduce the issue. If there isn't interest to enable this by default, I'm fine with keeping this locally (to enable it only with our defconfig changes which enable it). > >> Ross > >> > >> On 10 May 2018 at 13:20, Martin Jansa <martin.jansa@gmail.com> wrote: > >>> * We dropped in-tree obsoleted rpc from glibc and now busybox builds > >>> which had CONFIG_FEATURE_MOUNT_NFS enabled were failing with: > >>> | util-linux/mount.c:252:11: fatal error: rpc/rpc.h: No such file > >>> or directory > >>> | # include <rpc/rpc.h> > >>> | ^~~~~~~~~~~ > >>> | compilation terminated. > >>> | make[1]: *** [util-linux/mount.o] Error 1 > >>> > >>> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> > >>> --- > >>> meta/recipes-core/busybox/busybox.inc | 6 +++--- > >>> meta/recipes-core/busybox/busybox/defconfig | 2 +- > >>> 2 files changed, 4 insertions(+), 4 deletions(-) > >>> > >>> diff --git a/meta/recipes-core/busybox/busybox.inc > >>> b/meta/recipes-core/busybox/busybox.inc > >>> index d1675c37aa..2db19ed317 100644 > >>> --- a/meta/recipes-core/busybox/busybox.inc > >>> +++ b/meta/recipes-core/busybox/busybox.inc > >>> @@ -3,7 +3,7 @@ DESCRIPTION = "BusyBox combines tiny versions of many > >>> common UNIX utilities into > >>> HOMEPAGE = "http://www.busybox.net" > >>> BUGTRACKER = "https://bugs.busybox.net/" > >>> > >>> -DEPENDS += "kern-tools-native" > >>> +DEPENDS += "kern-tools-native libtirpc" > >>> > >>> # bzip2 applet in busybox is based on lightly-modified bzip2 source > >>> # the GPL is version 2 only > >>> @@ -15,8 +15,8 @@ SECTION = "base" > >>> # Whether to split the suid apps into a seperate binary > >>> BUSYBOX_SPLIT_SUID ?= "1" > >>> > >>> -export EXTRA_CFLAGS = "${CFLAGS}" > >>> -export EXTRA_LDFLAGS = "${LDFLAGS}" > >>> +export EXTRA_CFLAGS = "${CFLAGS} -I${STAGING_INCDIR}/tirpc" > >>> +export EXTRA_LDFLAGS = "${LDFLAGS} -ltirpc" > >>> > >>> EXTRA_OEMAKE = "CC='${CC}' LD='${CCLD}' V=1 ARCH=${TARGET_ARCH} > >>> CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y HOSTCC='${BUILD_CC}' > >>> HOSTCPP='${BUILD_CPP}'" > >>> > >>> diff --git a/meta/recipes-core/busybox/busybox/defconfig > >>> b/meta/recipes-core/busybox/busybox/defconfig > >>> index fbb5fd852c..816555fc21 100644 > >>> --- a/meta/recipes-core/busybox/busybox/defconfig > >>> +++ b/meta/recipes-core/busybox/busybox/defconfig > >>> @@ -638,7 +638,7 @@ CONFIG_MOUNT=y > >>> # CONFIG_FEATURE_MOUNT_VERBOSE is not set > >>> # CONFIG_FEATURE_MOUNT_HELPERS is not set > >>> # CONFIG_FEATURE_MOUNT_LABEL is not set > >>> -# CONFIG_FEATURE_MOUNT_NFS is not set > >>> +CONFIG_FEATURE_MOUNT_NFS=y > >>> # CONFIG_FEATURE_MOUNT_CIFS is not set > >>> CONFIG_FEATURE_MOUNT_FLAGS=y > >>> CONFIG_FEATURE_MOUNT_FSTAB=y > >>> -- > >>> 2.17.0 > >>> > >>> -- > >>> _______________________________________________ > >>> Openembedded-core mailing list > >>> Openembedded-core@lists.openembedded.org > >>> http://lists.openembedded.org/mailman/listinfo/openembedded-core -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 201 bytes --] ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH] busybox: Enable FEATURE_MOUNT_NFS and use libtirpc 2018-05-10 19:16 ` Martin Jansa @ 2018-05-10 19:26 ` Khem Raj 2018-05-30 17:39 ` Andre McCurdy 0 siblings, 1 reply; 74+ messages in thread From: Khem Raj @ 2018-05-10 19:26 UTC (permalink / raw) To: Martin Jansa; +Cc: OE-core On 5/10/18 12:16 PM, Martin Jansa wrote: >> On second thought, this probably should be enabled using a config >> fragment, since its not gonna link in another library it may not be >> common case to justify for a default config. > That's true, I've enabled CONFIG_FEATURE_MOUNT_NFS mostly to show how to > reproduce the issue. > > If there isn't interest to enable this by default, I'm fine with keeping this > locally (to enable it only with our defconfig changes which enable it). > I think keeping it as a nfsmount.cfg which then can be applied via a bbappend could be a good option. May be adding a PACKAGECONFIG to control the -I flag and libtirpc dependency would be nice too ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH] busybox: Enable FEATURE_MOUNT_NFS and use libtirpc 2018-05-10 19:26 ` Khem Raj @ 2018-05-30 17:39 ` Andre McCurdy 2018-06-10 11:05 ` Martin Jansa 0 siblings, 1 reply; 74+ messages in thread From: Andre McCurdy @ 2018-05-30 17:39 UTC (permalink / raw) To: Khem Raj; +Cc: OE-core On Thu, May 10, 2018 at 12:26 PM, Khem Raj <raj.khem@gmail.com> wrote: > On 5/10/18 12:16 PM, Martin Jansa wrote: >>> >>> On second thought, this probably should be enabled using a config >>> fragment, since its not gonna link in another library it may not be >>> common case to justify for a default config. >> >> That's true, I've enabled CONFIG_FEATURE_MOUNT_NFS mostly to show how to >> reproduce the issue. >> >> If there isn't interest to enable this by default, I'm fine with keeping >> this >> locally (to enable it only with our defconfig changes which enable it). > > I think keeping it as a nfsmount.cfg which then can be applied via a > bbappend could be a good option. May be adding a PACKAGECONFIG to control > the -I flag and libtirpc dependency would be nice too According to the busybox config help, CONFIG_FEATURE_MOUNT_NFS is only required for kernel versions before 2.6.23. Do we officially support kernels that old in oe-core? Or should this be in a .bbappend etc in separate layer? //config:config FEATURE_MOUNT_NFS //config: bool "Support mounting NFS file systems on Linux < 2.6.23" //config: default n //config: depends on MOUNT //config: select FEATURE_SYSLOG //config: help //config: Enable mounting of NFS file systems on Linux kernels prior //config: to version 2.6.23. Note that in this case mounting of NFS //config: over IPv6 will not be possible. //config: //config: Note that this option links in RPC support from libc, //config: which is rather large (~10 kbytes on uclibc). ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [PATCH] busybox: Enable FEATURE_MOUNT_NFS and use libtirpc 2018-05-30 17:39 ` Andre McCurdy @ 2018-06-10 11:05 ` Martin Jansa 0 siblings, 0 replies; 74+ messages in thread From: Martin Jansa @ 2018-06-10 11:05 UTC (permalink / raw) To: Andre McCurdy; +Cc: OE-core [-- Attachment #1.1: Type: text/plain, Size: 1929 bytes --] On Wed, May 30, 2018 at 10:39:16AM -0700, Andre McCurdy wrote: > On Thu, May 10, 2018 at 12:26 PM, Khem Raj <raj.khem@gmail.com> wrote: > > On 5/10/18 12:16 PM, Martin Jansa wrote: > >>> > >>> On second thought, this probably should be enabled using a config > >>> fragment, since its not gonna link in another library it may not be > >>> common case to justify for a default config. > >> > >> That's true, I've enabled CONFIG_FEATURE_MOUNT_NFS mostly to show how to > >> reproduce the issue. > >> > >> If there isn't interest to enable this by default, I'm fine with keeping > >> this > >> locally (to enable it only with our defconfig changes which enable it). > > > > I think keeping it as a nfsmount.cfg which then can be applied via a > > bbappend could be a good option. May be adding a PACKAGECONFIG to control > > the -I flag and libtirpc dependency would be nice too > > According to the busybox config help, CONFIG_FEATURE_MOUNT_NFS is only > required for kernel versions before 2.6.23. Do we officially support > kernels that old in oe-core? Or should this be in a .bbappend etc in > separate layer? OK, I agree that this should be kept in separate layer. If anyone needs it, the working version (with tirpc added in CONFIG_EXTRA_LDLIBS) is attached. > //config:config FEATURE_MOUNT_NFS > //config: bool "Support mounting NFS file systems on Linux < 2.6.23" > //config: default n > //config: depends on MOUNT > //config: select FEATURE_SYSLOG > //config: help > //config: Enable mounting of NFS file systems on Linux kernels prior > //config: to version 2.6.23. Note that in this case mounting of NFS > //config: over IPv6 will not be possible. > //config: > //config: Note that this option links in RPC support from libc, > //config: which is rather large (~10 kbytes on uclibc). -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #1.2: 0001-busybox-Enable-FEATURE_MOUNT_NFS-and-use-libtirpc.patch --] [-- Type: text/x-diff, Size: 2680 bytes --] From 3316407c73058173bcfa1b9fabcad4592d23cbfc Mon Sep 17 00:00:00 2001 From: Martin Jansa <Martin.Jansa@gmail.com> Date: Thu, 10 May 2018 12:08:58 +0000 Subject: [PATCH] busybox: Enable FEATURE_MOUNT_NFS and use libtirpc * We dropped in-tree obsoleted rpc from glibc and now busybox builds which had CONFIG_FEATURE_MOUNT_NFS enabled were failing with: | util-linux/mount.c:252:11: fatal error: rpc/rpc.h: No such file or directory | # include <rpc/rpc.h> | ^~~~~~~~~~~ | compilation terminated. | make[1]: *** [util-linux/mount.o] Error 1 Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> --- meta/recipes-core/busybox/busybox.inc | 6 +++--- meta/recipes-core/busybox/busybox/defconfig | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/meta/recipes-core/busybox/busybox.inc b/meta/recipes-core/busybox/busybox.inc index d1675c37aa..2db19ed317 100644 --- a/meta/recipes-core/busybox/busybox.inc +++ b/meta/recipes-core/busybox/busybox.inc @@ -3,7 +3,7 @@ DESCRIPTION = "BusyBox combines tiny versions of many common UNIX utilities into HOMEPAGE = "http://www.busybox.net" BUGTRACKER = "https://bugs.busybox.net/" -DEPENDS += "kern-tools-native" +DEPENDS += "kern-tools-native libtirpc" # bzip2 applet in busybox is based on lightly-modified bzip2 source # the GPL is version 2 only @@ -15,8 +15,8 @@ SECTION = "base" # Whether to split the suid apps into a seperate binary BUSYBOX_SPLIT_SUID ?= "1" -export EXTRA_CFLAGS = "${CFLAGS}" -export EXTRA_LDFLAGS = "${LDFLAGS}" +export EXTRA_CFLAGS = "${CFLAGS} -I${STAGING_INCDIR}/tirpc" +export EXTRA_LDFLAGS = "${LDFLAGS} -ltirpc" EXTRA_OEMAKE = "CC='${CC}' LD='${CCLD}' V=1 ARCH=${TARGET_ARCH} CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y HOSTCC='${BUILD_CC}' HOSTCPP='${BUILD_CPP}'" diff --git a/meta/recipes-core/busybox/busybox/defconfig b/meta/recipes-core/busybox/busybox/defconfig index fbb5fd852c..2e920277b7 100644 --- a/meta/recipes-core/busybox/busybox/defconfig +++ b/meta/recipes-core/busybox/busybox/defconfig @@ -51,7 +51,7 @@ CONFIG_CROSS_COMPILER_PREFIX="" CONFIG_SYSROOT="" CONFIG_EXTRA_CFLAGS="" CONFIG_EXTRA_LDFLAGS="" -CONFIG_EXTRA_LDLIBS="" +CONFIG_EXTRA_LDLIBS="tirpc" # # Installation Options ("make install" behavior) @@ -638,7 +638,7 @@ CONFIG_MOUNT=y # CONFIG_FEATURE_MOUNT_VERBOSE is not set # CONFIG_FEATURE_MOUNT_HELPERS is not set # CONFIG_FEATURE_MOUNT_LABEL is not set -# CONFIG_FEATURE_MOUNT_NFS is not set +CONFIG_FEATURE_MOUNT_NFS=y # CONFIG_FEATURE_MOUNT_CIFS is not set CONFIG_FEATURE_MOUNT_FLAGS=y CONFIG_FEATURE_MOUNT_FSTAB=y -- 2.17.1 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 201 bytes --] ^ permalink raw reply related [flat|nested] 74+ messages in thread
* Re: [OE-core] [RFT] GCC 8.1 2018-05-09 9:38 ` Martin Jansa @ 2018-05-10 18:50 ` Khem Raj -1 siblings, 0 replies; 74+ messages in thread From: Khem Raj @ 2018-05-10 18:50 UTC (permalink / raw) To: Martin Jansa Cc: Yocto Project, openembeded-devel, Patches and discussions about the oe-core layer Hi Martin Thanks for testing and reporting back On 5/9/18 2:38 AM, Martin Jansa wrote: > My initial tests show couple issues, but usually caused by other changes > in that branch, not the gcc-8 itself. > > 1) strace-4.22 from > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654 > fails to build with ptest enabled (it builds with 4.20 version if I > revert this change) > ../../strace-4.22/tests/inject-nf.c: In function 'main': > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in > asm here > } > ^ are you targeting thumb1 ? how can I reproduce it ? > Makefile:6313: recipe for target 'inject-nf.o' failed > make: *** [inject-nf.o] Error 1 > make: Leaving directory 'strace/4.22-r0/build/tests' > > 2) glibc with obsolete rpc disabled from: > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=0cd820424d4bdb5cc68e7503e09a0359fd21150a > causes busybox's mount applet to fail building: > util-linux/mount.c:252:11: fatal error: rpc/rpc.h: No such file or directory > # include <rpc/rpc.h> > ^~~~~~~~~~~ > compilation terminated. > make[1]: *** [util-linux/mount.o] Error 1 > make: *** [util-linux] Error 2 I think you sent a patch already for this so discussion for fix are on going. > > 3) grub and grub-efi fails to build with gcc8: > In file included from ../grub-2.02/grub-core/partmap/gpt.c:26: > ../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of > 'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned] > } GRUB_PACKED; > ^ > In file included from ../grub-2.02/grub-core/disk/ldm.c:26: > ../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of > 'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned] > } GRUB_PACKED; > ^ > .. > ../grub-2.02/grub-core/fs/btrfs.c:186:1: error: alignment 1 of 'struct > grub_btrfs_inode' is less than 4 [-Werror=packed-not-aligned] > } GRUB_PACKED; > ^ > I think we need to align end of these structs here, can you try https://src.fedoraproject.org/rpms/grub2/raw/master/f/0198-align-struct-efi_variable-better.patch > 4) iotivity fails to build with gcc8: > service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp: > In lambda function: > service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp:164:30: > error: 'value' is not captured > ocRep[KEY] = value; > ^~~~~ > this needs more investigation. May be move https://github.com/iotivity/iotivity/blob/master/service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp#L160 just above https://github.com/iotivity/iotivity/blob/master/service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp#L165 > 5) nativesdk-libxcrypt fails to build (not sure which change caused > this, it build OK with sumo since the -std=gnu99 addition. > ../git/crypt-sunmd5.c:189:13: error: 'snprintf' output may be truncated > before the last format character [-Werror=format-truncation=] > "$" CRYPT_ALGNAME "," ROUNDS "%u$%s$", > ^~~ > something new, I will look into reproducing this. > 6) couple internal components which usually fail to build with gcc8, > because of more strict warnings + Werror. OK, feel free to send out question if you get stuck > > I didn't get very far in testing, because our old kernel fails to build > with gcc8 and there are some other issues caused by other master > changes. But it doesn't look too bad (in my small test, lets see what > bitbake world will show), thanks a lot for new gcc. > yes, older kernel needs fixes, especially to disable new warnings. the mips/ppc fixes that I put out there might be helpful to cook up fixes for older kernels if running into same issues. > Cheers, > > > > > > On Sat, May 5, 2018 at 2:26 AM, Khem Raj <raj.khem@gmail.com > <mailto:raj.khem@gmail.com>> wrote: > > Hi All > > As you might have noticed that gcc 8.1 was released this week, I am > calling out for some testing help on testing branch so we can weed out > issues you might see in your setups. so if you have your > builders idling over weekend, then you know what they can do this > weekend :) > > Highlighted changes are > > https://gcc.gnu.org/gcc-8/changes.html > <https://gcc.gnu.org/gcc-8/changes.html> > > and porting doc is > > https://gcc.gnu.org/gcc-8/porting_to.html > <https://gcc.gnu.org/gcc-8/porting_to.html> > > The branch is here > > http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8 > <http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8> > > Its uptodate on top of current master oe-core > > May fourth be with you !! > > Cheers! > > -Khem > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > <mailto:Openembedded-core@lists.openembedded.org> > http://lists.openembedded.org/mailman/listinfo/openembedded-core > <http://lists.openembedded.org/mailman/listinfo/openembedded-core> > > ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFT] GCC 8.1 @ 2018-05-10 18:50 ` Khem Raj 0 siblings, 0 replies; 74+ messages in thread From: Khem Raj @ 2018-05-10 18:50 UTC (permalink / raw) To: Martin Jansa Cc: Yocto Project, openembeded-devel, Patches and discussions about the oe-core layer Hi Martin Thanks for testing and reporting back On 5/9/18 2:38 AM, Martin Jansa wrote: > My initial tests show couple issues, but usually caused by other changes > in that branch, not the gcc-8 itself. > > 1) strace-4.22 from > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654 > fails to build with ptest enabled (it builds with 4.20 version if I > revert this change) > ../../strace-4.22/tests/inject-nf.c: In function 'main': > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in > asm here > } > ^ are you targeting thumb1 ? how can I reproduce it ? > Makefile:6313: recipe for target 'inject-nf.o' failed > make: *** [inject-nf.o] Error 1 > make: Leaving directory 'strace/4.22-r0/build/tests' > > 2) glibc with obsolete rpc disabled from: > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=0cd820424d4bdb5cc68e7503e09a0359fd21150a > causes busybox's mount applet to fail building: > util-linux/mount.c:252:11: fatal error: rpc/rpc.h: No such file or directory > # include <rpc/rpc.h> > ^~~~~~~~~~~ > compilation terminated. > make[1]: *** [util-linux/mount.o] Error 1 > make: *** [util-linux] Error 2 I think you sent a patch already for this so discussion for fix are on going. > > 3) grub and grub-efi fails to build with gcc8: > In file included from ../grub-2.02/grub-core/partmap/gpt.c:26: > ../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of > 'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned] > } GRUB_PACKED; > ^ > In file included from ../grub-2.02/grub-core/disk/ldm.c:26: > ../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of > 'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned] > } GRUB_PACKED; > ^ > .. > ../grub-2.02/grub-core/fs/btrfs.c:186:1: error: alignment 1 of 'struct > grub_btrfs_inode' is less than 4 [-Werror=packed-not-aligned] > } GRUB_PACKED; > ^ > I think we need to align end of these structs here, can you try https://src.fedoraproject.org/rpms/grub2/raw/master/f/0198-align-struct-efi_variable-better.patch > 4) iotivity fails to build with gcc8: > service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp: > In lambda function: > service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp:164:30: > error: 'value' is not captured > ocRep[KEY] = value; > ^~~~~ > this needs more investigation. May be move https://github.com/iotivity/iotivity/blob/master/service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp#L160 just above https://github.com/iotivity/iotivity/blob/master/service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp#L165 > 5) nativesdk-libxcrypt fails to build (not sure which change caused > this, it build OK with sumo since the -std=gnu99 addition. > ../git/crypt-sunmd5.c:189:13: error: 'snprintf' output may be truncated > before the last format character [-Werror=format-truncation=] > "$" CRYPT_ALGNAME "," ROUNDS "%u$%s$", > ^~~ > something new, I will look into reproducing this. > 6) couple internal components which usually fail to build with gcc8, > because of more strict warnings + Werror. OK, feel free to send out question if you get stuck > > I didn't get very far in testing, because our old kernel fails to build > with gcc8 and there are some other issues caused by other master > changes. But it doesn't look too bad (in my small test, lets see what > bitbake world will show), thanks a lot for new gcc. > yes, older kernel needs fixes, especially to disable new warnings. the mips/ppc fixes that I put out there might be helpful to cook up fixes for older kernels if running into same issues. > Cheers, > > > > > > On Sat, May 5, 2018 at 2:26 AM, Khem Raj <raj.khem@gmail.com > <mailto:raj.khem@gmail.com>> wrote: > > Hi All > > As you might have noticed that gcc 8.1 was released this week, I am > calling out for some testing help on testing branch so we can weed out > issues you might see in your setups. so if you have your > builders idling over weekend, then you know what they can do this > weekend :) > > Highlighted changes are > > https://gcc.gnu.org/gcc-8/changes.html > <https://gcc.gnu.org/gcc-8/changes.html> > > and porting doc is > > https://gcc.gnu.org/gcc-8/porting_to.html > <https://gcc.gnu.org/gcc-8/porting_to.html> > > The branch is here > > http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8 > <http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8> > > Its uptodate on top of current master oe-core > > May fourth be with you !! > > Cheers! > > -Khem > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > <mailto:Openembedded-core@lists.openembedded.org> > http://lists.openembedded.org/mailman/listinfo/openembedded-core > <http://lists.openembedded.org/mailman/listinfo/openembedded-core> > > ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [OE-core] [RFT] GCC 8.1 2018-05-10 18:50 ` Khem Raj @ 2018-05-10 19:11 ` Martin Jansa -1 siblings, 0 replies; 74+ messages in thread From: Martin Jansa @ 2018-05-10 19:11 UTC (permalink / raw) To: Khem Raj Cc: Yocto Project, openembeded-devel, Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 11927 bytes --] On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote: > Hi Martin > > Thanks for testing and reporting back > > On 5/9/18 2:38 AM, Martin Jansa wrote: > > My initial tests show couple issues, but usually caused by other changes > > in that branch, not the gcc-8 itself. > > > > 1) strace-4.22 from > > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654 > > fails to build with ptest enabled (it builds with 4.20 version if I > > revert this change) > > ../../strace-4.22/tests/inject-nf.c: In function 'main': > > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in > > asm here > > } > > ^ > > are you targeting thumb1 ? how can I reproduce it ? I'm trying to find out what's different in the builds where it was failing, will provide more info later. > > Makefile:6313: recipe for target 'inject-nf.o' failed > > make: *** [inject-nf.o] Error 1 > > make: Leaving directory 'strace/4.22-r0/build/tests' > > > > 2) glibc with obsolete rpc disabled from: > > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=0cd820424d4bdb5cc68e7503e09a0359fd21150a > > causes busybox's mount applet to fail building: > > util-linux/mount.c:252:11: fatal error: rpc/rpc.h: No such file or directory > > # include <rpc/rpc.h> > > ^~~~~~~~~~~ > > compilation terminated. > > make[1]: *** [util-linux/mount.o] Error 1 > > make: *** [util-linux] Error 2 > > I think you sent a patch already for this so discussion for fix are on > going. > > > > > 3) grub and grub-efi fails to build with gcc8: > > In file included from ../grub-2.02/grub-core/partmap/gpt.c:26: > > ../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of > > 'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned] > > } GRUB_PACKED; > > ^ > > In file included from ../grub-2.02/grub-core/disk/ldm.c:26: > > ../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of > > 'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned] > > } GRUB_PACKED; > > ^ > > .. > > ../grub-2.02/grub-core/fs/btrfs.c:186:1: error: alignment 1 of 'struct > > grub_btrfs_inode' is less than 4 [-Werror=packed-not-aligned] > > } GRUB_PACKED; > > ^ > > > > I think we need to align end of these structs here, can you try > https://src.fedoraproject.org/rpms/grub2/raw/master/f/0198-align-struct-efi_variable-better.patch I've sent fix as well: http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150587.html it's in master-next already. > > 4) iotivity fails to build with gcc8: > > service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp: > > In lambda function: > > service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp:164:30: > > error: 'value' is not captured > > ocRep[KEY] = value; > > ^~~~~ > > > > this needs more investigation. May be move > https://github.com/iotivity/iotivity/blob/master/service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp#L160 > > just above > https://github.com/iotivity/iotivity/blob/master/service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp#L165 There are more issues in iotivity: +extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess] +extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi alization instead [-Werror=class-memaccess] +extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess] +extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi alization instead [-Werror=class-memaccess] +extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess] +extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi alization instead [-Werror=class-memaccess] +extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess] +extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi alization instead [-Werror=class-memaccess] +extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess] +extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi alization instead [-Werror=class-memaccess] +extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess] +extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi alization instead [-Werror=class-memaccess] +extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess] +extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi alization instead [-Werror=class-memaccess] + +service/resource-encapsulation/unittests/ResourceClientTest.cpp:243:67: error: 'VALUE' is not captured +extlibs/hippomocks/hippomocks/HippoMocks/hippomocks.h:1609:15: error: void value not ignored as it ought to be e.g. rapidjson one is tracked upstream: https://github.com/Tencent/rapidjson/issues/1205 for other issues I have a work around, but not good enough to submit for meta-oic. > > > 5) nativesdk-libxcrypt fails to build (not sure which change caused > > this, it build OK with sumo since the -std=gnu99 addition. > > ../git/crypt-sunmd5.c:189:13: error: 'snprintf' output may be truncated > > before the last format character [-Werror=format-truncation=] > > "$" CRYPT_ALGNAME "," ROUNDS "%u$%s$", > > ^~~ > > > > something new, I will look into reproducing this. > > > 6) couple internal components which usually fail to build with gcc8, > > because of more strict warnings + Werror. > > OK, feel free to send out question if you get stuck > > > > > I didn't get very far in testing, because our old kernel fails to build > > with gcc8 and there are some other issues caused by other master > > changes. But it doesn't look too bad (in my small test, lets see what > > bitbake world will show), thanks a lot for new gcc. > > > > yes, older kernel needs fixes, especially to disable new warnings. > the mips/ppc fixes that I put out there might be helpful to cook up > fixes for older kernels if running into same issues. In this case it fails with Error: .err encountered for many drivers. It's not the same case as in: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/325615.html nor arm version of this change, both are already applied in our 4.4.3 based kernel. I've tried to reproduce with vanilla 4.4.143 and it doesn't fail like this, vanilla 4.4.3 doesn't fail, so it's caused by one of our 10000 commits on top of 4.4.3 or the config, need to dig a bit more. > > Cheers, > > > > > > > > > > > > On Sat, May 5, 2018 at 2:26 AM, Khem Raj <raj.khem@gmail.com > > <mailto:raj.khem@gmail.com>> wrote: > > > > Hi All > > > > As you might have noticed that gcc 8.1 was released this week, I am > > calling out for some testing help on testing branch so we can weed out > > issues you might see in your setups. so if you have your > > builders idling over weekend, then you know what they can do this > > weekend :) > > > > Highlighted changes are > > > > https://gcc.gnu.org/gcc-8/changes.html > > <https://gcc.gnu.org/gcc-8/changes.html> > > > > and porting doc is > > > > https://gcc.gnu.org/gcc-8/porting_to.html > > <https://gcc.gnu.org/gcc-8/porting_to.html> > > > > The branch is here > > > > http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8 > > <http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8> > > > > Its uptodate on top of current master oe-core > > > > May fourth be with you !! > > > > Cheers! > > > > -Khem > > -- > > _______________________________________________ > > Openembedded-core mailing list > > Openembedded-core@lists.openembedded.org > > <mailto:Openembedded-core@lists.openembedded.org> > > http://lists.openembedded.org/mailman/listinfo/openembedded-core > > <http://lists.openembedded.org/mailman/listinfo/openembedded-core> > > > > -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 201 bytes --] ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFT] GCC 8.1 @ 2018-05-10 19:11 ` Martin Jansa 0 siblings, 0 replies; 74+ messages in thread From: Martin Jansa @ 2018-05-10 19:11 UTC (permalink / raw) To: Khem Raj Cc: Yocto Project, openembeded-devel, Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 11927 bytes --] On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote: > Hi Martin > > Thanks for testing and reporting back > > On 5/9/18 2:38 AM, Martin Jansa wrote: > > My initial tests show couple issues, but usually caused by other changes > > in that branch, not the gcc-8 itself. > > > > 1) strace-4.22 from > > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654 > > fails to build with ptest enabled (it builds with 4.20 version if I > > revert this change) > > ../../strace-4.22/tests/inject-nf.c: In function 'main': > > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in > > asm here > > } > > ^ > > are you targeting thumb1 ? how can I reproduce it ? I'm trying to find out what's different in the builds where it was failing, will provide more info later. > > Makefile:6313: recipe for target 'inject-nf.o' failed > > make: *** [inject-nf.o] Error 1 > > make: Leaving directory 'strace/4.22-r0/build/tests' > > > > 2) glibc with obsolete rpc disabled from: > > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=0cd820424d4bdb5cc68e7503e09a0359fd21150a > > causes busybox's mount applet to fail building: > > util-linux/mount.c:252:11: fatal error: rpc/rpc.h: No such file or directory > > # include <rpc/rpc.h> > > ^~~~~~~~~~~ > > compilation terminated. > > make[1]: *** [util-linux/mount.o] Error 1 > > make: *** [util-linux] Error 2 > > I think you sent a patch already for this so discussion for fix are on > going. > > > > > 3) grub and grub-efi fails to build with gcc8: > > In file included from ../grub-2.02/grub-core/partmap/gpt.c:26: > > ../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of > > 'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned] > > } GRUB_PACKED; > > ^ > > In file included from ../grub-2.02/grub-core/disk/ldm.c:26: > > ../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of > > 'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned] > > } GRUB_PACKED; > > ^ > > .. > > ../grub-2.02/grub-core/fs/btrfs.c:186:1: error: alignment 1 of 'struct > > grub_btrfs_inode' is less than 4 [-Werror=packed-not-aligned] > > } GRUB_PACKED; > > ^ > > > > I think we need to align end of these structs here, can you try > https://src.fedoraproject.org/rpms/grub2/raw/master/f/0198-align-struct-efi_variable-better.patch I've sent fix as well: http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150587.html it's in master-next already. > > 4) iotivity fails to build with gcc8: > > service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp: > > In lambda function: > > service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp:164:30: > > error: 'value' is not captured > > ocRep[KEY] = value; > > ^~~~~ > > > > this needs more investigation. May be move > https://github.com/iotivity/iotivity/blob/master/service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp#L160 > > just above > https://github.com/iotivity/iotivity/blob/master/service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp#L165 There are more issues in iotivity: +extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess] +extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi alization instead [-Werror=class-memaccess] +extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess] +extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi alization instead [-Werror=class-memaccess] +extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess] +extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi alization instead [-Werror=class-memaccess] +extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess] +extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi alization instead [-Werror=class-memaccess] +extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess] +extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi alization instead [-Werror=class-memaccess] +extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess] +extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi alization instead [-Werror=class-memaccess] +extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use copy-assignment instead [-Werror=class-memaccess] +extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; use copy-assignment or copy-initi alization instead [-Werror=class-memaccess] + +service/resource-encapsulation/unittests/ResourceClientTest.cpp:243:67: error: 'VALUE' is not captured +extlibs/hippomocks/hippomocks/HippoMocks/hippomocks.h:1609:15: error: void value not ignored as it ought to be e.g. rapidjson one is tracked upstream: https://github.com/Tencent/rapidjson/issues/1205 for other issues I have a work around, but not good enough to submit for meta-oic. > > > 5) nativesdk-libxcrypt fails to build (not sure which change caused > > this, it build OK with sumo since the -std=gnu99 addition. > > ../git/crypt-sunmd5.c:189:13: error: 'snprintf' output may be truncated > > before the last format character [-Werror=format-truncation=] > > "$" CRYPT_ALGNAME "," ROUNDS "%u$%s$", > > ^~~ > > > > something new, I will look into reproducing this. > > > 6) couple internal components which usually fail to build with gcc8, > > because of more strict warnings + Werror. > > OK, feel free to send out question if you get stuck > > > > > I didn't get very far in testing, because our old kernel fails to build > > with gcc8 and there are some other issues caused by other master > > changes. But it doesn't look too bad (in my small test, lets see what > > bitbake world will show), thanks a lot for new gcc. > > > > yes, older kernel needs fixes, especially to disable new warnings. > the mips/ppc fixes that I put out there might be helpful to cook up > fixes for older kernels if running into same issues. In this case it fails with Error: .err encountered for many drivers. It's not the same case as in: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/325615.html nor arm version of this change, both are already applied in our 4.4.3 based kernel. I've tried to reproduce with vanilla 4.4.143 and it doesn't fail like this, vanilla 4.4.3 doesn't fail, so it's caused by one of our 10000 commits on top of 4.4.3 or the config, need to dig a bit more. > > Cheers, > > > > > > > > > > > > On Sat, May 5, 2018 at 2:26 AM, Khem Raj <raj.khem@gmail.com > > <mailto:raj.khem@gmail.com>> wrote: > > > > Hi All > > > > As you might have noticed that gcc 8.1 was released this week, I am > > calling out for some testing help on testing branch so we can weed out > > issues you might see in your setups. so if you have your > > builders idling over weekend, then you know what they can do this > > weekend :) > > > > Highlighted changes are > > > > https://gcc.gnu.org/gcc-8/changes.html > > <https://gcc.gnu.org/gcc-8/changes.html> > > > > and porting doc is > > > > https://gcc.gnu.org/gcc-8/porting_to.html > > <https://gcc.gnu.org/gcc-8/porting_to.html> > > > > The branch is here > > > > http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8 > > <http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8> > > > > Its uptodate on top of current master oe-core > > > > May fourth be with you !! > > > > Cheers! > > > > -Khem > > -- > > _______________________________________________ > > Openembedded-core mailing list > > Openembedded-core@lists.openembedded.org > > <mailto:Openembedded-core@lists.openembedded.org> > > http://lists.openembedded.org/mailman/listinfo/openembedded-core > > <http://lists.openembedded.org/mailman/listinfo/openembedded-core> > > > > -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 201 bytes --] ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [OE-core] [RFT] GCC 8.1 2018-05-10 19:11 ` Martin Jansa @ 2018-05-10 19:27 ` Andre McCurdy -1 siblings, 0 replies; 74+ messages in thread From: Andre McCurdy @ 2018-05-10 19:27 UTC (permalink / raw) To: Martin Jansa Cc: Yocto Project, Patches and discussions about the oe-core layer, openembeded-devel On Thu, May 10, 2018 at 12:11 PM, Martin Jansa <martin.jansa@gmail.com> wrote: > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote: >> Hi Martin >> >> Thanks for testing and reporting back >> >> On 5/9/18 2:38 AM, Martin Jansa wrote: >> > My initial tests show couple issues, but usually caused by other changes >> > in that branch, not the gcc-8 itself. >> > >> > 1) strace-4.22 from >> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654 >> > fails to build with ptest enabled (it builds with 4.20 version if I >> > revert this change) >> > ../../strace-4.22/tests/inject-nf.c: In function 'main': >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in >> > asm here >> > } >> > ^ >> >> are you targeting thumb1 ? how can I reproduce it ? > > I'm trying to find out what's different in the builds where it was > failing, will provide more info later. This is probably due to making an inline syscall from Thumb (doesn't a matter Thumb1 or Thumb2) with frame pointers enabled. Does adding -fomit-frame-pointer to CFLAGS fix it? ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFT] GCC 8.1 @ 2018-05-10 19:27 ` Andre McCurdy 0 siblings, 0 replies; 74+ messages in thread From: Andre McCurdy @ 2018-05-10 19:27 UTC (permalink / raw) To: Martin Jansa Cc: Yocto Project, Patches and discussions about the oe-core layer, openembeded-devel On Thu, May 10, 2018 at 12:11 PM, Martin Jansa <martin.jansa@gmail.com> wrote: > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote: >> Hi Martin >> >> Thanks for testing and reporting back >> >> On 5/9/18 2:38 AM, Martin Jansa wrote: >> > My initial tests show couple issues, but usually caused by other changes >> > in that branch, not the gcc-8 itself. >> > >> > 1) strace-4.22 from >> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654 >> > fails to build with ptest enabled (it builds with 4.20 version if I >> > revert this change) >> > ../../strace-4.22/tests/inject-nf.c: In function 'main': >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in >> > asm here >> > } >> > ^ >> >> are you targeting thumb1 ? how can I reproduce it ? > > I'm trying to find out what's different in the builds where it was > failing, will provide more info later. This is probably due to making an inline syscall from Thumb (doesn't a matter Thumb1 or Thumb2) with frame pointers enabled. Does adding -fomit-frame-pointer to CFLAGS fix it? ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [OE-core] [RFT] GCC 8.1 2018-05-10 19:27 ` Andre McCurdy @ 2018-05-10 21:43 ` Martin Jansa -1 siblings, 0 replies; 74+ messages in thread From: Martin Jansa @ 2018-05-10 21:43 UTC (permalink / raw) To: Andre McCurdy Cc: Yocto Project, Patches and discussions about the oe-core layer, openembeded-devel [-- Attachment #1: Type: text/plain, Size: 3130 bytes --] On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote: > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa <martin.jansa@gmail.com> wrote: > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote: > >> Hi Martin > >> > >> Thanks for testing and reporting back > >> > >> On 5/9/18 2:38 AM, Martin Jansa wrote: > >> > My initial tests show couple issues, but usually caused by other changes > >> > in that branch, not the gcc-8 itself. > >> > > >> > 1) strace-4.22 from > >> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654 > >> > fails to build with ptest enabled (it builds with 4.20 version if I > >> > revert this change) > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main': > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in > >> > asm here > >> > } > >> > ^ > >> > >> are you targeting thumb1 ? how can I reproduce it ? > > > > I'm trying to find out what's different in the builds where it was > > failing, will provide more info later. > > This is probably due to making an inline syscall from Thumb (doesn't a > matter Thumb1 or Thumb2) with frame pointers enabled. > > Does adding -fomit-frame-pointer to CFLAGS fix it? It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is already -fno-omit-frame-pointer in the default command line for it, adding -fomit-frame-pointer at the end fixes it: docker-lge @ ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests $ arm-webos-linux-gnueabi-gcc -march=armv7ve -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot -DHAVE_CONFIG_H -I. -I../linux/arm -I../../strace-4.22/linux/arm -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22 -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4 -Wall -Wempty-body -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self -Wlogical-op -Wmissing-parameter-type -Wnested-externs -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits -Wwrite-strings -O -fno-omit-frame-pointer -g -feliminate-unused-debug-types -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0 -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot= -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native= -pipe -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c -fomit-frame-pointer This might come from: meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe" because in this build I had DEBUG_BUILD enabled. Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as well now. Thanks for pointers. -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 201 bytes --] ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFT] GCC 8.1 @ 2018-05-10 21:43 ` Martin Jansa 0 siblings, 0 replies; 74+ messages in thread From: Martin Jansa @ 2018-05-10 21:43 UTC (permalink / raw) To: Andre McCurdy Cc: Yocto Project, Patches and discussions about the oe-core layer, openembeded-devel [-- Attachment #1: Type: text/plain, Size: 3130 bytes --] On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote: > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa <martin.jansa@gmail.com> wrote: > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote: > >> Hi Martin > >> > >> Thanks for testing and reporting back > >> > >> On 5/9/18 2:38 AM, Martin Jansa wrote: > >> > My initial tests show couple issues, but usually caused by other changes > >> > in that branch, not the gcc-8 itself. > >> > > >> > 1) strace-4.22 from > >> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654 > >> > fails to build with ptest enabled (it builds with 4.20 version if I > >> > revert this change) > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main': > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in > >> > asm here > >> > } > >> > ^ > >> > >> are you targeting thumb1 ? how can I reproduce it ? > > > > I'm trying to find out what's different in the builds where it was > > failing, will provide more info later. > > This is probably due to making an inline syscall from Thumb (doesn't a > matter Thumb1 or Thumb2) with frame pointers enabled. > > Does adding -fomit-frame-pointer to CFLAGS fix it? It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is already -fno-omit-frame-pointer in the default command line for it, adding -fomit-frame-pointer at the end fixes it: docker-lge @ ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests $ arm-webos-linux-gnueabi-gcc -march=armv7ve -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot -DHAVE_CONFIG_H -I. -I../linux/arm -I../../strace-4.22/linux/arm -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22 -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4 -Wall -Wempty-body -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self -Wlogical-op -Wmissing-parameter-type -Wnested-externs -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits -Wwrite-strings -O -fno-omit-frame-pointer -g -feliminate-unused-debug-types -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0 -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot= -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native= -pipe -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c -fomit-frame-pointer This might come from: meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe" because in this build I had DEBUG_BUILD enabled. Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as well now. Thanks for pointers. -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 201 bytes --] ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [OE-core] [RFT] GCC 8.1 2018-05-10 21:43 ` Martin Jansa @ 2018-05-10 22:07 ` Martin Jansa -1 siblings, 0 replies; 74+ messages in thread From: Martin Jansa @ 2018-05-10 22:07 UTC (permalink / raw) To: Andre McCurdy Cc: Yocto Project, Patches and discussions about the oe-core layer, openembeded-devel [-- Attachment #1: Type: text/plain, Size: 3597 bytes --] On Thu, May 10, 2018 at 11:43:25PM +0200, Martin Jansa wrote: > On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote: > > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa <martin.jansa@gmail.com> wrote: > > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote: > > >> Hi Martin > > >> > > >> Thanks for testing and reporting back > > >> > > >> On 5/9/18 2:38 AM, Martin Jansa wrote: > > >> > My initial tests show couple issues, but usually caused by other changes > > >> > in that branch, not the gcc-8 itself. > > >> > > > >> > 1) strace-4.22 from > > >> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654 > > >> > fails to build with ptest enabled (it builds with 4.20 version if I > > >> > revert this change) > > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main': > > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in > > >> > asm here > > >> > } > > >> > ^ > > >> > > >> are you targeting thumb1 ? how can I reproduce it ? > > > > > > I'm trying to find out what's different in the builds where it was > > > failing, will provide more info later. > > > > This is probably due to making an inline syscall from Thumb (doesn't a > > matter Thumb1 or Thumb2) with frame pointers enabled. > > > > Does adding -fomit-frame-pointer to CFLAGS fix it? > > It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is > already -fno-omit-frame-pointer in the default command line for it, > adding -fomit-frame-pointer at the end fixes it: > > docker-lge @ ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests $ arm-webos-linux-gnueabi-gcc -march=armv7ve -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot -DHAVE_CONFIG_H -I. -I../linux/arm -I../../strace-4.22/linux/arm -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22 -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4 -Wall -Wempty-body -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self -Wlogical-op -Wmissing-parameter-type -Wnested-externs -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits -Wwrite-strings -O -fno-omit-frame-pointer -g -feliminate-unused-debug-types -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0 -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot= -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native= -pipe -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c -fomit-frame-pointer > > This might come from: > meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe" > because in this build I had DEBUG_BUILD enabled. > > Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as well now. 4.20 doesn't fail with DEBUG_BUILD, because inject-nf.c test is new in 4.22: https://github.com/strace/strace/commit/58598cd7f6e23e531d71bfe5a4e35f898a4f3b2d#diff-dc01d20c1e55f8adf7536cb46d4481e1 What is preferred fix for this? Is adding -fomit-frame-pointer to CFLAGS when ptest is in DISTRO_FEATURES acceptable solution? Regards, -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 201 bytes --] ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFT] GCC 8.1 @ 2018-05-10 22:07 ` Martin Jansa 0 siblings, 0 replies; 74+ messages in thread From: Martin Jansa @ 2018-05-10 22:07 UTC (permalink / raw) To: Andre McCurdy Cc: Yocto Project, Patches and discussions about the oe-core layer, openembeded-devel [-- Attachment #1: Type: text/plain, Size: 3597 bytes --] On Thu, May 10, 2018 at 11:43:25PM +0200, Martin Jansa wrote: > On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote: > > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa <martin.jansa@gmail.com> wrote: > > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote: > > >> Hi Martin > > >> > > >> Thanks for testing and reporting back > > >> > > >> On 5/9/18 2:38 AM, Martin Jansa wrote: > > >> > My initial tests show couple issues, but usually caused by other changes > > >> > in that branch, not the gcc-8 itself. > > >> > > > >> > 1) strace-4.22 from > > >> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654 > > >> > fails to build with ptest enabled (it builds with 4.20 version if I > > >> > revert this change) > > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main': > > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in > > >> > asm here > > >> > } > > >> > ^ > > >> > > >> are you targeting thumb1 ? how can I reproduce it ? > > > > > > I'm trying to find out what's different in the builds where it was > > > failing, will provide more info later. > > > > This is probably due to making an inline syscall from Thumb (doesn't a > > matter Thumb1 or Thumb2) with frame pointers enabled. > > > > Does adding -fomit-frame-pointer to CFLAGS fix it? > > It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is > already -fno-omit-frame-pointer in the default command line for it, > adding -fomit-frame-pointer at the end fixes it: > > docker-lge @ ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests $ arm-webos-linux-gnueabi-gcc -march=armv7ve -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot -DHAVE_CONFIG_H -I. -I../linux/arm -I../../strace-4.22/linux/arm -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22 -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4 -Wall -Wempty-body -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self -Wlogical-op -Wmissing-parameter-type -Wnested-externs -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits -Wwrite-strings -O -fno-omit-frame-pointer -g -feliminate-unused-debug-types -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0 -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot= -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native= -pipe -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c -fomit-frame-pointer > > This might come from: > meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe" > because in this build I had DEBUG_BUILD enabled. > > Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as well now. 4.20 doesn't fail with DEBUG_BUILD, because inject-nf.c test is new in 4.22: https://github.com/strace/strace/commit/58598cd7f6e23e531d71bfe5a4e35f898a4f3b2d#diff-dc01d20c1e55f8adf7536cb46d4481e1 What is preferred fix for this? Is adding -fomit-frame-pointer to CFLAGS when ptest is in DISTRO_FEATURES acceptable solution? Regards, -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 201 bytes --] ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [OE-core] [RFT] GCC 8.1 2018-05-10 22:07 ` Martin Jansa @ 2018-05-10 22:35 ` Khem Raj -1 siblings, 0 replies; 74+ messages in thread From: Khem Raj @ 2018-05-10 22:35 UTC (permalink / raw) To: Martin Jansa Cc: Yocto Project, openembeded-devel, Patches and discussions about the oe-core layer On Thu, May 10, 2018 at 3:07 PM, Martin Jansa <martin.jansa@gmail.com> wrote: > On Thu, May 10, 2018 at 11:43:25PM +0200, Martin Jansa wrote: >> On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote: >> > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >> > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote: >> > >> Hi Martin >> > >> >> > >> Thanks for testing and reporting back >> > >> >> > >> On 5/9/18 2:38 AM, Martin Jansa wrote: >> > >> > My initial tests show couple issues, but usually caused by other changes >> > >> > in that branch, not the gcc-8 itself. >> > >> > >> > >> > 1) strace-4.22 from >> > >> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654 >> > >> > fails to build with ptest enabled (it builds with 4.20 version if I >> > >> > revert this change) >> > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main': >> > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in >> > >> > asm here >> > >> > } >> > >> > ^ >> > >> >> > >> are you targeting thumb1 ? how can I reproduce it ? >> > > >> > > I'm trying to find out what's different in the builds where it was >> > > failing, will provide more info later. >> > >> > This is probably due to making an inline syscall from Thumb (doesn't a >> > matter Thumb1 or Thumb2) with frame pointers enabled. >> > >> > Does adding -fomit-frame-pointer to CFLAGS fix it? >> >> It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is >> already -fno-omit-frame-pointer in the default command line for it, >> adding -fomit-frame-pointer at the end fixes it: >> >> docker-lge @ ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests $ arm-webos-linux-gnueabi-gcc -march=armv7ve -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot -DHAVE_CONFIG_H -I. -I../linux/arm -I../../strace-4.22/linux/arm -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22 -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4 -Wall -Wempty-body -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self -Wlogical-op -Wmissing-parameter-type -Wnested-externs -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits -Wwrite-strings -O -fno-omit-frame-pointer -g -feliminate-unused-debug-types -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0 -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot= -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native= -pipe -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c -fomit-frame-pointer >> >> This might come from: >> meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe" >> because in this build I had DEBUG_BUILD enabled. >> >> Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as well now. > > 4.20 doesn't fail with DEBUG_BUILD, because inject-nf.c test is new in > 4.22: > > https://github.com/strace/strace/commit/58598cd7f6e23e531d71bfe5a4e35f898a4f3b2d#diff-dc01d20c1e55f8adf7536cb46d4481e1 > > What is preferred fix for this? Is adding -fomit-frame-pointer to CFLAGS > when ptest is in DISTRO_FEATURES acceptable solution? you might want to _remove operation for -fno-omit-frame-pointer for SELECTED_OPTIMIZATION variable. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFT] GCC 8.1 @ 2018-05-10 22:35 ` Khem Raj 0 siblings, 0 replies; 74+ messages in thread From: Khem Raj @ 2018-05-10 22:35 UTC (permalink / raw) To: Martin Jansa Cc: Yocto Project, openembeded-devel, Patches and discussions about the oe-core layer On Thu, May 10, 2018 at 3:07 PM, Martin Jansa <martin.jansa@gmail.com> wrote: > On Thu, May 10, 2018 at 11:43:25PM +0200, Martin Jansa wrote: >> On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote: >> > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >> > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote: >> > >> Hi Martin >> > >> >> > >> Thanks for testing and reporting back >> > >> >> > >> On 5/9/18 2:38 AM, Martin Jansa wrote: >> > >> > My initial tests show couple issues, but usually caused by other changes >> > >> > in that branch, not the gcc-8 itself. >> > >> > >> > >> > 1) strace-4.22 from >> > >> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654 >> > >> > fails to build with ptest enabled (it builds with 4.20 version if I >> > >> > revert this change) >> > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main': >> > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in >> > >> > asm here >> > >> > } >> > >> > ^ >> > >> >> > >> are you targeting thumb1 ? how can I reproduce it ? >> > > >> > > I'm trying to find out what's different in the builds where it was >> > > failing, will provide more info later. >> > >> > This is probably due to making an inline syscall from Thumb (doesn't a >> > matter Thumb1 or Thumb2) with frame pointers enabled. >> > >> > Does adding -fomit-frame-pointer to CFLAGS fix it? >> >> It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is >> already -fno-omit-frame-pointer in the default command line for it, >> adding -fomit-frame-pointer at the end fixes it: >> >> docker-lge @ ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests $ arm-webos-linux-gnueabi-gcc -march=armv7ve -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot -DHAVE_CONFIG_H -I. -I../linux/arm -I../../strace-4.22/linux/arm -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22 -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4 -Wall -Wempty-body -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self -Wlogical-op -Wmissing-parameter-type -Wnested-externs -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits -Wwrite-strings -O -fno-omit-frame-pointer -g -feliminate-unused-debug-types -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0 -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot= -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native= -pipe -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c -fomit-frame-pointer >> >> This might come from: >> meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe" >> because in this build I had DEBUG_BUILD enabled. >> >> Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as well now. > > 4.20 doesn't fail with DEBUG_BUILD, because inject-nf.c test is new in > 4.22: > > https://github.com/strace/strace/commit/58598cd7f6e23e531d71bfe5a4e35f898a4f3b2d#diff-dc01d20c1e55f8adf7536cb46d4481e1 > > What is preferred fix for this? Is adding -fomit-frame-pointer to CFLAGS > when ptest is in DISTRO_FEATURES acceptable solution? you might want to _remove operation for -fno-omit-frame-pointer for SELECTED_OPTIMIZATION variable. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [OE-core] [RFT] GCC 8.1 2018-05-10 22:07 ` Martin Jansa @ 2018-05-10 22:38 ` Andre McCurdy -1 siblings, 0 replies; 74+ messages in thread From: Andre McCurdy @ 2018-05-10 22:38 UTC (permalink / raw) To: Martin Jansa Cc: Yocto Project, Patches and discussions about the oe-core layer, openembeded-devel On Thu, May 10, 2018 at 3:07 PM, Martin Jansa <martin.jansa@gmail.com> wrote: > On Thu, May 10, 2018 at 11:43:25PM +0200, Martin Jansa wrote: >> On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote: >> > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >> > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote: >> > >> Hi Martin >> > >> >> > >> Thanks for testing and reporting back >> > >> >> > >> On 5/9/18 2:38 AM, Martin Jansa wrote: >> > >> > My initial tests show couple issues, but usually caused by other changes >> > >> > in that branch, not the gcc-8 itself. >> > >> > >> > >> > 1) strace-4.22 from >> > >> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654 >> > >> > fails to build with ptest enabled (it builds with 4.20 version if I >> > >> > revert this change) >> > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main': >> > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in >> > >> > asm here >> > >> > } >> > >> > ^ >> > >> >> > >> are you targeting thumb1 ? how can I reproduce it ? >> > > >> > > I'm trying to find out what's different in the builds where it was >> > > failing, will provide more info later. >> > >> > This is probably due to making an inline syscall from Thumb (doesn't a >> > matter Thumb1 or Thumb2) with frame pointers enabled. >> > >> > Does adding -fomit-frame-pointer to CFLAGS fix it? >> >> It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is >> already -fno-omit-frame-pointer in the default command line for it, >> adding -fomit-frame-pointer at the end fixes it: >> >> docker-lge @ ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests $ arm-webos-linux-gnueabi-gcc -march=armv7ve -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot -DHAVE_CONFIG_H -I. -I../linux/arm -I../../strace-4.22/linux/arm -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22 -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4 -Wall -Wempty-body -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self -Wlogical-op -Wmissing-parameter-type -Wnested-externs -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits -Wwrite-strings -O -fno-omit-frame-pointer -g -feliminate-unused-debug-types -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0 -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot= -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native= -pipe -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c -fomit-frame-pointer >> >> This might come from: >> meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe" >> because in this build I had DEBUG_BUILD enabled. >> >> Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as well now. > > 4.20 doesn't fail with DEBUG_BUILD, because inject-nf.c test is new in > 4.22: > > https://github.com/strace/strace/commit/58598cd7f6e23e531d71bfe5a4e35f898a4f3b2d#diff-dc01d20c1e55f8adf7536cb46d4481e1 > > What is preferred fix for this? Is adding -fomit-frame-pointer to CFLAGS > when ptest is in DISTRO_FEATURES acceptable solution? I would say unconditionally adding -fomit-frame-pointer to CFLAGS for all builds is OK (strace is a debug tool - not something that generally needs to be debugged and frame pointers aren't essential for debugging anyway). ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFT] GCC 8.1 @ 2018-05-10 22:38 ` Andre McCurdy 0 siblings, 0 replies; 74+ messages in thread From: Andre McCurdy @ 2018-05-10 22:38 UTC (permalink / raw) To: Martin Jansa Cc: Yocto Project, Patches and discussions about the oe-core layer, openembeded-devel On Thu, May 10, 2018 at 3:07 PM, Martin Jansa <martin.jansa@gmail.com> wrote: > On Thu, May 10, 2018 at 11:43:25PM +0200, Martin Jansa wrote: >> On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote: >> > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >> > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote: >> > >> Hi Martin >> > >> >> > >> Thanks for testing and reporting back >> > >> >> > >> On 5/9/18 2:38 AM, Martin Jansa wrote: >> > >> > My initial tests show couple issues, but usually caused by other changes >> > >> > in that branch, not the gcc-8 itself. >> > >> > >> > >> > 1) strace-4.22 from >> > >> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654 >> > >> > fails to build with ptest enabled (it builds with 4.20 version if I >> > >> > revert this change) >> > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main': >> > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in >> > >> > asm here >> > >> > } >> > >> > ^ >> > >> >> > >> are you targeting thumb1 ? how can I reproduce it ? >> > > >> > > I'm trying to find out what's different in the builds where it was >> > > failing, will provide more info later. >> > >> > This is probably due to making an inline syscall from Thumb (doesn't a >> > matter Thumb1 or Thumb2) with frame pointers enabled. >> > >> > Does adding -fomit-frame-pointer to CFLAGS fix it? >> >> It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is >> already -fno-omit-frame-pointer in the default command line for it, >> adding -fomit-frame-pointer at the end fixes it: >> >> docker-lge @ ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests $ arm-webos-linux-gnueabi-gcc -march=armv7ve -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot -DHAVE_CONFIG_H -I. -I../linux/arm -I../../strace-4.22/linux/arm -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22 -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4 -Wall -Wempty-body -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self -Wlogical-op -Wmissing-parameter-type -Wnested-externs -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits -Wwrite-strings -O -fno-omit-frame-pointer -g -feliminate-unused-debug-types -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0 -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot= -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native= -pipe -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c -fomit-frame-pointer >> >> This might come from: >> meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe" >> because in this build I had DEBUG_BUILD enabled. >> >> Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as well now. > > 4.20 doesn't fail with DEBUG_BUILD, because inject-nf.c test is new in > 4.22: > > https://github.com/strace/strace/commit/58598cd7f6e23e531d71bfe5a4e35f898a4f3b2d#diff-dc01d20c1e55f8adf7536cb46d4481e1 > > What is preferred fix for this? Is adding -fomit-frame-pointer to CFLAGS > when ptest is in DISTRO_FEATURES acceptable solution? I would say unconditionally adding -fomit-frame-pointer to CFLAGS for all builds is OK (strace is a debug tool - not something that generally needs to be debugged and frame pointers aren't essential for debugging anyway). ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [OE-core] [RFT] GCC 8.1 2018-05-10 22:38 ` Andre McCurdy (?) @ 2018-05-10 22:38 ` Martin Jansa -1 siblings, 0 replies; 74+ messages in thread From: Martin Jansa @ 2018-05-10 22:38 UTC (permalink / raw) To: Andre McCurdy Cc: Yocto Project, Patches and discussions about the oe-core layer, openembedded-devel [-- Attachment #1: Type: text/plain, Size: 4242 bytes --] see http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html On Fri, May 11, 2018 at 12:38 AM Andre McCurdy <armccurdy@gmail.com> wrote: > On Thu, May 10, 2018 at 3:07 PM, Martin Jansa <martin.jansa@gmail.com> > wrote: > > On Thu, May 10, 2018 at 11:43:25PM +0200, Martin Jansa wrote: > >> On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote: > >> > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa < > martin.jansa@gmail.com> wrote: > >> > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote: > >> > >> Hi Martin > >> > >> > >> > >> Thanks for testing and reporting back > >> > >> > >> > >> On 5/9/18 2:38 AM, Martin Jansa wrote: > >> > >> > My initial tests show couple issues, but usually caused by other > changes > >> > >> > in that branch, not the gcc-8 itself. > >> > >> > > >> > >> > 1) strace-4.22 from > >> > >> > > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654 > >> > >> > fails to build with ptest enabled (it builds with 4.20 version > if I > >> > >> > revert this change) > >> > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main': > >> > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be > used in > >> > >> > asm here > >> > >> > } > >> > >> > ^ > >> > >> > >> > >> are you targeting thumb1 ? how can I reproduce it ? > >> > > > >> > > I'm trying to find out what's different in the builds where it was > >> > > failing, will provide more info later. > >> > > >> > This is probably due to making an inline syscall from Thumb (doesn't a > >> > matter Thumb1 or Thumb2) with frame pointers enabled. > >> > > >> > Does adding -fomit-frame-pointer to CFLAGS fix it? > >> > >> It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is > >> already -fno-omit-frame-pointer in the default command line for it, > >> adding -fomit-frame-pointer at the end fixes it: > >> > >> docker-lge @ > ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests > $ arm-webos-linux-gnueabi-gcc -march=armv7ve -mthumb -mfpu=neon-vfpv4 > -mfloat-abi=hard -mcpu=cortex-a7 > --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot > -DHAVE_CONFIG_H -I. -I../linux/arm -I../../strace-4.22/linux/arm > -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22 > -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4 -Wall -Wempty-body > -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self > -Wlogical-op -Wmissing-parameter-type -Wnested-externs > -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits > -Wwrite-strings -O -fno-omit-frame-pointer -g > -feliminate-unused-debug-types > -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0 > -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot= > -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native= > -pipe -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c > -fomit-frame-pointer > >> > >> This might come from: > >> meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer > ${DEBUG_FLAGS} -pipe" > >> because in this build I had DEBUG_BUILD enabled. > >> > >> Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as > well now. > > > > 4.20 doesn't fail with DEBUG_BUILD, because inject-nf.c test is new in > > 4.22: > > > > > https://github.com/strace/strace/commit/58598cd7f6e23e531d71bfe5a4e35f898a4f3b2d#diff-dc01d20c1e55f8adf7536cb46d4481e1 > > > > What is preferred fix for this? Is adding -fomit-frame-pointer to CFLAGS > > when ptest is in DISTRO_FEATURES acceptable solution? > > I would say unconditionally adding -fomit-frame-pointer to CFLAGS for > all builds is OK (strace is a debug tool - not something that > generally needs to be debugged and frame pointers aren't essential for > debugging anyway). > [-- Attachment #2: Type: text/html, Size: 5654 bytes --] ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [OE-core] [RFT] GCC 8.1 @ 2018-05-10 22:38 ` Martin Jansa 0 siblings, 0 replies; 74+ messages in thread From: Martin Jansa @ 2018-05-10 22:38 UTC (permalink / raw) To: Andre McCurdy Cc: Yocto Project, Patches and discussions about the oe-core layer, openembedded-devel see http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html On Fri, May 11, 2018 at 12:38 AM Andre McCurdy <armccurdy@gmail.com> wrote: > On Thu, May 10, 2018 at 3:07 PM, Martin Jansa <martin.jansa@gmail.com> > wrote: > > On Thu, May 10, 2018 at 11:43:25PM +0200, Martin Jansa wrote: > >> On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote: > >> > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa < > martin.jansa@gmail.com> wrote: > >> > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote: > >> > >> Hi Martin > >> > >> > >> > >> Thanks for testing and reporting back > >> > >> > >> > >> On 5/9/18 2:38 AM, Martin Jansa wrote: > >> > >> > My initial tests show couple issues, but usually caused by other > changes > >> > >> > in that branch, not the gcc-8 itself. > >> > >> > > >> > >> > 1) strace-4.22 from > >> > >> > > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654 > >> > >> > fails to build with ptest enabled (it builds with 4.20 version > if I > >> > >> > revert this change) > >> > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main': > >> > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be > used in > >> > >> > asm here > >> > >> > } > >> > >> > ^ > >> > >> > >> > >> are you targeting thumb1 ? how can I reproduce it ? > >> > > > >> > > I'm trying to find out what's different in the builds where it was > >> > > failing, will provide more info later. > >> > > >> > This is probably due to making an inline syscall from Thumb (doesn't a > >> > matter Thumb1 or Thumb2) with frame pointers enabled. > >> > > >> > Does adding -fomit-frame-pointer to CFLAGS fix it? > >> > >> It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is > >> already -fno-omit-frame-pointer in the default command line for it, > >> adding -fomit-frame-pointer at the end fixes it: > >> > >> docker-lge @ > ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests > $ arm-webos-linux-gnueabi-gcc -march=armv7ve -mthumb -mfpu=neon-vfpv4 > -mfloat-abi=hard -mcpu=cortex-a7 > --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot > -DHAVE_CONFIG_H -I. -I../linux/arm -I../../strace-4.22/linux/arm > -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22 > -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4 -Wall -Wempty-body > -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self > -Wlogical-op -Wmissing-parameter-type -Wnested-externs > -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits > -Wwrite-strings -O -fno-omit-frame-pointer -g > -feliminate-unused-debug-types > -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0 > -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot= > -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native= > -pipe -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c > -fomit-frame-pointer > >> > >> This might come from: > >> meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer > ${DEBUG_FLAGS} -pipe" > >> because in this build I had DEBUG_BUILD enabled. > >> > >> Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as > well now. > > > > 4.20 doesn't fail with DEBUG_BUILD, because inject-nf.c test is new in > > 4.22: > > > > > https://github.com/strace/strace/commit/58598cd7f6e23e531d71bfe5a4e35f898a4f3b2d#diff-dc01d20c1e55f8adf7536cb46d4481e1 > > > > What is preferred fix for this? Is adding -fomit-frame-pointer to CFLAGS > > when ptest is in DISTRO_FEATURES acceptable solution? > > I would say unconditionally adding -fomit-frame-pointer to CFLAGS for > all builds is OK (strace is a debug tool - not something that > generally needs to be debugged and frame pointers aren't essential for > debugging anyway). > ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFT] GCC 8.1 @ 2018-05-10 22:38 ` Martin Jansa 0 siblings, 0 replies; 74+ messages in thread From: Martin Jansa @ 2018-05-10 22:38 UTC (permalink / raw) To: Andre McCurdy Cc: Yocto Project, Patches and discussions about the oe-core layer, openembedded-devel [-- Attachment #1: Type: text/plain, Size: 4242 bytes --] see http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html On Fri, May 11, 2018 at 12:38 AM Andre McCurdy <armccurdy@gmail.com> wrote: > On Thu, May 10, 2018 at 3:07 PM, Martin Jansa <martin.jansa@gmail.com> > wrote: > > On Thu, May 10, 2018 at 11:43:25PM +0200, Martin Jansa wrote: > >> On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote: > >> > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa < > martin.jansa@gmail.com> wrote: > >> > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote: > >> > >> Hi Martin > >> > >> > >> > >> Thanks for testing and reporting back > >> > >> > >> > >> On 5/9/18 2:38 AM, Martin Jansa wrote: > >> > >> > My initial tests show couple issues, but usually caused by other > changes > >> > >> > in that branch, not the gcc-8 itself. > >> > >> > > >> > >> > 1) strace-4.22 from > >> > >> > > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654 > >> > >> > fails to build with ptest enabled (it builds with 4.20 version > if I > >> > >> > revert this change) > >> > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main': > >> > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be > used in > >> > >> > asm here > >> > >> > } > >> > >> > ^ > >> > >> > >> > >> are you targeting thumb1 ? how can I reproduce it ? > >> > > > >> > > I'm trying to find out what's different in the builds where it was > >> > > failing, will provide more info later. > >> > > >> > This is probably due to making an inline syscall from Thumb (doesn't a > >> > matter Thumb1 or Thumb2) with frame pointers enabled. > >> > > >> > Does adding -fomit-frame-pointer to CFLAGS fix it? > >> > >> It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is > >> already -fno-omit-frame-pointer in the default command line for it, > >> adding -fomit-frame-pointer at the end fixes it: > >> > >> docker-lge @ > ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests > $ arm-webos-linux-gnueabi-gcc -march=armv7ve -mthumb -mfpu=neon-vfpv4 > -mfloat-abi=hard -mcpu=cortex-a7 > --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot > -DHAVE_CONFIG_H -I. -I../linux/arm -I../../strace-4.22/linux/arm > -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22 > -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4 -Wall -Wempty-body > -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self > -Wlogical-op -Wmissing-parameter-type -Wnested-externs > -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits > -Wwrite-strings -O -fno-omit-frame-pointer -g > -feliminate-unused-debug-types > -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0 > -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot= > -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native= > -pipe -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c > -fomit-frame-pointer > >> > >> This might come from: > >> meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer > ${DEBUG_FLAGS} -pipe" > >> because in this build I had DEBUG_BUILD enabled. > >> > >> Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as > well now. > > > > 4.20 doesn't fail with DEBUG_BUILD, because inject-nf.c test is new in > > 4.22: > > > > > https://github.com/strace/strace/commit/58598cd7f6e23e531d71bfe5a4e35f898a4f3b2d#diff-dc01d20c1e55f8adf7536cb46d4481e1 > > > > What is preferred fix for this? Is adding -fomit-frame-pointer to CFLAGS > > when ptest is in DISTRO_FEATURES acceptable solution? > > I would say unconditionally adding -fomit-frame-pointer to CFLAGS for > all builds is OK (strace is a debug tool - not something that > generally needs to be debugged and frame pointers aren't essential for > debugging anyway). > [-- Attachment #2: Type: text/html, Size: 5654 bytes --] ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [OE-core] [RFT] GCC 8.1 2018-05-10 22:38 ` Martin Jansa @ 2018-05-10 22:40 ` Andre McCurdy -1 siblings, 0 replies; 74+ messages in thread From: Andre McCurdy @ 2018-05-10 22:40 UTC (permalink / raw) To: Martin Jansa Cc: Yocto Project, Patches and discussions about the oe-core layer, openembedded-devel On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote: > see > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html Removing -fno-omit-frame-pointer isn't the same as adding -fomit-frame-pointer. Frame pointers may get enabled depending on the optimisation level etc (ie not only by -fno-omit-frame-pointer). > On Fri, May 11, 2018 at 12:38 AM Andre McCurdy <armccurdy@gmail.com> wrote: >> >> On Thu, May 10, 2018 at 3:07 PM, Martin Jansa <martin.jansa@gmail.com> >> wrote: >> > On Thu, May 10, 2018 at 11:43:25PM +0200, Martin Jansa wrote: >> >> On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote: >> >> > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa >> >> > <martin.jansa@gmail.com> wrote: >> >> > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote: >> >> > >> Hi Martin >> >> > >> >> >> > >> Thanks for testing and reporting back >> >> > >> >> >> > >> On 5/9/18 2:38 AM, Martin Jansa wrote: >> >> > >> > My initial tests show couple issues, but usually caused by other >> >> > >> > changes >> >> > >> > in that branch, not the gcc-8 itself. >> >> > >> > >> >> > >> > 1) strace-4.22 from >> >> > >> > >> >> > >> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654 >> >> > >> > fails to build with ptest enabled (it builds with 4.20 version >> >> > >> > if I >> >> > >> > revert this change) >> >> > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main': >> >> > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be >> >> > >> > used in >> >> > >> > asm here >> >> > >> > } >> >> > >> > ^ >> >> > >> >> >> > >> are you targeting thumb1 ? how can I reproduce it ? >> >> > > >> >> > > I'm trying to find out what's different in the builds where it was >> >> > > failing, will provide more info later. >> >> > >> >> > This is probably due to making an inline syscall from Thumb (doesn't >> >> > a >> >> > matter Thumb1 or Thumb2) with frame pointers enabled. >> >> > >> >> > Does adding -fomit-frame-pointer to CFLAGS fix it? >> >> >> >> It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is >> >> already -fno-omit-frame-pointer in the default command line for it, >> >> adding -fomit-frame-pointer at the end fixes it: >> >> >> >> docker-lge @ >> >> ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests >> >> $ arm-webos-linux-gnueabi-gcc -march=armv7ve -mthumb -mfpu=neon-vfpv4 >> >> -mfloat-abi=hard -mcpu=cortex-a7 >> >> --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot >> >> -DHAVE_CONFIG_H -I. -I../linux/arm -I../../strace-4.22/linux/arm >> >> -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22 >> >> -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4 -Wall -Wempty-body >> >> -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self >> >> -Wlogical-op -Wmissing-parameter-type -Wnested-externs >> >> -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits >> >> -Wwrite-strings -O -fno-omit-frame-pointer -g -feliminate-unused-debug-types >> >> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0 >> >> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot= >> >> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native= >> >> -pipe -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c >> >> -fomit-frame-pointer >> >> >> >> This might come from: >> >> meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer >> >> ${DEBUG_FLAGS} -pipe" >> >> because in this build I had DEBUG_BUILD enabled. >> >> >> >> Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as >> >> well now. >> > >> > 4.20 doesn't fail with DEBUG_BUILD, because inject-nf.c test is new in >> > 4.22: >> > >> > >> > https://github.com/strace/strace/commit/58598cd7f6e23e531d71bfe5a4e35f898a4f3b2d#diff-dc01d20c1e55f8adf7536cb46d4481e1 >> > >> > What is preferred fix for this? Is adding -fomit-frame-pointer to CFLAGS >> > when ptest is in DISTRO_FEATURES acceptable solution? >> >> I would say unconditionally adding -fomit-frame-pointer to CFLAGS for >> all builds is OK (strace is a debug tool - not something that >> generally needs to be debugged and frame pointers aren't essential for >> debugging anyway). ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFT] GCC 8.1 @ 2018-05-10 22:40 ` Andre McCurdy 0 siblings, 0 replies; 74+ messages in thread From: Andre McCurdy @ 2018-05-10 22:40 UTC (permalink / raw) To: Martin Jansa Cc: Yocto Project, Patches and discussions about the oe-core layer, openembedded-devel On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote: > see > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html Removing -fno-omit-frame-pointer isn't the same as adding -fomit-frame-pointer. Frame pointers may get enabled depending on the optimisation level etc (ie not only by -fno-omit-frame-pointer). > On Fri, May 11, 2018 at 12:38 AM Andre McCurdy <armccurdy@gmail.com> wrote: >> >> On Thu, May 10, 2018 at 3:07 PM, Martin Jansa <martin.jansa@gmail.com> >> wrote: >> > On Thu, May 10, 2018 at 11:43:25PM +0200, Martin Jansa wrote: >> >> On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote: >> >> > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa >> >> > <martin.jansa@gmail.com> wrote: >> >> > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote: >> >> > >> Hi Martin >> >> > >> >> >> > >> Thanks for testing and reporting back >> >> > >> >> >> > >> On 5/9/18 2:38 AM, Martin Jansa wrote: >> >> > >> > My initial tests show couple issues, but usually caused by other >> >> > >> > changes >> >> > >> > in that branch, not the gcc-8 itself. >> >> > >> > >> >> > >> > 1) strace-4.22 from >> >> > >> > >> >> > >> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654 >> >> > >> > fails to build with ptest enabled (it builds with 4.20 version >> >> > >> > if I >> >> > >> > revert this change) >> >> > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main': >> >> > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be >> >> > >> > used in >> >> > >> > asm here >> >> > >> > } >> >> > >> > ^ >> >> > >> >> >> > >> are you targeting thumb1 ? how can I reproduce it ? >> >> > > >> >> > > I'm trying to find out what's different in the builds where it was >> >> > > failing, will provide more info later. >> >> > >> >> > This is probably due to making an inline syscall from Thumb (doesn't >> >> > a >> >> > matter Thumb1 or Thumb2) with frame pointers enabled. >> >> > >> >> > Does adding -fomit-frame-pointer to CFLAGS fix it? >> >> >> >> It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is >> >> already -fno-omit-frame-pointer in the default command line for it, >> >> adding -fomit-frame-pointer at the end fixes it: >> >> >> >> docker-lge @ >> >> ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests >> >> $ arm-webos-linux-gnueabi-gcc -march=armv7ve -mthumb -mfpu=neon-vfpv4 >> >> -mfloat-abi=hard -mcpu=cortex-a7 >> >> --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot >> >> -DHAVE_CONFIG_H -I. -I../linux/arm -I../../strace-4.22/linux/arm >> >> -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22 >> >> -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4 -Wall -Wempty-body >> >> -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self >> >> -Wlogical-op -Wmissing-parameter-type -Wnested-externs >> >> -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits >> >> -Wwrite-strings -O -fno-omit-frame-pointer -g -feliminate-unused-debug-types >> >> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0 >> >> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot= >> >> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native= >> >> -pipe -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c >> >> -fomit-frame-pointer >> >> >> >> This might come from: >> >> meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer >> >> ${DEBUG_FLAGS} -pipe" >> >> because in this build I had DEBUG_BUILD enabled. >> >> >> >> Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as >> >> well now. >> > >> > 4.20 doesn't fail with DEBUG_BUILD, because inject-nf.c test is new in >> > 4.22: >> > >> > >> > https://github.com/strace/strace/commit/58598cd7f6e23e531d71bfe5a4e35f898a4f3b2d#diff-dc01d20c1e55f8adf7536cb46d4481e1 >> > >> > What is preferred fix for this? Is adding -fomit-frame-pointer to CFLAGS >> > when ptest is in DISTRO_FEATURES acceptable solution? >> >> I would say unconditionally adding -fomit-frame-pointer to CFLAGS for >> all builds is OK (strace is a debug tool - not something that >> generally needs to be debugged and frame pointers aren't essential for >> debugging anyway). ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [OE-core] [RFT] GCC 8.1 2018-05-10 22:40 ` Andre McCurdy @ 2018-05-10 22:50 ` Martin Jansa -1 siblings, 0 replies; 74+ messages in thread From: Martin Jansa @ 2018-05-10 22:50 UTC (permalink / raw) To: Andre McCurdy Cc: Yocto Project, Patches and discussions about the oe-core layer, openembedded-devel [-- Attachment #1: Type: text/plain, Size: 5185 bytes --] On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote: > On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote: > > see > > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html > > Removing -fno-omit-frame-pointer isn't the same as adding > -fomit-frame-pointer. Frame pointers may get enabled depending on the > optimisation level etc (ie not only by -fno-omit-frame-pointer). Should I send v2 adding -fomit-frame-pointer instead of removing -fno-omit-frame-pointer? The v1 fixes the issue for me with default config + DEBUG_BUILD. > > On Fri, May 11, 2018 at 12:38 AM Andre McCurdy <armccurdy@gmail.com> wrote: > >> > >> On Thu, May 10, 2018 at 3:07 PM, Martin Jansa <martin.jansa@gmail.com> > >> wrote: > >> > On Thu, May 10, 2018 at 11:43:25PM +0200, Martin Jansa wrote: > >> >> On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote: > >> >> > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa > >> >> > <martin.jansa@gmail.com> wrote: > >> >> > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote: > >> >> > >> Hi Martin > >> >> > >> > >> >> > >> Thanks for testing and reporting back > >> >> > >> > >> >> > >> On 5/9/18 2:38 AM, Martin Jansa wrote: > >> >> > >> > My initial tests show couple issues, but usually caused by other > >> >> > >> > changes > >> >> > >> > in that branch, not the gcc-8 itself. > >> >> > >> > > >> >> > >> > 1) strace-4.22 from > >> >> > >> > > >> >> > >> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654 > >> >> > >> > fails to build with ptest enabled (it builds with 4.20 version > >> >> > >> > if I > >> >> > >> > revert this change) > >> >> > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main': > >> >> > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be > >> >> > >> > used in > >> >> > >> > asm here > >> >> > >> > } > >> >> > >> > ^ > >> >> > >> > >> >> > >> are you targeting thumb1 ? how can I reproduce it ? > >> >> > > > >> >> > > I'm trying to find out what's different in the builds where it was > >> >> > > failing, will provide more info later. > >> >> > > >> >> > This is probably due to making an inline syscall from Thumb (doesn't > >> >> > a > >> >> > matter Thumb1 or Thumb2) with frame pointers enabled. > >> >> > > >> >> > Does adding -fomit-frame-pointer to CFLAGS fix it? > >> >> > >> >> It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is > >> >> already -fno-omit-frame-pointer in the default command line for it, > >> >> adding -fomit-frame-pointer at the end fixes it: > >> >> > >> >> docker-lge @ > >> >> ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests > >> >> $ arm-webos-linux-gnueabi-gcc -march=armv7ve -mthumb -mfpu=neon-vfpv4 > >> >> -mfloat-abi=hard -mcpu=cortex-a7 > >> >> --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot > >> >> -DHAVE_CONFIG_H -I. -I../linux/arm -I../../strace-4.22/linux/arm > >> >> -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22 > >> >> -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4 -Wall -Wempty-body > >> >> -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self > >> >> -Wlogical-op -Wmissing-parameter-type -Wnested-externs > >> >> -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits > >> >> -Wwrite-strings -O -fno-omit-frame-pointer -g -feliminate-unused-debug-types > >> >> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0 > >> >> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot= > >> >> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native= > >> >> -pipe -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c > >> >> -fomit-frame-pointer > >> >> > >> >> This might come from: > >> >> meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer > >> >> ${DEBUG_FLAGS} -pipe" > >> >> because in this build I had DEBUG_BUILD enabled. > >> >> > >> >> Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as > >> >> well now. > >> > > >> > 4.20 doesn't fail with DEBUG_BUILD, because inject-nf.c test is new in > >> > 4.22: > >> > > >> > > >> > https://github.com/strace/strace/commit/58598cd7f6e23e531d71bfe5a4e35f898a4f3b2d#diff-dc01d20c1e55f8adf7536cb46d4481e1 > >> > > >> > What is preferred fix for this? Is adding -fomit-frame-pointer to CFLAGS > >> > when ptest is in DISTRO_FEATURES acceptable solution? > >> > >> I would say unconditionally adding -fomit-frame-pointer to CFLAGS for > >> all builds is OK (strace is a debug tool - not something that > >> generally needs to be debugged and frame pointers aren't essential for > >> debugging anyway). -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 201 bytes --] ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFT] GCC 8.1 @ 2018-05-10 22:50 ` Martin Jansa 0 siblings, 0 replies; 74+ messages in thread From: Martin Jansa @ 2018-05-10 22:50 UTC (permalink / raw) To: Andre McCurdy Cc: Yocto Project, Patches and discussions about the oe-core layer, openembedded-devel [-- Attachment #1: Type: text/plain, Size: 5185 bytes --] On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote: > On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote: > > see > > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html > > Removing -fno-omit-frame-pointer isn't the same as adding > -fomit-frame-pointer. Frame pointers may get enabled depending on the > optimisation level etc (ie not only by -fno-omit-frame-pointer). Should I send v2 adding -fomit-frame-pointer instead of removing -fno-omit-frame-pointer? The v1 fixes the issue for me with default config + DEBUG_BUILD. > > On Fri, May 11, 2018 at 12:38 AM Andre McCurdy <armccurdy@gmail.com> wrote: > >> > >> On Thu, May 10, 2018 at 3:07 PM, Martin Jansa <martin.jansa@gmail.com> > >> wrote: > >> > On Thu, May 10, 2018 at 11:43:25PM +0200, Martin Jansa wrote: > >> >> On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote: > >> >> > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa > >> >> > <martin.jansa@gmail.com> wrote: > >> >> > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote: > >> >> > >> Hi Martin > >> >> > >> > >> >> > >> Thanks for testing and reporting back > >> >> > >> > >> >> > >> On 5/9/18 2:38 AM, Martin Jansa wrote: > >> >> > >> > My initial tests show couple issues, but usually caused by other > >> >> > >> > changes > >> >> > >> > in that branch, not the gcc-8 itself. > >> >> > >> > > >> >> > >> > 1) strace-4.22 from > >> >> > >> > > >> >> > >> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8&id=af33a8b721cc9caebd3f5226b4c5903f666ab654 > >> >> > >> > fails to build with ptest enabled (it builds with 4.20 version > >> >> > >> > if I > >> >> > >> > revert this change) > >> >> > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main': > >> >> > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be > >> >> > >> > used in > >> >> > >> > asm here > >> >> > >> > } > >> >> > >> > ^ > >> >> > >> > >> >> > >> are you targeting thumb1 ? how can I reproduce it ? > >> >> > > > >> >> > > I'm trying to find out what's different in the builds where it was > >> >> > > failing, will provide more info later. > >> >> > > >> >> > This is probably due to making an inline syscall from Thumb (doesn't > >> >> > a > >> >> > matter Thumb1 or Thumb2) with frame pointers enabled. > >> >> > > >> >> > Does adding -fomit-frame-pointer to CFLAGS fix it? > >> >> > >> >> It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is > >> >> already -fno-omit-frame-pointer in the default command line for it, > >> >> adding -fomit-frame-pointer at the end fixes it: > >> >> > >> >> docker-lge @ > >> >> ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests > >> >> $ arm-webos-linux-gnueabi-gcc -march=armv7ve -mthumb -mfpu=neon-vfpv4 > >> >> -mfloat-abi=hard -mcpu=cortex-a7 > >> >> --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot > >> >> -DHAVE_CONFIG_H -I. -I../linux/arm -I../../strace-4.22/linux/arm > >> >> -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22 > >> >> -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4 -Wall -Wempty-body > >> >> -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self > >> >> -Wlogical-op -Wmissing-parameter-type -Wnested-externs > >> >> -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits > >> >> -Wwrite-strings -O -fno-omit-frame-pointer -g -feliminate-unused-debug-types > >> >> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0 > >> >> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot= > >> >> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native= > >> >> -pipe -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c > >> >> -fomit-frame-pointer > >> >> > >> >> This might come from: > >> >> meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer > >> >> ${DEBUG_FLAGS} -pipe" > >> >> because in this build I had DEBUG_BUILD enabled. > >> >> > >> >> Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as > >> >> well now. > >> > > >> > 4.20 doesn't fail with DEBUG_BUILD, because inject-nf.c test is new in > >> > 4.22: > >> > > >> > > >> > https://github.com/strace/strace/commit/58598cd7f6e23e531d71bfe5a4e35f898a4f3b2d#diff-dc01d20c1e55f8adf7536cb46d4481e1 > >> > > >> > What is preferred fix for this? Is adding -fomit-frame-pointer to CFLAGS > >> > when ptest is in DISTRO_FEATURES acceptable solution? > >> > >> I would say unconditionally adding -fomit-frame-pointer to CFLAGS for > >> all builds is OK (strace is a debug tool - not something that > >> generally needs to be debugged and frame pointers aren't essential for > >> debugging anyway). -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 201 bytes --] ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [OE-core] [RFT] GCC 8.1 2018-05-10 22:50 ` Martin Jansa @ 2018-05-10 23:11 ` Andre McCurdy -1 siblings, 0 replies; 74+ messages in thread From: Andre McCurdy @ 2018-05-10 23:11 UTC (permalink / raw) To: Martin Jansa Cc: Yocto Project, Patches and discussions about the oe-core layer, openembedded-devel On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote: > On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote: >> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >> > see >> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html >> >> Removing -fno-omit-frame-pointer isn't the same as adding >> -fomit-frame-pointer. Frame pointers may get enabled depending on the >> optimisation level etc (ie not only by -fno-omit-frame-pointer). > > Should I send v2 adding -fomit-frame-pointer instead of removing > -fno-omit-frame-pointer? > > The v1 fixes the issue for me with default config + DEBUG_BUILD. The v1 patch isn't wrong, it's just incomplete (the problem could come back if someone changes optimisation level or switches gcc to clang, etc). My choice would be a v2 patch which adds -fomit-frame-pointer to CFLAGS unconditionally for all ARM builds when Thumb is enabled. That should fix the problem for all optimisation levels etc and avoids building the main strace binary differently depending on whether or not ptest is enabled. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFT] GCC 8.1 @ 2018-05-10 23:11 ` Andre McCurdy 0 siblings, 0 replies; 74+ messages in thread From: Andre McCurdy @ 2018-05-10 23:11 UTC (permalink / raw) To: Martin Jansa Cc: Yocto Project, Patches and discussions about the oe-core layer, openembedded-devel On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote: > On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote: >> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >> > see >> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html >> >> Removing -fno-omit-frame-pointer isn't the same as adding >> -fomit-frame-pointer. Frame pointers may get enabled depending on the >> optimisation level etc (ie not only by -fno-omit-frame-pointer). > > Should I send v2 adding -fomit-frame-pointer instead of removing > -fno-omit-frame-pointer? > > The v1 fixes the issue for me with default config + DEBUG_BUILD. The v1 patch isn't wrong, it's just incomplete (the problem could come back if someone changes optimisation level or switches gcc to clang, etc). My choice would be a v2 patch which adds -fomit-frame-pointer to CFLAGS unconditionally for all ARM builds when Thumb is enabled. That should fix the problem for all optimisation levels etc and avoids building the main strace binary differently depending on whether or not ptest is enabled. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [OE-core] [RFT] GCC 8.1 2018-05-10 23:11 ` Andre McCurdy @ 2018-05-10 23:32 ` Martin Jansa -1 siblings, 0 replies; 74+ messages in thread From: Martin Jansa @ 2018-05-10 23:32 UTC (permalink / raw) To: Andre McCurdy Cc: Yocto Project, Patches and discussions about the oe-core layer, openembedded-devel [-- Attachment #1: Type: text/plain, Size: 1448 bytes --] On Thu, May 10, 2018 at 04:11:00PM -0700, Andre McCurdy wrote: > On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote: > > On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote: > >> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote: > >> > see > >> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html > >> > >> Removing -fno-omit-frame-pointer isn't the same as adding > >> -fomit-frame-pointer. Frame pointers may get enabled depending on the > >> optimisation level etc (ie not only by -fno-omit-frame-pointer). > > > > Should I send v2 adding -fomit-frame-pointer instead of removing > > -fno-omit-frame-pointer? > > > > The v1 fixes the issue for me with default config + DEBUG_BUILD. > > The v1 patch isn't wrong, it's just incomplete (the problem could come > back if someone changes optimisation level or switches gcc to clang, > etc). > > My choice would be a v2 patch which adds -fomit-frame-pointer to > CFLAGS unconditionally for all ARM builds when Thumb is enabled. That > should fix the problem for all optimisation levels etc and avoids > building the main strace binary differently depending on whether or > not ptest is enabled. Only for thumb? makes me a bit sad that thumb override was dropped by you in 351443d71eb246a946b41f12b54d57b36fe1574e -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 201 bytes --] ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFT] GCC 8.1 @ 2018-05-10 23:32 ` Martin Jansa 0 siblings, 0 replies; 74+ messages in thread From: Martin Jansa @ 2018-05-10 23:32 UTC (permalink / raw) To: Andre McCurdy Cc: Yocto Project, Patches and discussions about the oe-core layer, openembedded-devel [-- Attachment #1: Type: text/plain, Size: 1448 bytes --] On Thu, May 10, 2018 at 04:11:00PM -0700, Andre McCurdy wrote: > On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote: > > On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote: > >> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote: > >> > see > >> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html > >> > >> Removing -fno-omit-frame-pointer isn't the same as adding > >> -fomit-frame-pointer. Frame pointers may get enabled depending on the > >> optimisation level etc (ie not only by -fno-omit-frame-pointer). > > > > Should I send v2 adding -fomit-frame-pointer instead of removing > > -fno-omit-frame-pointer? > > > > The v1 fixes the issue for me with default config + DEBUG_BUILD. > > The v1 patch isn't wrong, it's just incomplete (the problem could come > back if someone changes optimisation level or switches gcc to clang, > etc). > > My choice would be a v2 patch which adds -fomit-frame-pointer to > CFLAGS unconditionally for all ARM builds when Thumb is enabled. That > should fix the problem for all optimisation levels etc and avoids > building the main strace binary differently depending on whether or > not ptest is enabled. Only for thumb? makes me a bit sad that thumb override was dropped by you in 351443d71eb246a946b41f12b54d57b36fe1574e -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 201 bytes --] ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [OE-core] [RFT] GCC 8.1 2018-05-10 23:32 ` Martin Jansa @ 2018-05-10 23:41 ` Andre McCurdy -1 siblings, 0 replies; 74+ messages in thread From: Andre McCurdy @ 2018-05-10 23:41 UTC (permalink / raw) To: Martin Jansa Cc: Yocto Project, Patches and discussions about the oe-core layer, openembedded-devel On Thu, May 10, 2018 at 4:32 PM, Martin Jansa <martin.jansa@gmail.com> wrote: > On Thu, May 10, 2018 at 04:11:00PM -0700, Andre McCurdy wrote: >> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >> > On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote: >> >> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >> >> > see >> >> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html >> >> >> >> Removing -fno-omit-frame-pointer isn't the same as adding >> >> -fomit-frame-pointer. Frame pointers may get enabled depending on the >> >> optimisation level etc (ie not only by -fno-omit-frame-pointer). >> > >> > Should I send v2 adding -fomit-frame-pointer instead of removing >> > -fno-omit-frame-pointer? >> > >> > The v1 fixes the issue for me with default config + DEBUG_BUILD. >> >> The v1 patch isn't wrong, it's just incomplete (the problem could come >> back if someone changes optimisation level or switches gcc to clang, >> etc). >> >> My choice would be a v2 patch which adds -fomit-frame-pointer to >> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That >> should fix the problem for all optimisation levels etc and avoids >> building the main strace binary differently depending on whether or >> not ptest is enabled. > > Only for thumb? makes me a bit sad that thumb override was dropped by > you in > 351443d71eb246a946b41f12b54d57b36fe1574e No need for a thumb over-ride. You can copy and paste from the musl recipe: CFLAGS_append_arm = " ${@bb.utils.contains('TUNE_CCARGS', '-mthumb', '-fomit-frame-pointer', '', d)}" ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFT] GCC 8.1 @ 2018-05-10 23:41 ` Andre McCurdy 0 siblings, 0 replies; 74+ messages in thread From: Andre McCurdy @ 2018-05-10 23:41 UTC (permalink / raw) To: Martin Jansa Cc: Yocto Project, Patches and discussions about the oe-core layer, openembedded-devel On Thu, May 10, 2018 at 4:32 PM, Martin Jansa <martin.jansa@gmail.com> wrote: > On Thu, May 10, 2018 at 04:11:00PM -0700, Andre McCurdy wrote: >> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >> > On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote: >> >> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >> >> > see >> >> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html >> >> >> >> Removing -fno-omit-frame-pointer isn't the same as adding >> >> -fomit-frame-pointer. Frame pointers may get enabled depending on the >> >> optimisation level etc (ie not only by -fno-omit-frame-pointer). >> > >> > Should I send v2 adding -fomit-frame-pointer instead of removing >> > -fno-omit-frame-pointer? >> > >> > The v1 fixes the issue for me with default config + DEBUG_BUILD. >> >> The v1 patch isn't wrong, it's just incomplete (the problem could come >> back if someone changes optimisation level or switches gcc to clang, >> etc). >> >> My choice would be a v2 patch which adds -fomit-frame-pointer to >> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That >> should fix the problem for all optimisation levels etc and avoids >> building the main strace binary differently depending on whether or >> not ptest is enabled. > > Only for thumb? makes me a bit sad that thumb override was dropped by > you in > 351443d71eb246a946b41f12b54d57b36fe1574e No need for a thumb over-ride. You can copy and paste from the musl recipe: CFLAGS_append_arm = " ${@bb.utils.contains('TUNE_CCARGS', '-mthumb', '-fomit-frame-pointer', '', d)}" ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [OE-core] [RFT] GCC 8.1 2018-05-10 23:11 ` Andre McCurdy @ 2018-05-11 0:55 ` Khem Raj -1 siblings, 0 replies; 74+ messages in thread From: Khem Raj @ 2018-05-11 0:55 UTC (permalink / raw) To: Andre McCurdy Cc: Yocto Project, Patches and discussions about the oe-core layer, openembedded-devel On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote: > On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >> On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote: >>> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >>> > see >>> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html >>> >>> Removing -fno-omit-frame-pointer isn't the same as adding >>> -fomit-frame-pointer. Frame pointers may get enabled depending on the >>> optimisation level etc (ie not only by -fno-omit-frame-pointer). >> >> Should I send v2 adding -fomit-frame-pointer instead of removing >> -fno-omit-frame-pointer? >> >> The v1 fixes the issue for me with default config + DEBUG_BUILD. > > The v1 patch isn't wrong, it's just incomplete (the problem could come > back if someone changes optimisation level or switches gcc to clang, > etc). > > My choice would be a v2 patch which adds -fomit-frame-pointer to > CFLAGS unconditionally for all ARM builds when Thumb is enabled. That > should fix the problem for all optimisation levels etc and avoids > building the main strace binary differently depending on whether or > not ptest is enabled. explicitly adding this option is a poor choice especially for debug builds where we should let the -On level decide and not explicitly ask for either enable/disable frame-pointers that will also make it compiler proof. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFT] GCC 8.1 @ 2018-05-11 0:55 ` Khem Raj 0 siblings, 0 replies; 74+ messages in thread From: Khem Raj @ 2018-05-11 0:55 UTC (permalink / raw) To: Andre McCurdy Cc: Yocto Project, Patches and discussions about the oe-core layer, openembedded-devel On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote: > On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >> On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote: >>> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >>> > see >>> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html >>> >>> Removing -fno-omit-frame-pointer isn't the same as adding >>> -fomit-frame-pointer. Frame pointers may get enabled depending on the >>> optimisation level etc (ie not only by -fno-omit-frame-pointer). >> >> Should I send v2 adding -fomit-frame-pointer instead of removing >> -fno-omit-frame-pointer? >> >> The v1 fixes the issue for me with default config + DEBUG_BUILD. > > The v1 patch isn't wrong, it's just incomplete (the problem could come > back if someone changes optimisation level or switches gcc to clang, > etc). > > My choice would be a v2 patch which adds -fomit-frame-pointer to > CFLAGS unconditionally for all ARM builds when Thumb is enabled. That > should fix the problem for all optimisation levels etc and avoids > building the main strace binary differently depending on whether or > not ptest is enabled. explicitly adding this option is a poor choice especially for debug builds where we should let the -On level decide and not explicitly ask for either enable/disable frame-pointers that will also make it compiler proof. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [OE-core] [RFT] GCC 8.1 2018-05-11 0:55 ` Khem Raj @ 2018-05-11 1:00 ` Andre McCurdy -1 siblings, 0 replies; 74+ messages in thread From: Andre McCurdy @ 2018-05-11 1:00 UTC (permalink / raw) To: Khem Raj Cc: Yocto Project, Patches and discussions about the oe-core layer, openembedded-devel On Thu, May 10, 2018 at 5:55 PM, Khem Raj <raj.khem@gmail.com> wrote: > On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote: >> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >>> On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote: >>>> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >>>> > see >>>> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html >>>> >>>> Removing -fno-omit-frame-pointer isn't the same as adding >>>> -fomit-frame-pointer. Frame pointers may get enabled depending on the >>>> optimisation level etc (ie not only by -fno-omit-frame-pointer). >>> >>> Should I send v2 adding -fomit-frame-pointer instead of removing >>> -fno-omit-frame-pointer? >>> >>> The v1 fixes the issue for me with default config + DEBUG_BUILD. >> >> The v1 patch isn't wrong, it's just incomplete (the problem could come >> back if someone changes optimisation level or switches gcc to clang, >> etc). >> >> My choice would be a v2 patch which adds -fomit-frame-pointer to >> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That >> should fix the problem for all optimisation levels etc and avoids >> building the main strace binary differently depending on whether or >> not ptest is enabled. > > explicitly adding this option is a poor choice especially for debug > builds where we should > let the -On level decide and not explicitly ask for either > enable/disable frame-pointers > that will also make it compiler proof. Of course, we should let the compiler decide whenever it's possible to do so. Unfortunately there are cases like this one where frame pointers clash with inline assembler and we need to over-rule the compiler's choice. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFT] GCC 8.1 @ 2018-05-11 1:00 ` Andre McCurdy 0 siblings, 0 replies; 74+ messages in thread From: Andre McCurdy @ 2018-05-11 1:00 UTC (permalink / raw) To: Khem Raj Cc: Yocto Project, Patches and discussions about the oe-core layer, openembedded-devel On Thu, May 10, 2018 at 5:55 PM, Khem Raj <raj.khem@gmail.com> wrote: > On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote: >> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >>> On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote: >>>> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >>>> > see >>>> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html >>>> >>>> Removing -fno-omit-frame-pointer isn't the same as adding >>>> -fomit-frame-pointer. Frame pointers may get enabled depending on the >>>> optimisation level etc (ie not only by -fno-omit-frame-pointer). >>> >>> Should I send v2 adding -fomit-frame-pointer instead of removing >>> -fno-omit-frame-pointer? >>> >>> The v1 fixes the issue for me with default config + DEBUG_BUILD. >> >> The v1 patch isn't wrong, it's just incomplete (the problem could come >> back if someone changes optimisation level or switches gcc to clang, >> etc). >> >> My choice would be a v2 patch which adds -fomit-frame-pointer to >> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That >> should fix the problem for all optimisation levels etc and avoids >> building the main strace binary differently depending on whether or >> not ptest is enabled. > > explicitly adding this option is a poor choice especially for debug > builds where we should > let the -On level decide and not explicitly ask for either > enable/disable frame-pointers > that will also make it compiler proof. Of course, we should let the compiler decide whenever it's possible to do so. Unfortunately there are cases like this one where frame pointers clash with inline assembler and we need to over-rule the compiler's choice. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [OE-core] [RFT] GCC 8.1 2018-05-11 1:00 ` Andre McCurdy @ 2018-05-11 1:06 ` Khem Raj -1 siblings, 0 replies; 74+ messages in thread From: Khem Raj @ 2018-05-11 1:06 UTC (permalink / raw) To: Andre McCurdy Cc: Yocto Project, Patches and discussions about the oe-core layer, openembedded-devel On Thu, May 10, 2018 at 6:00 PM, Andre McCurdy <armccurdy@gmail.com> wrote: > On Thu, May 10, 2018 at 5:55 PM, Khem Raj <raj.khem@gmail.com> wrote: >> On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote: >>> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >>>> On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote: >>>>> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >>>>> > see >>>>> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html >>>>> >>>>> Removing -fno-omit-frame-pointer isn't the same as adding >>>>> -fomit-frame-pointer. Frame pointers may get enabled depending on the >>>>> optimisation level etc (ie not only by -fno-omit-frame-pointer). >>>> >>>> Should I send v2 adding -fomit-frame-pointer instead of removing >>>> -fno-omit-frame-pointer? >>>> >>>> The v1 fixes the issue for me with default config + DEBUG_BUILD. >>> >>> The v1 patch isn't wrong, it's just incomplete (the problem could come >>> back if someone changes optimisation level or switches gcc to clang, >>> etc). >>> >>> My choice would be a v2 patch which adds -fomit-frame-pointer to >>> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That >>> should fix the problem for all optimisation levels etc and avoids >>> building the main strace binary differently depending on whether or >>> not ptest is enabled. >> >> explicitly adding this option is a poor choice especially for debug >> builds where we should >> let the -On level decide and not explicitly ask for either >> enable/disable frame-pointers >> that will also make it compiler proof. > > Of course, we should let the compiler decide whenever it's possible to do so. > > Unfortunately there are cases like this one where frame pointers clash > with inline assembler and we need to over-rule the compiler's choice. Here we are adding -fno-omit-frame-pointer via global opt flags that is the issue where we have fallouts from default O options I agree we should teach this to build system and help the compiler ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFT] GCC 8.1 @ 2018-05-11 1:06 ` Khem Raj 0 siblings, 0 replies; 74+ messages in thread From: Khem Raj @ 2018-05-11 1:06 UTC (permalink / raw) To: Andre McCurdy Cc: Yocto Project, Patches and discussions about the oe-core layer, openembedded-devel On Thu, May 10, 2018 at 6:00 PM, Andre McCurdy <armccurdy@gmail.com> wrote: > On Thu, May 10, 2018 at 5:55 PM, Khem Raj <raj.khem@gmail.com> wrote: >> On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote: >>> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >>>> On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote: >>>>> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >>>>> > see >>>>> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html >>>>> >>>>> Removing -fno-omit-frame-pointer isn't the same as adding >>>>> -fomit-frame-pointer. Frame pointers may get enabled depending on the >>>>> optimisation level etc (ie not only by -fno-omit-frame-pointer). >>>> >>>> Should I send v2 adding -fomit-frame-pointer instead of removing >>>> -fno-omit-frame-pointer? >>>> >>>> The v1 fixes the issue for me with default config + DEBUG_BUILD. >>> >>> The v1 patch isn't wrong, it's just incomplete (the problem could come >>> back if someone changes optimisation level or switches gcc to clang, >>> etc). >>> >>> My choice would be a v2 patch which adds -fomit-frame-pointer to >>> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That >>> should fix the problem for all optimisation levels etc and avoids >>> building the main strace binary differently depending on whether or >>> not ptest is enabled. >> >> explicitly adding this option is a poor choice especially for debug >> builds where we should >> let the -On level decide and not explicitly ask for either >> enable/disable frame-pointers >> that will also make it compiler proof. > > Of course, we should let the compiler decide whenever it's possible to do so. > > Unfortunately there are cases like this one where frame pointers clash > with inline assembler and we need to over-rule the compiler's choice. Here we are adding -fno-omit-frame-pointer via global opt flags that is the issue where we have fallouts from default O options I agree we should teach this to build system and help the compiler ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [OE-core] [RFT] GCC 8.1 2018-05-11 1:06 ` Khem Raj @ 2018-05-11 1:11 ` Andre McCurdy -1 siblings, 0 replies; 74+ messages in thread From: Andre McCurdy @ 2018-05-11 1:11 UTC (permalink / raw) To: Khem Raj Cc: Yocto Project, Patches and discussions about the oe-core layer, openembedded-devel On Thu, May 10, 2018 at 6:06 PM, Khem Raj <raj.khem@gmail.com> wrote: > On Thu, May 10, 2018 at 6:00 PM, Andre McCurdy <armccurdy@gmail.com> wrote: >> On Thu, May 10, 2018 at 5:55 PM, Khem Raj <raj.khem@gmail.com> wrote: >>> On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote: >>>> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >>>>> On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote: >>>>>> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >>>>>> > see >>>>>> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html >>>>>> >>>>>> Removing -fno-omit-frame-pointer isn't the same as adding >>>>>> -fomit-frame-pointer. Frame pointers may get enabled depending on the >>>>>> optimisation level etc (ie not only by -fno-omit-frame-pointer). >>>>> >>>>> Should I send v2 adding -fomit-frame-pointer instead of removing >>>>> -fno-omit-frame-pointer? >>>>> >>>>> The v1 fixes the issue for me with default config + DEBUG_BUILD. >>>> >>>> The v1 patch isn't wrong, it's just incomplete (the problem could come >>>> back if someone changes optimisation level or switches gcc to clang, >>>> etc). >>>> >>>> My choice would be a v2 patch which adds -fomit-frame-pointer to >>>> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That >>>> should fix the problem for all optimisation levels etc and avoids >>>> building the main strace binary differently depending on whether or >>>> not ptest is enabled. >>> >>> explicitly adding this option is a poor choice especially for debug >>> builds where we should >>> let the -On level decide and not explicitly ask for either >>> enable/disable frame-pointers >>> that will also make it compiler proof. >> >> Of course, we should let the compiler decide whenever it's possible to do so. >> >> Unfortunately there are cases like this one where frame pointers clash >> with inline assembler and we need to over-rule the compiler's choice. > > Here we are adding -fno-omit-frame-pointer via global opt flags that > is the issue > where we have fallouts from default O options I agree we should teach > this to build > system and help the compiler Since there's NO situation where enabling frame pointers is going to work for this code + ARM + Thumb, I don't see the advantage of leaving anything up to chance. Just explicitly disabling frame pointers is the safest and cleanest option. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFT] GCC 8.1 @ 2018-05-11 1:11 ` Andre McCurdy 0 siblings, 0 replies; 74+ messages in thread From: Andre McCurdy @ 2018-05-11 1:11 UTC (permalink / raw) To: Khem Raj Cc: Yocto Project, Patches and discussions about the oe-core layer, openembedded-devel On Thu, May 10, 2018 at 6:06 PM, Khem Raj <raj.khem@gmail.com> wrote: > On Thu, May 10, 2018 at 6:00 PM, Andre McCurdy <armccurdy@gmail.com> wrote: >> On Thu, May 10, 2018 at 5:55 PM, Khem Raj <raj.khem@gmail.com> wrote: >>> On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote: >>>> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >>>>> On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote: >>>>>> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >>>>>> > see >>>>>> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html >>>>>> >>>>>> Removing -fno-omit-frame-pointer isn't the same as adding >>>>>> -fomit-frame-pointer. Frame pointers may get enabled depending on the >>>>>> optimisation level etc (ie not only by -fno-omit-frame-pointer). >>>>> >>>>> Should I send v2 adding -fomit-frame-pointer instead of removing >>>>> -fno-omit-frame-pointer? >>>>> >>>>> The v1 fixes the issue for me with default config + DEBUG_BUILD. >>>> >>>> The v1 patch isn't wrong, it's just incomplete (the problem could come >>>> back if someone changes optimisation level or switches gcc to clang, >>>> etc). >>>> >>>> My choice would be a v2 patch which adds -fomit-frame-pointer to >>>> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That >>>> should fix the problem for all optimisation levels etc and avoids >>>> building the main strace binary differently depending on whether or >>>> not ptest is enabled. >>> >>> explicitly adding this option is a poor choice especially for debug >>> builds where we should >>> let the -On level decide and not explicitly ask for either >>> enable/disable frame-pointers >>> that will also make it compiler proof. >> >> Of course, we should let the compiler decide whenever it's possible to do so. >> >> Unfortunately there are cases like this one where frame pointers clash >> with inline assembler and we need to over-rule the compiler's choice. > > Here we are adding -fno-omit-frame-pointer via global opt flags that > is the issue > where we have fallouts from default O options I agree we should teach > this to build > system and help the compiler Since there's NO situation where enabling frame pointers is going to work for this code + ARM + Thumb, I don't see the advantage of leaving anything up to chance. Just explicitly disabling frame pointers is the safest and cleanest option. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [OE-core] [RFT] GCC 8.1 2018-05-11 1:11 ` Andre McCurdy @ 2018-05-11 1:16 ` Khem Raj -1 siblings, 0 replies; 74+ messages in thread From: Khem Raj @ 2018-05-11 1:16 UTC (permalink / raw) To: Andre McCurdy Cc: Yocto Project, Patches and discussions about the oe-core layer, openembedded-devel On Thu, May 10, 2018 at 6:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote: > On Thu, May 10, 2018 at 6:06 PM, Khem Raj <raj.khem@gmail.com> wrote: >> On Thu, May 10, 2018 at 6:00 PM, Andre McCurdy <armccurdy@gmail.com> wrote: >>> On Thu, May 10, 2018 at 5:55 PM, Khem Raj <raj.khem@gmail.com> wrote: >>>> On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote: >>>>> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >>>>>> On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote: >>>>>>> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >>>>>>> > see >>>>>>> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html >>>>>>> >>>>>>> Removing -fno-omit-frame-pointer isn't the same as adding >>>>>>> -fomit-frame-pointer. Frame pointers may get enabled depending on the >>>>>>> optimisation level etc (ie not only by -fno-omit-frame-pointer). >>>>>> >>>>>> Should I send v2 adding -fomit-frame-pointer instead of removing >>>>>> -fno-omit-frame-pointer? >>>>>> >>>>>> The v1 fixes the issue for me with default config + DEBUG_BUILD. >>>>> >>>>> The v1 patch isn't wrong, it's just incomplete (the problem could come >>>>> back if someone changes optimisation level or switches gcc to clang, >>>>> etc). >>>>> >>>>> My choice would be a v2 patch which adds -fomit-frame-pointer to >>>>> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That >>>>> should fix the problem for all optimisation levels etc and avoids >>>>> building the main strace binary differently depending on whether or >>>>> not ptest is enabled. >>>> >>>> explicitly adding this option is a poor choice especially for debug >>>> builds where we should >>>> let the -On level decide and not explicitly ask for either >>>> enable/disable frame-pointers >>>> that will also make it compiler proof. >>> >>> Of course, we should let the compiler decide whenever it's possible to do so. >>> >>> Unfortunately there are cases like this one where frame pointers clash >>> with inline assembler and we need to over-rule the compiler's choice. >> >> Here we are adding -fno-omit-frame-pointer via global opt flags that >> is the issue >> where we have fallouts from default O options I agree we should teach >> this to build >> system and help the compiler > > Since there's NO situation where enabling frame pointers is going to > work for this code + ARM + Thumb, I don't see the advantage of leaving > anything up to chance. Just explicitly disabling frame pointers is the > safest and cleanest option. In that case what we are saying is that strace has wrong assumptions I would think its best to change strace build system to demand this option override instead of injecting it externally. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFT] GCC 8.1 @ 2018-05-11 1:16 ` Khem Raj 0 siblings, 0 replies; 74+ messages in thread From: Khem Raj @ 2018-05-11 1:16 UTC (permalink / raw) To: Andre McCurdy Cc: Yocto Project, Patches and discussions about the oe-core layer, openembedded-devel On Thu, May 10, 2018 at 6:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote: > On Thu, May 10, 2018 at 6:06 PM, Khem Raj <raj.khem@gmail.com> wrote: >> On Thu, May 10, 2018 at 6:00 PM, Andre McCurdy <armccurdy@gmail.com> wrote: >>> On Thu, May 10, 2018 at 5:55 PM, Khem Raj <raj.khem@gmail.com> wrote: >>>> On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote: >>>>> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >>>>>> On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote: >>>>>>> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >>>>>>> > see >>>>>>> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html >>>>>>> >>>>>>> Removing -fno-omit-frame-pointer isn't the same as adding >>>>>>> -fomit-frame-pointer. Frame pointers may get enabled depending on the >>>>>>> optimisation level etc (ie not only by -fno-omit-frame-pointer). >>>>>> >>>>>> Should I send v2 adding -fomit-frame-pointer instead of removing >>>>>> -fno-omit-frame-pointer? >>>>>> >>>>>> The v1 fixes the issue for me with default config + DEBUG_BUILD. >>>>> >>>>> The v1 patch isn't wrong, it's just incomplete (the problem could come >>>>> back if someone changes optimisation level or switches gcc to clang, >>>>> etc). >>>>> >>>>> My choice would be a v2 patch which adds -fomit-frame-pointer to >>>>> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That >>>>> should fix the problem for all optimisation levels etc and avoids >>>>> building the main strace binary differently depending on whether or >>>>> not ptest is enabled. >>>> >>>> explicitly adding this option is a poor choice especially for debug >>>> builds where we should >>>> let the -On level decide and not explicitly ask for either >>>> enable/disable frame-pointers >>>> that will also make it compiler proof. >>> >>> Of course, we should let the compiler decide whenever it's possible to do so. >>> >>> Unfortunately there are cases like this one where frame pointers clash >>> with inline assembler and we need to over-rule the compiler's choice. >> >> Here we are adding -fno-omit-frame-pointer via global opt flags that >> is the issue >> where we have fallouts from default O options I agree we should teach >> this to build >> system and help the compiler > > Since there's NO situation where enabling frame pointers is going to > work for this code + ARM + Thumb, I don't see the advantage of leaving > anything up to chance. Just explicitly disabling frame pointers is the > safest and cleanest option. In that case what we are saying is that strace has wrong assumptions I would think its best to change strace build system to demand this option override instead of injecting it externally. ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [OE-core] [RFT] GCC 8.1 2018-05-11 1:16 ` Khem Raj @ 2018-05-11 1:21 ` Andre McCurdy -1 siblings, 0 replies; 74+ messages in thread From: Andre McCurdy @ 2018-05-11 1:21 UTC (permalink / raw) To: Khem Raj Cc: Yocto Project, Patches and discussions about the oe-core layer, openembedded-devel On Thu, May 10, 2018 at 6:16 PM, Khem Raj <raj.khem@gmail.com> wrote: > On Thu, May 10, 2018 at 6:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote: >> On Thu, May 10, 2018 at 6:06 PM, Khem Raj <raj.khem@gmail.com> wrote: >>> On Thu, May 10, 2018 at 6:00 PM, Andre McCurdy <armccurdy@gmail.com> wrote: >>>> On Thu, May 10, 2018 at 5:55 PM, Khem Raj <raj.khem@gmail.com> wrote: >>>>> On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote: >>>>>> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >>>>>>> On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote: >>>>>>>> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >>>>>>>> > see >>>>>>>> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html >>>>>>>> >>>>>>>> Removing -fno-omit-frame-pointer isn't the same as adding >>>>>>>> -fomit-frame-pointer. Frame pointers may get enabled depending on the >>>>>>>> optimisation level etc (ie not only by -fno-omit-frame-pointer). >>>>>>> >>>>>>> Should I send v2 adding -fomit-frame-pointer instead of removing >>>>>>> -fno-omit-frame-pointer? >>>>>>> >>>>>>> The v1 fixes the issue for me with default config + DEBUG_BUILD. >>>>>> >>>>>> The v1 patch isn't wrong, it's just incomplete (the problem could come >>>>>> back if someone changes optimisation level or switches gcc to clang, >>>>>> etc). >>>>>> >>>>>> My choice would be a v2 patch which adds -fomit-frame-pointer to >>>>>> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That >>>>>> should fix the problem for all optimisation levels etc and avoids >>>>>> building the main strace binary differently depending on whether or >>>>>> not ptest is enabled. >>>>> >>>>> explicitly adding this option is a poor choice especially for debug >>>>> builds where we should >>>>> let the -On level decide and not explicitly ask for either >>>>> enable/disable frame-pointers >>>>> that will also make it compiler proof. >>>> >>>> Of course, we should let the compiler decide whenever it's possible to do so. >>>> >>>> Unfortunately there are cases like this one where frame pointers clash >>>> with inline assembler and we need to over-rule the compiler's choice. >>> >>> Here we are adding -fno-omit-frame-pointer via global opt flags that >>> is the issue >>> where we have fallouts from default O options I agree we should teach >>> this to build >>> system and help the compiler >> >> Since there's NO situation where enabling frame pointers is going to >> work for this code + ARM + Thumb, I don't see the advantage of leaving >> anything up to chance. Just explicitly disabling frame pointers is the >> safest and cleanest option. > > In that case what we are saying is that strace has wrong assumptions > I would think its best to change strace build system to demand this > option override instead of injecting it externally. There are many possible / better fixes if we want to patch the strace sources or Makefiles. I'm not sure if Martin was signing up for that though :-) ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFT] GCC 8.1 @ 2018-05-11 1:21 ` Andre McCurdy 0 siblings, 0 replies; 74+ messages in thread From: Andre McCurdy @ 2018-05-11 1:21 UTC (permalink / raw) To: Khem Raj Cc: Yocto Project, Patches and discussions about the oe-core layer, openembedded-devel On Thu, May 10, 2018 at 6:16 PM, Khem Raj <raj.khem@gmail.com> wrote: > On Thu, May 10, 2018 at 6:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote: >> On Thu, May 10, 2018 at 6:06 PM, Khem Raj <raj.khem@gmail.com> wrote: >>> On Thu, May 10, 2018 at 6:00 PM, Andre McCurdy <armccurdy@gmail.com> wrote: >>>> On Thu, May 10, 2018 at 5:55 PM, Khem Raj <raj.khem@gmail.com> wrote: >>>>> On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote: >>>>>> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >>>>>>> On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote: >>>>>>>> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa@gmail.com> wrote: >>>>>>>> > see >>>>>>>> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html >>>>>>>> >>>>>>>> Removing -fno-omit-frame-pointer isn't the same as adding >>>>>>>> -fomit-frame-pointer. Frame pointers may get enabled depending on the >>>>>>>> optimisation level etc (ie not only by -fno-omit-frame-pointer). >>>>>>> >>>>>>> Should I send v2 adding -fomit-frame-pointer instead of removing >>>>>>> -fno-omit-frame-pointer? >>>>>>> >>>>>>> The v1 fixes the issue for me with default config + DEBUG_BUILD. >>>>>> >>>>>> The v1 patch isn't wrong, it's just incomplete (the problem could come >>>>>> back if someone changes optimisation level or switches gcc to clang, >>>>>> etc). >>>>>> >>>>>> My choice would be a v2 patch which adds -fomit-frame-pointer to >>>>>> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That >>>>>> should fix the problem for all optimisation levels etc and avoids >>>>>> building the main strace binary differently depending on whether or >>>>>> not ptest is enabled. >>>>> >>>>> explicitly adding this option is a poor choice especially for debug >>>>> builds where we should >>>>> let the -On level decide and not explicitly ask for either >>>>> enable/disable frame-pointers >>>>> that will also make it compiler proof. >>>> >>>> Of course, we should let the compiler decide whenever it's possible to do so. >>>> >>>> Unfortunately there are cases like this one where frame pointers clash >>>> with inline assembler and we need to over-rule the compiler's choice. >>> >>> Here we are adding -fno-omit-frame-pointer via global opt flags that >>> is the issue >>> where we have fallouts from default O options I agree we should teach >>> this to build >>> system and help the compiler >> >> Since there's NO situation where enabling frame pointers is going to >> work for this code + ARM + Thumb, I don't see the advantage of leaving >> anything up to chance. Just explicitly disabling frame pointers is the >> safest and cleanest option. > > In that case what we are saying is that strace has wrong assumptions > I would think its best to change strace build system to demand this > option override instead of injecting it externally. There are many possible / better fixes if we want to patch the strace sources or Makefiles. I'm not sure if Martin was signing up for that though :-) ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [OE-core] [RFT] GCC 8.1 2018-05-10 19:11 ` Martin Jansa @ 2018-05-17 10:46 ` Martin Jansa -1 siblings, 0 replies; 74+ messages in thread From: Martin Jansa @ 2018-05-17 10:46 UTC (permalink / raw) To: Khem Raj Cc: Yocto Project, openembeded-devel, Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 6643 bytes --] On Thu, May 10, 2018 at 09:11:45PM +0200, Martin Jansa wrote: > > > 5) nativesdk-libxcrypt fails to build (not sure which change caused > > > this, it build OK with sumo since the -std=gnu99 addition. > > > ../git/crypt-sunmd5.c:189:13: error: 'snprintf' output may be truncated > > > before the last format character [-Werror=format-truncation=] > > > "$" CRYPT_ALGNAME "," ROUNDS "%u$%s$", > > > ^~~ > > > > > > > something new, I will look into reproducing this. The fix from you worked for me, thanks! > > > I didn't get very far in testing, because our old kernel fails to build > > > with gcc8 and there are some other issues caused by other master > > > changes. But it doesn't look too bad (in my small test, lets see what > > > bitbake world will show), thanks a lot for new gcc. > > > > > > > yes, older kernel needs fixes, especially to disable new warnings. > > the mips/ppc fixes that I put out there might be helpful to cook up > > fixes for older kernels if running into same issues. > > In this case it fails with Error: .err encountered for many drivers. It's not the same case as in: > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/325615.html > nor arm version of this change, both are already applied in our > 4.4.3 based kernel. > > I've tried to reproduce with vanilla 4.4.143 and it doesn't fail like this, vanilla 4.4.3 doesn't > fail, so it's caused by one of our 10000 commits on top of 4.4.3 or the config, need to dig a bit more. Just FYI if someone needs similar fix, backporting this: https://patchwork.kernel.org/patch/9170055/ fixed the issue for me, now I have successful kernel build. The failing code was always in put_user calls, e.g. kernel/exit.s was showing: @ 1581 "kernel-source/kernel/exit.c" 1 .ifnc r0,r0; .ifnc r0r0,fpr11; .ifnc r0r0,r11fp; .ifnc r0r0,ipr12; .ifnc r0r0,r12ip; .err; .endif; .endif; .endif; .endif; .endif .ifnc r5,r2; .ifnc r5r2,fpr11; .ifnc r5r2,r11fp; .ifnc r5r2,ipr12; .ifnc r5r2,r12ip; .err; .endif; .endif; .endif; .endif; .endif .ifnc r1,r1; .ifnc r1r1,fpr11; .ifnc r1r1,r11fp; .ifnc r1r1,ipr12; .ifnc r1r1,r12ip; .err; .endif; .endif; .endif; .endif; .endif bl __put_user_4 @ 0 "" 2 with the error triggered on the middle line. /tmp/ccHq8ugv.s: Assembler messages: /tmp/ccHq8ugv.s:1179: Error: .err encountered /tmp/ccHq8ugv.s:1331: Error: .err encountered /tmp/ccHq8ugv.s:4617: Error: .err encountered /tmp/ccHq8ugv.s:6222: Error: .err encountered /tmp/ccHq8ugv.s:8705: Error: .err encountered /tmp/ccHq8ugv.s:14486: Error: .err encountered /tmp/ccHq8ugv.s:14646: Error: .err encountered /tmp/ccHq8ugv.s:14806: Error: .err encountered /tmp/ccHq8ugv.s:14966: Error: .err encountered /tmp/ccHq8ugv.s:15126: Error: .err encountered /tmp/ccHq8ugv.s:15286: Error: .err encountered That leaves only few issues in our internal components and strange failure with perf which fails to include various header files: perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory perf/1.0-r9/perf-1.0/tools/perf/arch/arm/include/../../../../include/asm-generic/bitops/fls.h:1:56: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/arch/arm/include/../../../../include/asm-generic/bitops/fls.h:1:56: error: #include nested too deeply ... Cheers, [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 201 bytes --] ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFT] GCC 8.1 @ 2018-05-17 10:46 ` Martin Jansa 0 siblings, 0 replies; 74+ messages in thread From: Martin Jansa @ 2018-05-17 10:46 UTC (permalink / raw) To: Khem Raj Cc: Yocto Project, openembeded-devel, Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 6643 bytes --] On Thu, May 10, 2018 at 09:11:45PM +0200, Martin Jansa wrote: > > > 5) nativesdk-libxcrypt fails to build (not sure which change caused > > > this, it build OK with sumo since the -std=gnu99 addition. > > > ../git/crypt-sunmd5.c:189:13: error: 'snprintf' output may be truncated > > > before the last format character [-Werror=format-truncation=] > > > "$" CRYPT_ALGNAME "," ROUNDS "%u$%s$", > > > ^~~ > > > > > > > something new, I will look into reproducing this. The fix from you worked for me, thanks! > > > I didn't get very far in testing, because our old kernel fails to build > > > with gcc8 and there are some other issues caused by other master > > > changes. But it doesn't look too bad (in my small test, lets see what > > > bitbake world will show), thanks a lot for new gcc. > > > > > > > yes, older kernel needs fixes, especially to disable new warnings. > > the mips/ppc fixes that I put out there might be helpful to cook up > > fixes for older kernels if running into same issues. > > In this case it fails with Error: .err encountered for many drivers. It's not the same case as in: > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/325615.html > nor arm version of this change, both are already applied in our > 4.4.3 based kernel. > > I've tried to reproduce with vanilla 4.4.143 and it doesn't fail like this, vanilla 4.4.3 doesn't > fail, so it's caused by one of our 10000 commits on top of 4.4.3 or the config, need to dig a bit more. Just FYI if someone needs similar fix, backporting this: https://patchwork.kernel.org/patch/9170055/ fixed the issue for me, now I have successful kernel build. The failing code was always in put_user calls, e.g. kernel/exit.s was showing: @ 1581 "kernel-source/kernel/exit.c" 1 .ifnc r0,r0; .ifnc r0r0,fpr11; .ifnc r0r0,r11fp; .ifnc r0r0,ipr12; .ifnc r0r0,r12ip; .err; .endif; .endif; .endif; .endif; .endif .ifnc r5,r2; .ifnc r5r2,fpr11; .ifnc r5r2,r11fp; .ifnc r5r2,ipr12; .ifnc r5r2,r12ip; .err; .endif; .endif; .endif; .endif; .endif .ifnc r1,r1; .ifnc r1r1,fpr11; .ifnc r1r1,r11fp; .ifnc r1r1,ipr12; .ifnc r1r1,r12ip; .err; .endif; .endif; .endif; .endif; .endif bl __put_user_4 @ 0 "" 2 with the error triggered on the middle line. /tmp/ccHq8ugv.s: Assembler messages: /tmp/ccHq8ugv.s:1179: Error: .err encountered /tmp/ccHq8ugv.s:1331: Error: .err encountered /tmp/ccHq8ugv.s:4617: Error: .err encountered /tmp/ccHq8ugv.s:6222: Error: .err encountered /tmp/ccHq8ugv.s:8705: Error: .err encountered /tmp/ccHq8ugv.s:14486: Error: .err encountered /tmp/ccHq8ugv.s:14646: Error: .err encountered /tmp/ccHq8ugv.s:14806: Error: .err encountered /tmp/ccHq8ugv.s:14966: Error: .err encountered /tmp/ccHq8ugv.s:15126: Error: .err encountered /tmp/ccHq8ugv.s:15286: Error: .err encountered That leaves only few issues in our internal components and strange failure with perf which fails to include various header files: perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory perf/1.0-r9/perf-1.0/tools/perf/arch/arm/include/../../../../include/asm-generic/bitops/fls.h:1:56: error: #include nested too deeply perf/1.0-r9/perf-1.0/tools/perf/arch/arm/include/../../../../include/asm-generic/bitops/fls.h:1:56: error: #include nested too deeply ... Cheers, [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 201 bytes --] ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [OE-core] [RFT] GCC 8.1 2018-05-17 10:46 ` Martin Jansa @ 2018-05-18 5:54 ` Khem Raj -1 siblings, 0 replies; 74+ messages in thread From: Khem Raj @ 2018-05-18 5:54 UTC (permalink / raw) To: Martin Jansa Cc: Yocto Project, openembeded-devel, Patches and discussions about the oe-core layer On Thu, May 17, 2018 at 3:46 AM, Martin Jansa <martin.jansa@gmail.com> wrote: > On Thu, May 10, 2018 at 09:11:45PM +0200, Martin Jansa wrote: >> > > 5) nativesdk-libxcrypt fails to build (not sure which change caused >> > > this, it build OK with sumo since the -std=gnu99 addition. >> > > ../git/crypt-sunmd5.c:189:13: error: 'snprintf' output may be truncated >> > > before the last format character [-Werror=format-truncation=] >> > > "$" CRYPT_ALGNAME "," ROUNDS "%u$%s$", >> > > ^~~ >> > > >> > >> > something new, I will look into reproducing this. > > The fix from you worked for me, thanks! There is a followup here which now doesnt need local patch http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/master&id=0924a69244892097f60adbf6c7f576375bea7870 > Just FYI if someone needs similar fix, backporting this: > https://patchwork.kernel.org/patch/9170055/ > > fixed the issue for me, now I have successful kernel build. > > The failing code was always in put_user calls, e.g. kernel/exit.s was showing: > @ 1581 "kernel-source/kernel/exit.c" 1 > .ifnc r0,r0; .ifnc r0r0,fpr11; .ifnc r0r0,r11fp; .ifnc r0r0,ipr12; .ifnc r0r0,r12ip; .err; .endif; .endif; .endif; .endif; .endif > .ifnc r5,r2; .ifnc r5r2,fpr11; .ifnc r5r2,r11fp; .ifnc r5r2,ipr12; .ifnc r5r2,r12ip; .err; .endif; .endif; .endif; .endif; .endif > .ifnc r1,r1; .ifnc r1r1,fpr11; .ifnc r1r1,r11fp; .ifnc r1r1,ipr12; .ifnc r1r1,r12ip; .err; .endif; .endif; .endif; .endif; .endif > bl __put_user_4 > @ 0 "" 2 > > with the error triggered on the middle line. > /tmp/ccHq8ugv.s: Assembler messages: > /tmp/ccHq8ugv.s:1179: Error: .err encountered > /tmp/ccHq8ugv.s:1331: Error: .err encountered > /tmp/ccHq8ugv.s:4617: Error: .err encountered > /tmp/ccHq8ugv.s:6222: Error: .err encountered > /tmp/ccHq8ugv.s:8705: Error: .err encountered > /tmp/ccHq8ugv.s:14486: Error: .err encountered > /tmp/ccHq8ugv.s:14646: Error: .err encountered > /tmp/ccHq8ugv.s:14806: Error: .err encountered > /tmp/ccHq8ugv.s:14966: Error: .err encountered > /tmp/ccHq8ugv.s:15126: Error: .err encountered > /tmp/ccHq8ugv.s:15286: Error: .err encountered > > That leaves only few issues in our internal components and strange failure with perf which fails to include various header files: perf is building file for qemux86 on o-core I wonder if this is an issue related to your kernel version. > > Cheers, ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFT] GCC 8.1 @ 2018-05-18 5:54 ` Khem Raj 0 siblings, 0 replies; 74+ messages in thread From: Khem Raj @ 2018-05-18 5:54 UTC (permalink / raw) To: Martin Jansa Cc: Yocto Project, openembeded-devel, Patches and discussions about the oe-core layer On Thu, May 17, 2018 at 3:46 AM, Martin Jansa <martin.jansa@gmail.com> wrote: > On Thu, May 10, 2018 at 09:11:45PM +0200, Martin Jansa wrote: >> > > 5) nativesdk-libxcrypt fails to build (not sure which change caused >> > > this, it build OK with sumo since the -std=gnu99 addition. >> > > ../git/crypt-sunmd5.c:189:13: error: 'snprintf' output may be truncated >> > > before the last format character [-Werror=format-truncation=] >> > > "$" CRYPT_ALGNAME "," ROUNDS "%u$%s$", >> > > ^~~ >> > > >> > >> > something new, I will look into reproducing this. > > The fix from you worked for me, thanks! There is a followup here which now doesnt need local patch http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/master&id=0924a69244892097f60adbf6c7f576375bea7870 > Just FYI if someone needs similar fix, backporting this: > https://patchwork.kernel.org/patch/9170055/ > > fixed the issue for me, now I have successful kernel build. > > The failing code was always in put_user calls, e.g. kernel/exit.s was showing: > @ 1581 "kernel-source/kernel/exit.c" 1 > .ifnc r0,r0; .ifnc r0r0,fpr11; .ifnc r0r0,r11fp; .ifnc r0r0,ipr12; .ifnc r0r0,r12ip; .err; .endif; .endif; .endif; .endif; .endif > .ifnc r5,r2; .ifnc r5r2,fpr11; .ifnc r5r2,r11fp; .ifnc r5r2,ipr12; .ifnc r5r2,r12ip; .err; .endif; .endif; .endif; .endif; .endif > .ifnc r1,r1; .ifnc r1r1,fpr11; .ifnc r1r1,r11fp; .ifnc r1r1,ipr12; .ifnc r1r1,r12ip; .err; .endif; .endif; .endif; .endif; .endif > bl __put_user_4 > @ 0 "" 2 > > with the error triggered on the middle line. > /tmp/ccHq8ugv.s: Assembler messages: > /tmp/ccHq8ugv.s:1179: Error: .err encountered > /tmp/ccHq8ugv.s:1331: Error: .err encountered > /tmp/ccHq8ugv.s:4617: Error: .err encountered > /tmp/ccHq8ugv.s:6222: Error: .err encountered > /tmp/ccHq8ugv.s:8705: Error: .err encountered > /tmp/ccHq8ugv.s:14486: Error: .err encountered > /tmp/ccHq8ugv.s:14646: Error: .err encountered > /tmp/ccHq8ugv.s:14806: Error: .err encountered > /tmp/ccHq8ugv.s:14966: Error: .err encountered > /tmp/ccHq8ugv.s:15126: Error: .err encountered > /tmp/ccHq8ugv.s:15286: Error: .err encountered > > That leaves only few issues in our internal components and strange failure with perf which fails to include various header files: perf is building file for qemux86 on o-core I wonder if this is an issue related to your kernel version. > > Cheers, ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [OE-core] [RFT] GCC 8.1 2018-05-17 10:46 ` Martin Jansa @ 2018-05-24 15:08 ` Martin Jansa -1 siblings, 0 replies; 74+ messages in thread From: Martin Jansa @ 2018-05-24 15:08 UTC (permalink / raw) To: Khem Raj Cc: Yocto Project, openembeded-devel, Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 5423 bytes --] > That leaves only few issues in our internal components and strange failure with perf which fails to include various header files: > perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory > perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory > perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory > perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory > perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory > perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory > perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory > perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory > perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory > perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory > perf/1.0-r9/perf-1.0/tools/perf/arch/arm/include/../../../../include/asm-generic/bitops/fls.h:1:56: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/arch/arm/include/../../../../include/asm-generic/bitops/fls.h:1:56: error: #include nested too deeply > ... This issue wasn't caused by gcc upgrade, it was caused by: https://patchwork.openembedded.org/patch/150269/ which was included in the same batch of updates when I've included these RFT changes. I've sent separate fix for perf with slightly longer explanation what was wrong: https://patchwork.openembedded.org/patch/151017/ Now I got a bit further with testing again, remaining 3 issues in public recipes: gcc-sanitizers/8.1.0-r0 fails to build with qemuarm (with thumb enabled): {standard input}: Assembler messages: {standard input}:5724: Error: lo register required -- `ldr ip,[sp],#8' make[2]: *** [sanitizer_linux.lo] Error 1 qtbase/5.6.3+gitAUTOINC+e6f8b072d2-r0 fails to build with qemuarm (with thumb enabled): {standard input}: Assembler messages: {standard input}: Error: unaligned opcodes detected in executable segment make[2]: *** [.obj/qdrawhelper.o] Error 1 lib32-glibc-initial/2.27-r0 fails to build with multilib checking installed Linux kernel header files... missing or too old! configure: error: GNU libc requires kernel header files from Linux 3.2.0 or later to be installed before configuring. The kernel header files are found usually in /usr/include/asm and /usr/include/linux; make sure these directories use files from Linux 3.2.0 or later. This check uses <linux/version.h>, so make sure that file was built correctly when installing the kernel header files. To use kernel headers not from /usr/include/linux, use the configure option --with-headers. WARNING: exit code 1 from a shell command. Regards, -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 201 bytes --] ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFT] GCC 8.1 @ 2018-05-24 15:08 ` Martin Jansa 0 siblings, 0 replies; 74+ messages in thread From: Martin Jansa @ 2018-05-24 15:08 UTC (permalink / raw) To: Khem Raj Cc: Yocto Project, openembeded-devel, Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 5423 bytes --] > That leaves only few issues in our internal components and strange failure with perf which fails to include various header files: > perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory > perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory > perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory > perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory > perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory > perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory > perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory > perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory > perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory > perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: ../../../../include/uapi/linux/swab.h: No such file or directory > perf/1.0-r9/perf-1.0/tools/perf/arch/arm/include/../../../../include/asm-generic/bitops/fls.h:1:56: error: #include nested too deeply > perf/1.0-r9/perf-1.0/tools/perf/arch/arm/include/../../../../include/asm-generic/bitops/fls.h:1:56: error: #include nested too deeply > ... This issue wasn't caused by gcc upgrade, it was caused by: https://patchwork.openembedded.org/patch/150269/ which was included in the same batch of updates when I've included these RFT changes. I've sent separate fix for perf with slightly longer explanation what was wrong: https://patchwork.openembedded.org/patch/151017/ Now I got a bit further with testing again, remaining 3 issues in public recipes: gcc-sanitizers/8.1.0-r0 fails to build with qemuarm (with thumb enabled): {standard input}: Assembler messages: {standard input}:5724: Error: lo register required -- `ldr ip,[sp],#8' make[2]: *** [sanitizer_linux.lo] Error 1 qtbase/5.6.3+gitAUTOINC+e6f8b072d2-r0 fails to build with qemuarm (with thumb enabled): {standard input}: Assembler messages: {standard input}: Error: unaligned opcodes detected in executable segment make[2]: *** [.obj/qdrawhelper.o] Error 1 lib32-glibc-initial/2.27-r0 fails to build with multilib checking installed Linux kernel header files... missing or too old! configure: error: GNU libc requires kernel header files from Linux 3.2.0 or later to be installed before configuring. The kernel header files are found usually in /usr/include/asm and /usr/include/linux; make sure these directories use files from Linux 3.2.0 or later. This check uses <linux/version.h>, so make sure that file was built correctly when installing the kernel header files. To use kernel headers not from /usr/include/linux, use the configure option --with-headers. WARNING: exit code 1 from a shell command. Regards, -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 201 bytes --] ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [OE-core] [RFT] GCC 8.1 2018-05-05 0:26 [RFT] GCC 8.1 Khem Raj @ 2018-05-10 14:34 ` Dan McGregor 2018-05-09 9:38 ` Martin Jansa ` (2 subsequent siblings) 3 siblings, 0 replies; 74+ messages in thread From: Dan McGregor @ 2018-05-10 14:34 UTC (permalink / raw) To: Khem Raj Cc: Yocto Project, openembeded-devel, Patches and discussions about the oe-core layer On 4 May 2018 at 18:26, Khem Raj <raj.khem@gmail.com> wrote: > Hi All > > As you might have noticed that gcc 8.1 was released this week, I am > calling out for some testing help on testing branch so we can weed out > issues you might see in your setups. so if you have your > builders idling over weekend, then you know what they can do this weekend :) > Thanks for this. The only two issues I noticed are that the Wandboard's kernel doesn't compile with gcc 8.1, and gcc-sanitizers now throws a packaging error on (at least) x86_64. ${libdir}/liblsan_preinit.o is a new file that should go into liblsan-dev. > Highlighted changes are > > https://gcc.gnu.org/gcc-8/changes.html > > and porting doc is > > https://gcc.gnu.org/gcc-8/porting_to.html > > The branch is here > > http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8 > > Its uptodate on top of current master oe-core > > May fourth be with you !! > > Cheers! > > -Khem > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFT] GCC 8.1 @ 2018-05-10 14:34 ` Dan McGregor 0 siblings, 0 replies; 74+ messages in thread From: Dan McGregor @ 2018-05-10 14:34 UTC (permalink / raw) To: Khem Raj Cc: Yocto Project, openembeded-devel, Patches and discussions about the oe-core layer On 4 May 2018 at 18:26, Khem Raj <raj.khem@gmail.com> wrote: > Hi All > > As you might have noticed that gcc 8.1 was released this week, I am > calling out for some testing help on testing branch so we can weed out > issues you might see in your setups. so if you have your > builders idling over weekend, then you know what they can do this weekend :) > Thanks for this. The only two issues I noticed are that the Wandboard's kernel doesn't compile with gcc 8.1, and gcc-sanitizers now throws a packaging error on (at least) x86_64. ${libdir}/liblsan_preinit.o is a new file that should go into liblsan-dev. > Highlighted changes are > > https://gcc.gnu.org/gcc-8/changes.html > > and porting doc is > > https://gcc.gnu.org/gcc-8/porting_to.html > > The branch is here > > http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8 > > Its uptodate on top of current master oe-core > > May fourth be with you !! > > Cheers! > > -Khem > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [OE-core] [RFT] GCC 8.1 2018-05-10 14:34 ` Dan McGregor @ 2018-05-10 18:53 ` Khem Raj -1 siblings, 0 replies; 74+ messages in thread From: Khem Raj @ 2018-05-10 18:53 UTC (permalink / raw) To: Dan McGregor Cc: Yocto Project, openembeded-devel, Patches and discussions about the oe-core layer Hi Dan, Thanks for testing On 5/10/18 7:34 AM, Dan McGregor wrote: > On 4 May 2018 at 18:26, Khem Raj <raj.khem@gmail.com> wrote: >> Hi All >> >> As you might have noticed that gcc 8.1 was released this week, I am >> calling out for some testing help on testing branch so we can weed out >> issues you might see in your setups. so if you have your >> builders idling over weekend, then you know what they can do this weekend :) >> > > Thanks for this. The only two issues I noticed are that the > Wandboard's kernel doesn't compile with gcc 8.1, what errors do you see ? and gcc-sanitizers > now throws a packaging error on (at least) x86_64. > ${libdir}/liblsan_preinit.o is a new file that should go into > liblsan-dev. That seems to be the case, I wonder why my world build for qemux86_64 did not find this error. I would like to reproduce this and the fix is then simple. > >> Highlighted changes are >> >> https://gcc.gnu.org/gcc-8/changes.html >> >> and porting doc is >> >> https://gcc.gnu.org/gcc-8/porting_to.html >> >> The branch is here >> >> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8 >> >> Its uptodate on top of current master oe-core >> >> May fourth be with you !! >> >> Cheers! >> >> -Khem >> -- >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFT] GCC 8.1 @ 2018-05-10 18:53 ` Khem Raj 0 siblings, 0 replies; 74+ messages in thread From: Khem Raj @ 2018-05-10 18:53 UTC (permalink / raw) To: Dan McGregor Cc: Yocto Project, openembeded-devel, Patches and discussions about the oe-core layer Hi Dan, Thanks for testing On 5/10/18 7:34 AM, Dan McGregor wrote: > On 4 May 2018 at 18:26, Khem Raj <raj.khem@gmail.com> wrote: >> Hi All >> >> As you might have noticed that gcc 8.1 was released this week, I am >> calling out for some testing help on testing branch so we can weed out >> issues you might see in your setups. so if you have your >> builders idling over weekend, then you know what they can do this weekend :) >> > > Thanks for this. The only two issues I noticed are that the > Wandboard's kernel doesn't compile with gcc 8.1, what errors do you see ? and gcc-sanitizers > now throws a packaging error on (at least) x86_64. > ${libdir}/liblsan_preinit.o is a new file that should go into > liblsan-dev. That seems to be the case, I wonder why my world build for qemux86_64 did not find this error. I would like to reproduce this and the fix is then simple. > >> Highlighted changes are >> >> https://gcc.gnu.org/gcc-8/changes.html >> >> and porting doc is >> >> https://gcc.gnu.org/gcc-8/porting_to.html >> >> The branch is here >> >> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8 >> >> Its uptodate on top of current master oe-core >> >> May fourth be with you !! >> >> Cheers! >> >> -Khem >> -- >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [OE-core] [RFT] GCC 8.1 2018-05-10 18:53 ` Khem Raj @ 2018-05-14 16:33 ` Dan McGregor -1 siblings, 0 replies; 74+ messages in thread From: Dan McGregor @ 2018-05-14 16:33 UTC (permalink / raw) To: Khem Raj Cc: Yocto Project, openembeded-devel, Patches and discussions about the oe-core layer On 10 May 2018 at 12:53, Khem Raj <raj.khem@gmail.com> wrote: > Hi Dan, > > Thanks for testing > > On 5/10/18 7:34 AM, Dan McGregor wrote: >> >> On 4 May 2018 at 18:26, Khem Raj <raj.khem@gmail.com> wrote: >>> >>> Hi All >>> >>> As you might have noticed that gcc 8.1 was released this week, I am >>> calling out for some testing help on testing branch so we can weed out >>> issues you might see in your setups. so if you have your >>> builders idling over weekend, then you know what they can do this weekend >>> :) >>> >> >> Thanks for this. The only two issues I noticed are that the >> Wandboard's kernel doesn't compile with gcc 8.1, > > > > what errors do you see ? I expect the standard "Linux 4.1" errors. A bunch of ignored attributes and incompatible type aliases: tmp-glibc/work-shared/wandboard/kernel-source/include/linux/log2.h:22:1: warning: ignoring attribute 'noreturn' because it conflicts with attribute 'const' [-Wattributes] int ____ilog2_NaN(void) tmp-glibc/work-shared/wandboard/kernel-source/include/linux/syscalls.h:195:18: warning: 'sys_clone' alias between functions of incompatible types 'long int(long unsigned int, long unsigned int, int *, int, int *)' and 'long int(long int, long int, long int, long int, long int)' [-Wattribute-alias] asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \ I can give you the full compile log if you'd like, but I think others want it kept off the list. > > and gcc-sanitizers >> >> now throws a packaging error on (at least) x86_64. >> ${libdir}/liblsan_preinit.o is a new file that should go into >> liblsan-dev. > > > That seems to be the case, I wonder why my world build for qemux86_64 did > not find this error. I would like to reproduce this and the fix is then > simple. My x86_64 build was multilib enabled. I doubt that had anything to do with it, but I suppose it's possible. > > >> >>> Highlighted changes are >>> >>> https://gcc.gnu.org/gcc-8/changes.html >>> >>> and porting doc is >>> >>> https://gcc.gnu.org/gcc-8/porting_to.html >>> >>> The branch is here >>> >>> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8 >>> >>> Its uptodate on top of current master oe-core >>> >>> May fourth be with you !! >>> >>> Cheers! >>> >>> -Khem >>> -- >>> _______________________________________________ >>> Openembedded-core mailing list >>> Openembedded-core@lists.openembedded.org >>> http://lists.openembedded.org/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFT] GCC 8.1 @ 2018-05-14 16:33 ` Dan McGregor 0 siblings, 0 replies; 74+ messages in thread From: Dan McGregor @ 2018-05-14 16:33 UTC (permalink / raw) To: Khem Raj Cc: Yocto Project, openembeded-devel, Patches and discussions about the oe-core layer On 10 May 2018 at 12:53, Khem Raj <raj.khem@gmail.com> wrote: > Hi Dan, > > Thanks for testing > > On 5/10/18 7:34 AM, Dan McGregor wrote: >> >> On 4 May 2018 at 18:26, Khem Raj <raj.khem@gmail.com> wrote: >>> >>> Hi All >>> >>> As you might have noticed that gcc 8.1 was released this week, I am >>> calling out for some testing help on testing branch so we can weed out >>> issues you might see in your setups. so if you have your >>> builders idling over weekend, then you know what they can do this weekend >>> :) >>> >> >> Thanks for this. The only two issues I noticed are that the >> Wandboard's kernel doesn't compile with gcc 8.1, > > > > what errors do you see ? I expect the standard "Linux 4.1" errors. A bunch of ignored attributes and incompatible type aliases: tmp-glibc/work-shared/wandboard/kernel-source/include/linux/log2.h:22:1: warning: ignoring attribute 'noreturn' because it conflicts with attribute 'const' [-Wattributes] int ____ilog2_NaN(void) tmp-glibc/work-shared/wandboard/kernel-source/include/linux/syscalls.h:195:18: warning: 'sys_clone' alias between functions of incompatible types 'long int(long unsigned int, long unsigned int, int *, int, int *)' and 'long int(long int, long int, long int, long int, long int)' [-Wattribute-alias] asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \ I can give you the full compile log if you'd like, but I think others want it kept off the list. > > and gcc-sanitizers >> >> now throws a packaging error on (at least) x86_64. >> ${libdir}/liblsan_preinit.o is a new file that should go into >> liblsan-dev. > > > That seems to be the case, I wonder why my world build for qemux86_64 did > not find this error. I would like to reproduce this and the fix is then > simple. My x86_64 build was multilib enabled. I doubt that had anything to do with it, but I suppose it's possible. > > >> >>> Highlighted changes are >>> >>> https://gcc.gnu.org/gcc-8/changes.html >>> >>> and porting doc is >>> >>> https://gcc.gnu.org/gcc-8/porting_to.html >>> >>> The branch is here >>> >>> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8 >>> >>> Its uptodate on top of current master oe-core >>> >>> May fourth be with you !! >>> >>> Cheers! >>> >>> -Khem >>> -- >>> _______________________________________________ >>> Openembedded-core mailing list >>> Openembedded-core@lists.openembedded.org >>> http://lists.openembedded.org/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [OE-core] [RFT] GCC 8.1 2018-05-14 16:33 ` Dan McGregor @ 2018-05-14 17:09 ` Martin Jansa -1 siblings, 0 replies; 74+ messages in thread From: Martin Jansa @ 2018-05-14 17:09 UTC (permalink / raw) To: Dan McGregor Cc: Yocto Project, Patches and discussions about the oe-core layer, openembeded-devel [-- Attachment #1: Type: text/plain, Size: 3168 bytes --] On Mon, May 14, 2018 at 10:33:41AM -0600, Dan McGregor wrote: > On 10 May 2018 at 12:53, Khem Raj <raj.khem@gmail.com> wrote: > > Hi Dan, > > > > Thanks for testing > > > > On 5/10/18 7:34 AM, Dan McGregor wrote: > >> > >> On 4 May 2018 at 18:26, Khem Raj <raj.khem@gmail.com> wrote: > >>> > >>> Hi All > >>> > >>> As you might have noticed that gcc 8.1 was released this week, I am > >>> calling out for some testing help on testing branch so we can weed out > >>> issues you might see in your setups. so if you have your > >>> builders idling over weekend, then you know what they can do this weekend > >>> :) > >>> > >> > >> Thanks for this. The only two issues I noticed are that the > >> Wandboard's kernel doesn't compile with gcc 8.1, > > > > > > > > what errors do you see ? > > I expect the standard "Linux 4.1" errors. A bunch of ignored > attributes and incompatible type aliases: > > tmp-glibc/work-shared/wandboard/kernel-source/include/linux/log2.h:22:1: > warning: ignoring attribute 'noreturn' because it conflicts with > attribute 'const' [-Wattributes] > int ____ilog2_NaN(void) Try backporting this change: https://github.com/torvalds/linux/commit/474c90156c8dcc2fa815e6716cc9394d7930cb9c > tmp-glibc/work-shared/wandboard/kernel-source/include/linux/syscalls.h:195:18: > warning: 'sys_clone' alias between functions of incompatible types > 'long int(long unsigned int, long unsigned int, int *, int, int *)' > and 'long int(long int, long int, long int, long int, long int)' > [-Wattribute-alias] > asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \ > > I can give you the full compile log if you'd like, but I think others > want it kept off the list. > > > > > and gcc-sanitizers > >> > >> now throws a packaging error on (at least) x86_64. > >> ${libdir}/liblsan_preinit.o is a new file that should go into > >> liblsan-dev. > > > > > > That seems to be the case, I wonder why my world build for qemux86_64 did > > not find this error. I would like to reproduce this and the fix is then > > simple. > > My x86_64 build was multilib enabled. I doubt that had anything to do > with it, but I suppose it's possible. > > > > > > >> > >>> Highlighted changes are > >>> > >>> https://gcc.gnu.org/gcc-8/changes.html > >>> > >>> and porting doc is > >>> > >>> https://gcc.gnu.org/gcc-8/porting_to.html > >>> > >>> The branch is here > >>> > >>> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8 > >>> > >>> Its uptodate on top of current master oe-core > >>> > >>> May fourth be with you !! > >>> > >>> Cheers! > >>> > >>> -Khem > >>> -- > >>> _______________________________________________ > >>> Openembedded-core mailing list > >>> Openembedded-core@lists.openembedded.org > >>> http://lists.openembedded.org/mailman/listinfo/openembedded-core > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 201 bytes --] ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFT] GCC 8.1 @ 2018-05-14 17:09 ` Martin Jansa 0 siblings, 0 replies; 74+ messages in thread From: Martin Jansa @ 2018-05-14 17:09 UTC (permalink / raw) To: Dan McGregor Cc: Yocto Project, Patches and discussions about the oe-core layer, openembeded-devel [-- Attachment #1: Type: text/plain, Size: 3168 bytes --] On Mon, May 14, 2018 at 10:33:41AM -0600, Dan McGregor wrote: > On 10 May 2018 at 12:53, Khem Raj <raj.khem@gmail.com> wrote: > > Hi Dan, > > > > Thanks for testing > > > > On 5/10/18 7:34 AM, Dan McGregor wrote: > >> > >> On 4 May 2018 at 18:26, Khem Raj <raj.khem@gmail.com> wrote: > >>> > >>> Hi All > >>> > >>> As you might have noticed that gcc 8.1 was released this week, I am > >>> calling out for some testing help on testing branch so we can weed out > >>> issues you might see in your setups. so if you have your > >>> builders idling over weekend, then you know what they can do this weekend > >>> :) > >>> > >> > >> Thanks for this. The only two issues I noticed are that the > >> Wandboard's kernel doesn't compile with gcc 8.1, > > > > > > > > what errors do you see ? > > I expect the standard "Linux 4.1" errors. A bunch of ignored > attributes and incompatible type aliases: > > tmp-glibc/work-shared/wandboard/kernel-source/include/linux/log2.h:22:1: > warning: ignoring attribute 'noreturn' because it conflicts with > attribute 'const' [-Wattributes] > int ____ilog2_NaN(void) Try backporting this change: https://github.com/torvalds/linux/commit/474c90156c8dcc2fa815e6716cc9394d7930cb9c > tmp-glibc/work-shared/wandboard/kernel-source/include/linux/syscalls.h:195:18: > warning: 'sys_clone' alias between functions of incompatible types > 'long int(long unsigned int, long unsigned int, int *, int, int *)' > and 'long int(long int, long int, long int, long int, long int)' > [-Wattribute-alias] > asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \ > > I can give you the full compile log if you'd like, but I think others > want it kept off the list. > > > > > and gcc-sanitizers > >> > >> now throws a packaging error on (at least) x86_64. > >> ${libdir}/liblsan_preinit.o is a new file that should go into > >> liblsan-dev. > > > > > > That seems to be the case, I wonder why my world build for qemux86_64 did > > not find this error. I would like to reproduce this and the fix is then > > simple. > > My x86_64 build was multilib enabled. I doubt that had anything to do > with it, but I suppose it's possible. > > > > > > >> > >>> Highlighted changes are > >>> > >>> https://gcc.gnu.org/gcc-8/changes.html > >>> > >>> and porting doc is > >>> > >>> https://gcc.gnu.org/gcc-8/porting_to.html > >>> > >>> The branch is here > >>> > >>> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8 > >>> > >>> Its uptodate on top of current master oe-core > >>> > >>> May fourth be with you !! > >>> > >>> Cheers! > >>> > >>> -Khem > >>> -- > >>> _______________________________________________ > >>> Openembedded-core mailing list > >>> Openembedded-core@lists.openembedded.org > >>> http://lists.openembedded.org/mailman/listinfo/openembedded-core > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 201 bytes --] ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [OE-core] [RFT] GCC 8.1 2018-05-05 0:26 [RFT] GCC 8.1 Khem Raj @ 2018-05-11 22:05 ` Burton, Ross 2018-05-09 9:38 ` Martin Jansa ` (2 subsequent siblings) 3 siblings, 0 replies; 74+ messages in thread From: Burton, Ross @ 2018-05-11 22:05 UTC (permalink / raw) To: Khem Raj Cc: Yocto Project, openembeded-devel, Patches and discussions about the oe-core layer I threw the branch at the Yocto Project autobuilder today, produced a number of failures: http://errors.yoctoproject.org/Errors/Latest//?filter=b23dba19607412c8cc7d267d95354d65f5631088&type=commit Ross On 5 May 2018 at 01:26, Khem Raj <raj.khem@gmail.com> wrote: > Hi All > > As you might have noticed that gcc 8.1 was released this week, I am > calling out for some testing help on testing branch so we can weed out > issues you might see in your setups. so if you have your > builders idling over weekend, then you know what they can do this weekend :) > > Highlighted changes are > > https://gcc.gnu.org/gcc-8/changes.html > > and porting doc is > > https://gcc.gnu.org/gcc-8/porting_to.html > > The branch is here > > http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8 > > Its uptodate on top of current master oe-core > > May fourth be with you !! > > Cheers! > > -Khem > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFT] GCC 8.1 @ 2018-05-11 22:05 ` Burton, Ross 0 siblings, 0 replies; 74+ messages in thread From: Burton, Ross @ 2018-05-11 22:05 UTC (permalink / raw) To: Khem Raj Cc: Yocto Project, openembeded-devel, Patches and discussions about the oe-core layer I threw the branch at the Yocto Project autobuilder today, produced a number of failures: http://errors.yoctoproject.org/Errors/Latest//?filter=b23dba19607412c8cc7d267d95354d65f5631088&type=commit Ross On 5 May 2018 at 01:26, Khem Raj <raj.khem@gmail.com> wrote: > Hi All > > As you might have noticed that gcc 8.1 was released this week, I am > calling out for some testing help on testing branch so we can weed out > issues you might see in your setups. so if you have your > builders idling over weekend, then you know what they can do this weekend :) > > Highlighted changes are > > https://gcc.gnu.org/gcc-8/changes.html > > and porting doc is > > https://gcc.gnu.org/gcc-8/porting_to.html > > The branch is here > > http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8 > > Its uptodate on top of current master oe-core > > May fourth be with you !! > > Cheers! > > -Khem > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [OE-core] [RFT] GCC 8.1 2018-05-11 22:05 ` Burton, Ross @ 2018-05-12 6:10 ` Khem Raj -1 siblings, 0 replies; 74+ messages in thread From: Khem Raj @ 2018-05-12 6:10 UTC (permalink / raw) To: Burton, Ross Cc: Yocto Project, openembeded-devel, Patches and discussions about the oe-core layer Hi Ross Thanks for testing I looked at failures and one of them is RESULTS - kernelmodule.KernelModuleTest.test_kernel_module - Testcase 1541: FAILED and this is the compile error. pager.c: In function 'pager_preexec': pager.c:36:12: error: passing argument 2 to restrict-qualified parameter aliases with argument 4 [-Werror=restrict] select(1, &in, NULL, &in, NULL); ^~~ ~~~ cc1: all warnings being treated as errors mv: cannot stat '/usr/src/kernel/tools/objtool/.pager.o.tmp': No such file or directory Firstly I must say that I am impressed with autotest, We are building on-device toolchain and then downloading a kernel and building it to test i.. bravo Problem here is that poky pins linux-yocto to 4.14, with gcc8 we need to use 4.15.x eventually 4.14 will get fixed but until then use 4.15, the test subject component that is being compiled is not ported to gcc-8, not sure how we can improve it. Is it compiling linux-yocto kmods ? or external kmod ? We need to patch the test before building, I think the mesa error is new with mesa-18 I havent seen this on my end. Its showing up when we enable llvmpipe which is not general default so it might not happen in general. selftest is failing like this | Copying files into the device: __populate_fs: Could not allocate block in ext2 filesystem while writing file "ldconfig" | mkfs.ext4: Could not allocate block in ext2 filesystem while populating file system | WARNING: /tmp/eSDKQAfqaczn6s/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/temp/run.do_image_ext4.15615:1 exit 1 from 'mkfs.$fstype -F $extra_imagecmd /tmp/eSDKQAfqaczn6s/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/deploy-core-image-minimal-image-complete/core-image-minimal-qemux86-64-20180511212710.rootfs.$fstype -d /tmp/eSDKQAfqaczn6s/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs' not sure if I understand it fully but it sems system ran out of disk space. On Fri, May 11, 2018 at 3:05 PM, Burton, Ross <ross.burton@intel.com> wrote: > I threw the branch at the Yocto Project autobuilder today, produced a > number of failures: > > http://errors.yoctoproject.org/Errors/Latest//?filter=b23dba19607412c8cc7d267d95354d65f5631088&type=commit > > Ross > > On 5 May 2018 at 01:26, Khem Raj <raj.khem@gmail.com> wrote: >> Hi All >> >> As you might have noticed that gcc 8.1 was released this week, I am >> calling out for some testing help on testing branch so we can weed out >> issues you might see in your setups. so if you have your >> builders idling over weekend, then you know what they can do this weekend :) >> >> Highlighted changes are >> >> https://gcc.gnu.org/gcc-8/changes.html >> >> and porting doc is >> >> https://gcc.gnu.org/gcc-8/porting_to.html >> >> The branch is here >> >> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8 >> >> Its uptodate on top of current master oe-core >> >> May fourth be with you !! >> >> Cheers! >> >> -Khem >> -- >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFT] GCC 8.1 @ 2018-05-12 6:10 ` Khem Raj 0 siblings, 0 replies; 74+ messages in thread From: Khem Raj @ 2018-05-12 6:10 UTC (permalink / raw) To: Burton, Ross Cc: Yocto Project, openembeded-devel, Patches and discussions about the oe-core layer Hi Ross Thanks for testing I looked at failures and one of them is RESULTS - kernelmodule.KernelModuleTest.test_kernel_module - Testcase 1541: FAILED and this is the compile error. pager.c: In function 'pager_preexec': pager.c:36:12: error: passing argument 2 to restrict-qualified parameter aliases with argument 4 [-Werror=restrict] select(1, &in, NULL, &in, NULL); ^~~ ~~~ cc1: all warnings being treated as errors mv: cannot stat '/usr/src/kernel/tools/objtool/.pager.o.tmp': No such file or directory Firstly I must say that I am impressed with autotest, We are building on-device toolchain and then downloading a kernel and building it to test i.. bravo Problem here is that poky pins linux-yocto to 4.14, with gcc8 we need to use 4.15.x eventually 4.14 will get fixed but until then use 4.15, the test subject component that is being compiled is not ported to gcc-8, not sure how we can improve it. Is it compiling linux-yocto kmods ? or external kmod ? We need to patch the test before building, I think the mesa error is new with mesa-18 I havent seen this on my end. Its showing up when we enable llvmpipe which is not general default so it might not happen in general. selftest is failing like this | Copying files into the device: __populate_fs: Could not allocate block in ext2 filesystem while writing file "ldconfig" | mkfs.ext4: Could not allocate block in ext2 filesystem while populating file system | WARNING: /tmp/eSDKQAfqaczn6s/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/temp/run.do_image_ext4.15615:1 exit 1 from 'mkfs.$fstype -F $extra_imagecmd /tmp/eSDKQAfqaczn6s/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/deploy-core-image-minimal-image-complete/core-image-minimal-qemux86-64-20180511212710.rootfs.$fstype -d /tmp/eSDKQAfqaczn6s/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs' not sure if I understand it fully but it sems system ran out of disk space. On Fri, May 11, 2018 at 3:05 PM, Burton, Ross <ross.burton@intel.com> wrote: > I threw the branch at the Yocto Project autobuilder today, produced a > number of failures: > > http://errors.yoctoproject.org/Errors/Latest//?filter=b23dba19607412c8cc7d267d95354d65f5631088&type=commit > > Ross > > On 5 May 2018 at 01:26, Khem Raj <raj.khem@gmail.com> wrote: >> Hi All >> >> As you might have noticed that gcc 8.1 was released this week, I am >> calling out for some testing help on testing branch so we can weed out >> issues you might see in your setups. so if you have your >> builders idling over weekend, then you know what they can do this weekend :) >> >> Highlighted changes are >> >> https://gcc.gnu.org/gcc-8/changes.html >> >> and porting doc is >> >> https://gcc.gnu.org/gcc-8/porting_to.html >> >> The branch is here >> >> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8 >> >> Its uptodate on top of current master oe-core >> >> May fourth be with you !! >> >> Cheers! >> >> -Khem >> -- >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [OE-core] [RFT] GCC 8.1 2018-05-11 22:05 ` Burton, Ross @ 2018-05-13 23:35 ` Khem Raj -1 siblings, 0 replies; 74+ messages in thread From: Khem Raj @ 2018-05-13 23:35 UTC (permalink / raw) To: Burton, Ross Cc: Yocto Project, openembeded-devel, Patches and discussions about the oe-core layer Hi Ross I pushed a few more fixes to branch which fixes kernel build issue ovmf build issue python2 build issue (your fix) I could not reproduce the mesa issues that is shown on AB With this I think we should be in better shape. Can you retry http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/master Once again and please bump the kernel version in poky to default by removing the pinning meta-poky/conf/distro/poky-lsb.conf:PREFERRED_VERSION_linux-yocto_linuxstdbase ?= "4.14%" meta-poky/conf/distro/poky-tiny.conf:PREFERRED_VERSION_linux-yocto-tiny ?= "4.14%" meta-poky/conf/distro/poky.conf:PREFERRED_VERSION_linux-yocto ?= "4.14%" Thanks -Khem On 5/11/18 3:05 PM, Burton, Ross wrote: > I threw the branch at the Yocto Project autobuilder today, produced a > number of failures: > > http://errors.yoctoproject.org/Errors/Latest//?filter=b23dba19607412c8cc7d267d95354d65f5631088&type=commit > > Ross > > On 5 May 2018 at 01:26, Khem Raj <raj.khem@gmail.com> wrote: >> Hi All >> >> As you might have noticed that gcc 8.1 was released this week, I am >> calling out for some testing help on testing branch so we can weed out >> issues you might see in your setups. so if you have your >> builders idling over weekend, then you know what they can do this weekend :) >> >> Highlighted changes are >> >> https://gcc.gnu.org/gcc-8/changes.html >> >> and porting doc is >> >> https://gcc.gnu.org/gcc-8/porting_to.html >> >> The branch is here >> >> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8 >> >> Its uptodate on top of current master oe-core >> >> May fourth be with you !! >> >> Cheers! >> >> -Khem >> -- >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: [RFT] GCC 8.1 @ 2018-05-13 23:35 ` Khem Raj 0 siblings, 0 replies; 74+ messages in thread From: Khem Raj @ 2018-05-13 23:35 UTC (permalink / raw) To: Burton, Ross Cc: Yocto Project, openembeded-devel, Patches and discussions about the oe-core layer Hi Ross I pushed a few more fixes to branch which fixes kernel build issue ovmf build issue python2 build issue (your fix) I could not reproduce the mesa issues that is shown on AB With this I think we should be in better shape. Can you retry http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/master Once again and please bump the kernel version in poky to default by removing the pinning meta-poky/conf/distro/poky-lsb.conf:PREFERRED_VERSION_linux-yocto_linuxstdbase ?= "4.14%" meta-poky/conf/distro/poky-tiny.conf:PREFERRED_VERSION_linux-yocto-tiny ?= "4.14%" meta-poky/conf/distro/poky.conf:PREFERRED_VERSION_linux-yocto ?= "4.14%" Thanks -Khem On 5/11/18 3:05 PM, Burton, Ross wrote: > I threw the branch at the Yocto Project autobuilder today, produced a > number of failures: > > http://errors.yoctoproject.org/Errors/Latest//?filter=b23dba19607412c8cc7d267d95354d65f5631088&type=commit > > Ross > > On 5 May 2018 at 01:26, Khem Raj <raj.khem@gmail.com> wrote: >> Hi All >> >> As you might have noticed that gcc 8.1 was released this week, I am >> calling out for some testing help on testing branch so we can weed out >> issues you might see in your setups. so if you have your >> builders idling over weekend, then you know what they can do this weekend :) >> >> Highlighted changes are >> >> https://gcc.gnu.org/gcc-8/changes.html >> >> and porting doc is >> >> https://gcc.gnu.org/gcc-8/porting_to.html >> >> The branch is here >> >> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8 >> >> Its uptodate on top of current master oe-core >> >> May fourth be with you !! >> >> Cheers! >> >> -Khem >> -- >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 74+ messages in thread
end of thread, other threads:[~2018-06-10 11:05 UTC | newest] Thread overview: 74+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-05-05 0:26 [RFT] GCC 8.1 Khem Raj 2018-05-05 7:31 ` Zoran Stojsavljevic 2018-05-10 19:21 ` Khem Raj 2018-05-10 19:21 ` [yocto] " Khem Raj 2018-05-09 9:38 ` [OE-core] " Martin Jansa 2018-05-09 9:38 ` Martin Jansa 2018-05-09 9:38 ` Martin Jansa 2018-05-10 12:20 ` [PATCH] busybox: Enable FEATURE_MOUNT_NFS and use libtirpc Martin Jansa 2018-05-10 13:01 ` Burton, Ross 2018-05-10 18:21 ` Khem Raj 2018-05-10 18:24 ` Khem Raj 2018-05-10 19:16 ` Martin Jansa 2018-05-10 19:26 ` Khem Raj 2018-05-30 17:39 ` Andre McCurdy 2018-06-10 11:05 ` Martin Jansa 2018-05-10 18:50 ` [OE-core] [RFT] GCC 8.1 Khem Raj 2018-05-10 18:50 ` Khem Raj 2018-05-10 19:11 ` [OE-core] " Martin Jansa 2018-05-10 19:11 ` Martin Jansa 2018-05-10 19:27 ` [OE-core] " Andre McCurdy 2018-05-10 19:27 ` Andre McCurdy 2018-05-10 21:43 ` [OE-core] " Martin Jansa 2018-05-10 21:43 ` Martin Jansa 2018-05-10 22:07 ` [OE-core] " Martin Jansa 2018-05-10 22:07 ` Martin Jansa 2018-05-10 22:35 ` [OE-core] " Khem Raj 2018-05-10 22:35 ` Khem Raj 2018-05-10 22:38 ` [OE-core] " Andre McCurdy 2018-05-10 22:38 ` Andre McCurdy 2018-05-10 22:38 ` [OE-core] " Martin Jansa 2018-05-10 22:38 ` Martin Jansa 2018-05-10 22:38 ` Martin Jansa 2018-05-10 22:40 ` [OE-core] " Andre McCurdy 2018-05-10 22:40 ` Andre McCurdy 2018-05-10 22:50 ` [OE-core] " Martin Jansa 2018-05-10 22:50 ` Martin Jansa 2018-05-10 23:11 ` [OE-core] " Andre McCurdy 2018-05-10 23:11 ` Andre McCurdy 2018-05-10 23:32 ` [OE-core] " Martin Jansa 2018-05-10 23:32 ` Martin Jansa 2018-05-10 23:41 ` [OE-core] " Andre McCurdy 2018-05-10 23:41 ` Andre McCurdy 2018-05-11 0:55 ` [OE-core] " Khem Raj 2018-05-11 0:55 ` Khem Raj 2018-05-11 1:00 ` [OE-core] " Andre McCurdy 2018-05-11 1:00 ` Andre McCurdy 2018-05-11 1:06 ` [OE-core] " Khem Raj 2018-05-11 1:06 ` Khem Raj 2018-05-11 1:11 ` [OE-core] " Andre McCurdy 2018-05-11 1:11 ` Andre McCurdy 2018-05-11 1:16 ` [OE-core] " Khem Raj 2018-05-11 1:16 ` Khem Raj 2018-05-11 1:21 ` [OE-core] " Andre McCurdy 2018-05-11 1:21 ` Andre McCurdy 2018-05-17 10:46 ` [OE-core] " Martin Jansa 2018-05-17 10:46 ` Martin Jansa 2018-05-18 5:54 ` [OE-core] " Khem Raj 2018-05-18 5:54 ` Khem Raj 2018-05-24 15:08 ` [OE-core] " Martin Jansa 2018-05-24 15:08 ` Martin Jansa 2018-05-10 14:34 ` [OE-core] " Dan McGregor 2018-05-10 14:34 ` Dan McGregor 2018-05-10 18:53 ` [OE-core] " Khem Raj 2018-05-10 18:53 ` Khem Raj 2018-05-14 16:33 ` [OE-core] " Dan McGregor 2018-05-14 16:33 ` Dan McGregor 2018-05-14 17:09 ` [OE-core] " Martin Jansa 2018-05-14 17:09 ` Martin Jansa 2018-05-11 22:05 ` [OE-core] " Burton, Ross 2018-05-11 22:05 ` Burton, Ross 2018-05-12 6:10 ` [OE-core] " Khem Raj 2018-05-12 6:10 ` Khem Raj 2018-05-13 23:35 ` [OE-core] " Khem Raj 2018-05-13 23:35 ` Khem Raj
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.