Re: [yocto] [OE-core] [RFT] GCC 8.1

[Martin Jansa]

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

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Khem Raj]

On Thu, May 17, 2018 at 3:46 AM, Martin Jansa  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,
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Martin Jansa]

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 1 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 deepl

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Martin Jansa]

On Mon, May 14, 2018 at 10:33:41AM -0600, Dan McGregor wrote:
> On 10 May 2018 at 12:53, Khem Raj  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  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-c...@lists.openembedded.org
> >>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> -- 
> ___
> Openembedded-core mailing list
> openembedded-c...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Dan McGregor]

On 10 May 2018 at 12:53, Khem Raj  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  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-c...@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Khem Raj]

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  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-c...@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Khem Raj]

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  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  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-c...@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Burton, Ross]

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  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-c...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 6:16 PM, Khem Raj  wrote:
> On Thu, May 10, 2018 at 6:11 PM, Andre McCurdy  wrote:
>> On Thu, May 10, 2018 at 6:06 PM, Khem Raj  wrote:
>>> On Thu, May 10, 2018 at 6:00 PM, Andre McCurdy  wrote:
 On Thu, May 10, 2018 at 5:55 PM, Khem Raj  wrote:
> On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy  
> wrote:
>> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa  
>> 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  
 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 :-)
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Khem Raj]

On Thu, May 10, 2018 at 6:11 PM, Andre McCurdy  wrote:
> On Thu, May 10, 2018 at 6:06 PM, Khem Raj  wrote:
>> On Thu, May 10, 2018 at 6:00 PM, Andre McCurdy  wrote:
>>> On Thu, May 10, 2018 at 5:55 PM, Khem Raj  wrote:
 On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy  wrote:
> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa  
> 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  
>>> 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.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 6:06 PM, Khem Raj  wrote:
> On Thu, May 10, 2018 at 6:00 PM, Andre McCurdy  wrote:
>> On Thu, May 10, 2018 at 5:55 PM, Khem Raj  wrote:
>>> On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy  wrote:
 On Thu, May 10, 2018 at 3:50 PM, Martin Jansa  
 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  
>> 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.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Khem Raj]

On Thu, May 10, 2018 at 6:00 PM, Andre McCurdy  wrote:
> On Thu, May 10, 2018 at 5:55 PM, Khem Raj  wrote:
>> On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy  wrote:
>>> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa  
>>> 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  
> 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
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 5:55 PM, Khem Raj  wrote:
> On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy  wrote:
>> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa  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  
 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.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Khem Raj]

On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy  wrote:
> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa  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  
>>> 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.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 4:32 PM, Martin Jansa  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  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  
>> >> 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)}"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Martin Jansa]

On Thu, May 10, 2018 at 04:11:00PM -0700, Andre McCurdy wrote:
> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa  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  
> >> 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.ja...@gmail.com


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 3:50 PM, Martin Jansa  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  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.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Martin Jansa]

On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote:
> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa  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  wrote:
> >>
> >> On Thu, May 10, 2018 at 3:07 PM, Martin Jansa 
> >> 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
> >> >> >  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: marti

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 3:38 PM, Martin Jansa  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  wrote:
>>
>> On Thu, May 10, 2018 at 3:07 PM, Martin Jansa 
>> 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
>> >> >  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).
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Martin Jansa]

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

On Fri, May 11, 2018 at 12:38 AM Andre McCurdy  wrote:

> On Thu, May 10, 2018 at 3:07 PM, Martin Jansa 
> 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.ja...@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).
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 3:07 PM, Martin Jansa  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  
>> > 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).
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Khem Raj]

On Thu, May 10, 2018 at 3:07 PM, Martin Jansa  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  
>> > 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.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Martin Jansa]

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  
> > 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.ja...@gmail.com


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Martin Jansa]

On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote:
> On Thu, May 10, 2018 at 12:11 PM, Martin Jansa  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.ja...@gmail.com


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 12:11 PM, Martin Jansa  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?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Martin Jansa]

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 
> >             ^~~
> > 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 >::Member' {aka 'struct 
rapidjson::GenericMember, 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 >' 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 >::Member' {aka 'struct 
rapidjson::GenericMember, 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 >' 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 >::Member' {aka 'struct 
rapidjson::GenericMember, rapidjs
on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use 
copy-a

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Khem Raj]

Hi Dan,

Thanks for testing

On 5/10/18 7:34 AM, Dan McGregor wrote:

On 4 May 2018 at 18:26, Khem Raj  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-c...@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Khem Raj]

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 
            ^~~
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 > 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-c...@lists.openembedded.org

http://lists.openembedded.org

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Dan McGregor]

On 4 May 2018 at 18:26, Khem Raj  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-c...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[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
 }
 ^
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 
   ^~~
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  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-c...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto