GCC 8.1

May fourth be with you !!

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
[email protected]
https://lists.yoctoproject.org/listinfo/yocto

Quoted 1 line

May fourth be with you !!

@off topic!

Who is here (and in wider context) Darth Vader? Bourne Kingpin (BK)? ;-)

Zoran
_______

Quoted 31 lines · Khem Raj

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
[email protected]
https://lists.yoctoproject.org/listinfo/yocto

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
[email protected]
http://lists.openembedded.org/mailman/listinfo/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 <[email protected]>

---
 meta/recipes-core/busybox/busybox.inc       | 6 +++---
 meta/recipes-core/busybox/busybox/defconfig | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

meta/recipes-core/busybox/busybox.inc +3 -3

index d1675c37aa..2db19ed317 100644
@@ -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}'"
 

meta/recipes-core/busybox/busybox/defconfig +1 -2

index fbb5fd852c..816555fc21 100644
@@ -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
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-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

Quoted 59 lines · Martin Jansa

* 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 <[email protected]>

---
  meta/recipes-core/busybox/busybox.inc       | 6 +++---
  meta/recipes-core/busybox/busybox/defconfig | 2 +-
  2 files changed, 4 insertions(+), 4 deletions(-)

meta/recipes-core/busybox/busybox.inc +3 -3

index d1675c37aa..2db19ed317 100644
@@ -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}'"
 

meta/recipes-core/busybox/busybox/defconfig +1 -2

index fbb5fd852c..816555fc21 100644
@@ -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
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Quoted 36 lines · Ross

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'

Quoted 9 lines

| /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

Quoted 63 lines

Ross

Quoted 60 lines · Martin Jansa

* 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 <[email protected]>

---
  meta/recipes-core/busybox/busybox.inc       | 6 +++--- meta/recipes-core/busybox/busybox/defconfig | 2 +-

  2 files changed, 4 insertions(+), 4 deletions(-)

meta/recipes-core/busybox/busybox.inc +0 -0

index d1675c37aa..2db19ed317 100644
@@ -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/"

meta/recipes-core/busybox/busybox.inc +1 -1

-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

meta/recipes-core/busybox/busybox.inc +0 -0

@@ -15,8 +15,8 @@ SECTION = "base"
   # Whether to split the suid apps into a seperate binary

  BUSYBOX_SPLIT_SUID ?= "1"

meta/recipes-core/busybox/busybox.inc +2 -2

-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}'"

meta/recipes-core/busybox/busybox/defconfig +1 -1

index fbb5fd852c..816555fc21 100644
@@ -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

Signature · 7 lines

2.17.0

-- 
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Quoted 74 lines · Khem Raj

Quoted 51 lines · Ross

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'
|

Quoted 9 lines

/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

Quoted 4 lines

# 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.

Quoted 68 lines

Quoted 68 lines

Ross

Quoted 65 lines · Martin Jansa

* 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 <[email protected]>

---
  meta/recipes-core/busybox/busybox.inc       | 6 +++--- meta/recipes-core/busybox/busybox/defconfig | 2 +-

  2 files changed, 4 insertions(+), 4 deletions(-)

meta/recipes-core/busybox/busybox.inc +0 -0

index d1675c37aa..2db19ed317 100644
@@ -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/"

meta/recipes-core/busybox/busybox.inc +1 -1

-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

meta/recipes-core/busybox/busybox.inc +0 -0

@@ -15,8 +15,8 @@ SECTION = "base"
   # Whether to split the suid apps into a seperate binary

  BUSYBOX_SPLIT_SUID ?= "1"

meta/recipes-core/busybox/busybox.inc +2 -2

-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}'"

meta/recipes-core/busybox/busybox/defconfig +1 -1

index fbb5fd852c..816555fc21 100644
@@ -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

Signature · 7 lines

2.17.0

-- 
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Quoted 3 lines

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).

Quoted 8 lines · Martin Jansa

Quoted 4 lines

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.

Quoted 3 lines

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

Quoted 13 lines · Khem Raj

Quoted 11 lines · Martin Jansa

Quoted 4 lines

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).

Quoted 3 lines

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).

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 <[email protected] <mailto:[email protected]>> 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 [email protected] <mailto:[email protected]>
http://lists.openembedded.org/mailman/listinfo/openembedded-core
<http://lists.openembedded.org/mailman/listinfo/openembedded-core>

Hi Martin

Thanks for testing and reporting back

Quoted 12 lines · Martin Jansa

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 ?

Quoted 8 lines

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

Quoted 5 lines

  # 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.

Quoted 18 lines

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

Quoted 8 lines

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

Quoted 8 lines

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.

Quoted 2 lines

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

Quoted 6 lines

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.

Quoted 48 lines

Cheers,

On Sat, May 5, 2018 at 2:26 AM, Khem Raj <[email protected] <mailto:[email protected]>> 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 [email protected] <mailto:[email protected]>
http://lists.openembedded.org/mailman/listinfo/openembedded-core
<http://lists.openembedded.org/mailman/listinfo/openembedded-core>

Quoted 18 lines · Khem Raj

Hi Martin

Thanks for testing and reporting back

Quoted 12 lines · Martin Jansa

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
}
^

Quoted 1 line

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.

Quoted 21 lines · Martin Jansa

Quoted 19 lines · Khem Raj

Hi Martin

Thanks for testing and reporting back

Quoted 12 lines · Martin Jansa

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 ?

Quoted 2 lines

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?

Quoted 22 lines · Andre McCurdy

Quoted 21 lines · Martin Jansa

Quoted 19 lines · Khem Raj

Hi Martin

Thanks for testing and reporting back

Quoted 12 lines · Martin Jansa

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 ?

Quoted 7 lines

Quoted 2 lines

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.

Quoted 35 lines · Martin Jansa

Quoted 22 lines · Andre McCurdy

Quoted 21 lines · Martin Jansa

Quoted 19 lines · Khem Raj

Hi Martin

Thanks for testing and reporting back

Quoted 12 lines · Martin Jansa

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 ?

Quoted 7 lines

Quoted 2 lines

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:

Quoted 7 lines

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?

Quoted 35 lines · Martin Jansa

Quoted 22 lines · Andre McCurdy

Quoted 21 lines · Martin Jansa

Quoted 19 lines · Khem Raj

Hi Martin

Thanks for testing and reporting back

Quoted 12 lines · Martin Jansa

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 ?

Quoted 7 lines

Quoted 2 lines

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:

Quoted 7 lines

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?

Quoted 3 lines · Martin Jansa

Quoted 2 lines · Martin Jansa

Quoted 1 line · Andre McCurdy

On Thu, May 10, 2018 at 12:11 PM, Martin Jansa <

Quoted 7 lines · [email protected]> wrote:

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines · Khem Raj

Quoted 6 lines

Hi Martin

Thanks for testing and reporting back

Quoted 1 line · Martin Jansa

My initial tests show couple issues, but usually caused by other

changes

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

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

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

fails to build with ptest enabled (it builds with 4.20 version

if I

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

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

Quoted 12 lines

Quoted 12 lines

Quoted 12 lines

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

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.

Quoted 7 lines

Quoted 7 lines

Quoted 1 line

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

(quoted diff) +0 -15

-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

Quoted 3 lines

Quoted 3 lines

This might come from:
meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer

${DEBUG_FLAGS} -pipe"

Quoted 3 lines

Quoted 3 lines

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.

Quoted 5 lines

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

Quoted 3 lines

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).

see
http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html

Quoted 84 lines

Quoted 72 lines · Martin Jansa

Quoted 59 lines · Martin Jansa

Quoted 27 lines · Andre McCurdy

Quoted 25 lines · Martin Jansa

Quoted 23 lines · Khem Raj

Hi Martin

Thanks for testing and reporting back

Quoted 6 lines · Martin Jansa

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

Quoted 10 lines

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 ?

Quoted 8 lines

Quoted 2 lines

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

(quoted diff) +0 -14

-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

Quoted 7 lines

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:

Quoted 4 lines

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).

Quoted 2 lines · Martin Jansa

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).

Quoted 85 lines · Andre McCurdy

Quoted 84 lines

Quoted 72 lines · Martin Jansa

Quoted 59 lines · Martin Jansa

Quoted 27 lines · Andre McCurdy

Quoted 25 lines · Martin Jansa

Quoted 23 lines · Khem Raj

Hi Martin

Thanks for testing and reporting back

Quoted 6 lines · Martin Jansa

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

Quoted 10 lines

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 ?

Quoted 8 lines

Quoted 2 lines

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

(quoted diff) +0 -14

-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

Quoted 7 lines

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:

Quoted 4 lines

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).

Quoted 4 lines · Andre McCurdy

Quoted 2 lines · Martin Jansa

see
http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html

Quoted 3 lines

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.

Quoted 5 lines · Martin Jansa

Quoted 4 lines · Andre McCurdy

Quoted 2 lines · Martin Jansa

see
http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html

Quoted 8 lines

Quoted 3 lines

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.

Quoted 19 lines · Andre McCurdy

Quoted 5 lines · Martin Jansa

Quoted 4 lines · Andre McCurdy

Quoted 2 lines · Martin Jansa

see
http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html

Quoted 8 lines

Quoted 3 lines

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).

Quoted 5 lines

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

Quoted 5 lines · Martin Jansa

Quoted 4 lines · Andre McCurdy

Quoted 2 lines · Martin Jansa

see
http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html

Quoted 8 lines

Quoted 3 lines

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.

Quoted 19 lines · Andre McCurdy

Quoted 5 lines · Martin Jansa

Quoted 4 lines · Andre McCurdy

Quoted 2 lines · Martin Jansa

see
http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html

Quoted 8 lines

Quoted 3 lines

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).

Quoted 5 lines

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.

Quoted 26 lines · Khem Raj

Quoted 19 lines · Andre McCurdy

Quoted 5 lines · Martin Jansa

Quoted 4 lines · Andre McCurdy

Quoted 2 lines · Martin Jansa

see
http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html

Quoted 8 lines

Quoted 3 lines

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).

Quoted 5 lines

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.

Quoted 5 lines

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.

Quoted 35 lines · Andre McCurdy

Quoted 26 lines · Khem Raj

Quoted 19 lines · Andre McCurdy

Quoted 5 lines · Martin Jansa

Quoted 4 lines · Andre McCurdy

Quoted 2 lines · Martin Jansa

see
http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html

Quoted 8 lines

Quoted 3 lines

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).

Quoted 5 lines

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.

Quoted 5 lines

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.

Quoted 2 lines

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

Quoted 36 lines · Khem Raj

Quoted 35 lines · Andre McCurdy

Quoted 26 lines · Khem Raj

Quoted 19 lines · Andre McCurdy

Quoted 5 lines · Martin Jansa

Quoted 4 lines · Andre McCurdy

Quoted 2 lines · Martin Jansa

see
http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html

Quoted 8 lines

Quoted 3 lines

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).

Quoted 5 lines

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.

Quoted 5 lines

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.

Quoted 8 lines

Quoted 2 lines

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.

Quoted 46 lines · Andre McCurdy

Quoted 44 lines · Khem Raj

Quoted 33 lines · Andre McCurdy

Quoted 26 lines · Khem Raj

Quoted 19 lines · Andre McCurdy

Quoted 5 lines · Martin Jansa

Quoted 4 lines · Andre McCurdy

Quoted 2 lines · Martin Jansa

see
http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html

Quoted 8 lines

Quoted 3 lines

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).

Quoted 5 lines

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.

Quoted 5 lines

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.

Quoted 4 lines

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

Quoted 4 lines

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.

Quoted 9 lines

Quoted 7 lines

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.

Quoted 9 lines

Quoted 5 lines

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.

Quoted 8 lines · Martin Jansa

Quoted 8 lines

Quoted 7 lines

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$",
              ^~~

Quoted 1 line

Quoted 1 line

something new, I will look into reproducing this.

The fix from you worked for me, thanks!

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:

Cheers,

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
...

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
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Quoted 7 lines · Khem Raj

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,

now throws a packaging error on (at least) x86_64. ${libdir}/liblsan_preinit.o is a new file that should go into liblsan-dev.

Quoted 25 lines

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
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Hi Dan,

Thanks for testing

Quoted 12 lines · Dan McGregor

Quoted 9 lines · Khem Raj

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 :)

Quoted 2 lines

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

Quoted 4 lines

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.

Quoted 27 lines

Quoted 27 lines

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
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Quoted 17 lines · Khem Raj

Hi Dan,

Thanks for testing

Quoted 12 lines · Dan McGregor

Quoted 9 lines · Khem Raj

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 :)

Quoted 6 lines

Quoted 2 lines

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.

Quoted 11 lines

and gcc-sanitizers

Quoted 4 lines

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.

Quoted 27 lines

Quoted 27 lines

Quoted 27 lines

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
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Signature · 4 lines

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

Quoted 31 lines · Khem Raj

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
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

Quoted 31 lines · Khem Raj

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
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core