[RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

Hi All

I have put together upgrade to gcc 4.9.2 as well as glibc 2.21 (
upcoming ) on  a contrib branch ( top 2 patches) its has not got much
testing besides x86 qemu thus far.

http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-glibc-upgrade

I would like to request some help in testing these out in your
respective environments and please report any issues you see so we can
start sorting them out at earlier and making its way into OE-Core.

Thanks for your help

-Khem

Re: [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]

Hi Khem,

On 2 February 2015 at 10:02, Khem Raj <raj.khem@gmail.com> wrote:

> I have put together upgrade to gcc 4.9.2 as well as glibc 2.21 (
> upcoming ) on  a contrib branch ( top 2 patches) its has not got much
> testing besides x86 qemu thus far.
>

I'm seeing these failures when cherry-picking the top two commits to
current poky/master.

gcc-cross-initial:

| /data/poky-master/tmp/work-shared/gcc-4.9.2-r0/gcc-4.9.2/gcc/dwarf2cfi.c:
In function 'void expand_builtin_init_dwarf_reg_sizes(tree)':
|
/data/poky-master/tmp/work-shared/gcc-4.9.2-r0/gcc-4.9.2/gcc/dwarf2cfi.c:334:27:
error: 'struct gcc_target' has no member named 'dwarf_frame_reg_mode'

cross-localdef-native:

| In file included from glibc/locale/programs/locarchive.c:696:0:
| glibc/locale/programs/../../intl/l10nflist.c: In function
'_nl_normalize_codeset':
| glibc/locale/programs/../../intl/l10nflist.c:306:12: error: missing
binary operator before token "("
| glibc/locale/programs/../../intl/l10nflist.c:313:9: error:
'_nl_C_locobj_ptr' undeclared (first use in this function)
| glibc/locale/programs/../../intl/l10nflist.c:313:9: note: each undeclared
identifier is reported only once for each function it appears in

Ross

[-- Attachment #2: Type: text/html, Size: 2229 bytes --]

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Burton, Ross]

Hi Khem,

On 2 February 2015 at 10:02, Khem Raj <raj.khem@gmail.com> wrote:

> I have put together upgrade to gcc 4.9.2 as well as glibc 2.21 (
> upcoming ) on  a contrib branch ( top 2 patches) its has not got much
> testing besides x86 qemu thus far.
>

I'm seeing these failures when cherry-picking the top two commits to
current poky/master.

gcc-cross-initial:

| /data/poky-master/tmp/work-shared/gcc-4.9.2-r0/gcc-4.9.2/gcc/dwarf2cfi.c:
In function 'void expand_builtin_init_dwarf_reg_sizes(tree)':
|
/data/poky-master/tmp/work-shared/gcc-4.9.2-r0/gcc-4.9.2/gcc/dwarf2cfi.c:334:27:
error: 'struct gcc_target' has no member named 'dwarf_frame_reg_mode'

cross-localdef-native:

| In file included from glibc/locale/programs/locarchive.c:696:0:
| glibc/locale/programs/../../intl/l10nflist.c: In function
'_nl_normalize_codeset':
| glibc/locale/programs/../../intl/l10nflist.c:306:12: error: missing
binary operator before token "("
| glibc/locale/programs/../../intl/l10nflist.c:313:9: error:
'_nl_C_locobj_ptr' undeclared (first use in this function)
| glibc/locale/programs/../../intl/l10nflist.c:313:9: note: each undeclared
identifier is reported only once for each function it appears in

Ross

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]

Hi Khem,

On 2 February 2015 at 10:02, Khem Raj <raj.khem@gmail.com> wrote:

> I have put together upgrade to gcc 4.9.2 as well as glibc 2.21 (
> upcoming ) on  a contrib branch ( top 2 patches) its has not got much
> testing besides x86 qemu thus far.
>

I'm seeing these failures when cherry-picking the top two commits to
current poky/master.

gcc-cross-initial:

| /data/poky-master/tmp/work-shared/gcc-4.9.2-r0/gcc-4.9.2/gcc/dwarf2cfi.c:
In function 'void expand_builtin_init_dwarf_reg_sizes(tree)':
|
/data/poky-master/tmp/work-shared/gcc-4.9.2-r0/gcc-4.9.2/gcc/dwarf2cfi.c:334:27:
error: 'struct gcc_target' has no member named 'dwarf_frame_reg_mode'

cross-localdef-native:

| In file included from glibc/locale/programs/locarchive.c:696:0:
| glibc/locale/programs/../../intl/l10nflist.c: In function
'_nl_normalize_codeset':
| glibc/locale/programs/../../intl/l10nflist.c:306:12: error: missing
binary operator before token "("
| glibc/locale/programs/../../intl/l10nflist.c:313:9: error:
'_nl_C_locobj_ptr' undeclared (first use in this function)
| glibc/locale/programs/../../intl/l10nflist.c:313:9: note: each undeclared
identifier is reported only once for each function it appears in

Ross

[-- Attachment #2: Type: text/html, Size: 2229 bytes --]

Re: [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

Hi Ross

Please repull. I did not push from right machine first time. Now it
should be good.
Thanks for quick turnaround

Thanks
-Khem

On Mon, Feb 2, 2015 at 2:40 AM, Burton, Ross <ross.burton@intel.com> wrote:
> Hi Khem,
>
> On 2 February 2015 at 10:02, Khem Raj <raj.khem@gmail.com> wrote:
>>
>> I have put together upgrade to gcc 4.9.2 as well as glibc 2.21 (
>> upcoming ) on  a contrib branch ( top 2 patches) its has not got much
>> testing besides x86 qemu thus far.
>
>
> I'm seeing these failures when cherry-picking the top two commits to current
> poky/master.
>
> gcc-cross-initial:
>
> | /data/poky-master/tmp/work-shared/gcc-4.9.2-r0/gcc-4.9.2/gcc/dwarf2cfi.c:
> In function 'void expand_builtin_init_dwarf_reg_sizes(tree)':
> |
> /data/poky-master/tmp/work-shared/gcc-4.9.2-r0/gcc-4.9.2/gcc/dwarf2cfi.c:334:27:
> error: 'struct gcc_target' has no member named 'dwarf_frame_reg_mode'
>
> cross-localdef-native:
>
> | In file included from glibc/locale/programs/locarchive.c:696:0:
> | glibc/locale/programs/../../intl/l10nflist.c: In function
> '_nl_normalize_codeset':
> | glibc/locale/programs/../../intl/l10nflist.c:306:12: error: missing binary
> operator before token "("
> | glibc/locale/programs/../../intl/l10nflist.c:313:9: error:
> '_nl_C_locobj_ptr' undeclared (first use in this function)
> | glibc/locale/programs/../../intl/l10nflist.c:313:9: note: each undeclared
> identifier is reported only once for each function it appears in
>
> Ross

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

Hi Ross

Please repull. I did not push from right machine first time. Now it
should be good.
Thanks for quick turnaround

Thanks
-Khem

On Mon, Feb 2, 2015 at 2:40 AM, Burton, Ross <ross.burton@intel.com> wrote:
> Hi Khem,
>
> On 2 February 2015 at 10:02, Khem Raj <raj.khem@gmail.com> wrote:
>>
>> I have put together upgrade to gcc 4.9.2 as well as glibc 2.21 (
>> upcoming ) on  a contrib branch ( top 2 patches) its has not got much
>> testing besides x86 qemu thus far.
>
>
> I'm seeing these failures when cherry-picking the top two commits to current
> poky/master.
>
> gcc-cross-initial:
>
> | /data/poky-master/tmp/work-shared/gcc-4.9.2-r0/gcc-4.9.2/gcc/dwarf2cfi.c:
> In function 'void expand_builtin_init_dwarf_reg_sizes(tree)':
> |
> /data/poky-master/tmp/work-shared/gcc-4.9.2-r0/gcc-4.9.2/gcc/dwarf2cfi.c:334:27:
> error: 'struct gcc_target' has no member named 'dwarf_frame_reg_mode'
>
> cross-localdef-native:
>
> | In file included from glibc/locale/programs/locarchive.c:696:0:
> | glibc/locale/programs/../../intl/l10nflist.c: In function
> '_nl_normalize_codeset':
> | glibc/locale/programs/../../intl/l10nflist.c:306:12: error: missing binary
> operator before token "("
> | glibc/locale/programs/../../intl/l10nflist.c:313:9: error:
> '_nl_C_locobj_ptr' undeclared (first use in this function)
> | glibc/locale/programs/../../intl/l10nflist.c:313:9: note: each undeclared
> identifier is reported only once for each function it appears in
>
> Ross

Re: [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

On Mon, Feb 2, 2015 at 2:40 AM, Burton, Ross <ross.burton@intel.com> wrote:
> cross-localdef-native:
>
> | In file included from glibc/locale/programs/locarchive.c:696:0:
> | glibc/locale/programs/../../intl/l10nflist.c: In function
> '_nl_normalize_codeset':
> | glibc/locale/programs/../../intl/l10nflist.c:306:12: error: missing binary
> operator before token "("
> | glibc/locale/programs/../../intl/l10nflist.c:313:9: error:
> '_nl_C_locobj_ptr' undeclared (first use in this function)
> | glibc/locale/programs/../../intl/l10nflist.c:313:9: note: each undeclared
> identifier is reported only once for each function it appears in


gcc would work with latest tree but I did not run into this error. So
wait a while until I get to it.

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

On Mon, Feb 2, 2015 at 2:40 AM, Burton, Ross <ross.burton@intel.com> wrote:
> cross-localdef-native:
>
> | In file included from glibc/locale/programs/locarchive.c:696:0:
> | glibc/locale/programs/../../intl/l10nflist.c: In function
> '_nl_normalize_codeset':
> | glibc/locale/programs/../../intl/l10nflist.c:306:12: error: missing binary
> operator before token "("
> | glibc/locale/programs/../../intl/l10nflist.c:313:9: error:
> '_nl_C_locobj_ptr' undeclared (first use in this function)
> | glibc/locale/programs/../../intl/l10nflist.c:313:9: note: each undeclared
> identifier is reported only once for each function it appears in


gcc would work with latest tree but I did not run into this error. So
wait a while until I get to it.

Re: [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 4953 bytes --]

On 2 February 2015 at 10:54, Khem Raj <raj.khem@gmail.com> wrote:

> On Mon, Feb 2, 2015 at 2:40 AM, Burton, Ross <ross.burton@intel.com>
> wrote:
> > cross-localdef-native:
> >
> > | In file included from glibc/locale/programs/locarchive.c:696:0:
> > | glibc/locale/programs/../../intl/l10nflist.c: In function
> > '_nl_normalize_codeset':
> > | glibc/locale/programs/../../intl/l10nflist.c:306:12: error: missing
> binary
> > operator before token "("
> > | glibc/locale/programs/../../intl/l10nflist.c:313:9: error:
> > '_nl_C_locobj_ptr' undeclared (first use in this function)
> > | glibc/locale/programs/../../intl/l10nflist.c:313:9: note: each
> undeclared
> > identifier is reported only once for each function it appears in
>
>
> gcc would work with latest tree but I did not run into this error. So
> wait a while until I get to it.


I can confirm that the current branch builds gcc (and everything else in a
minimal image) apart from cross-localdef-native, with a long set of errors
for me now:

| In file included from glibc/locale/programs/locarchive.c:696:0:
| glibc/locale/programs/../../intl/l10nflist.c: In function
'_nl_normalize_codeset':
| glibc/locale/programs/../../intl/l10nflist.c:306:12: error: missing
binary operator before token "("
| glibc/locale/programs/../../intl/l10nflist.c:313:9: error:
'_nl_C_locobj_ptr' undeclared (first use in this function)
| glibc/locale/programs/../../intl/l10nflist.c:313:9: note: each undeclared
identifier is reported only once for each function it appears in
| glibc/locale/programs/locarchive.c: In function 'add_locales_to_archive':
| glibc/locale/programs/locarchive.c:1517:7: warning: passing argument 1 of
'__xpg_basename' discards 'const' qualifier from pointer target type
[enabled by default]
| In file included from
/data/poky-master/tmp/work/x86_64-linux/cross-localedef-native/2.21-r0/git/localedef/include/string.h:4:0,
|                  from glibc/locale/programs/locarchive.c:34:
| /usr/include/libgen.h:35:14: note: expected 'char *' but argument is of
type 'const char *'
| glibc/locale/programs/ld-ctype.c: In function 'set_class_defaults':
| glibc/locale/programs/ld-ctype.c:3012:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:3012:7: note: use option -std=c99 or
-std=gnu99 to compile your code
| glibc/locale/programs/ld-ctype.c:3016:19: error: redefinition of 'cnt'
| glibc/locale/programs/ld-ctype.c:3012:19: note: previous definition of
'cnt' was here
| glibc/locale/programs/ld-ctype.c:3016:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:3034:5: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:3038:17: error: redefinition of 'cnt'
| glibc/locale/programs/ld-ctype.c:3034:17: note: previous definition of
'cnt' was here
| glibc/locale/programs/ld-ctype.c:3038:5: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:3250:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:3254:19: error: redefinition of 'cnt'
| glibc/locale/programs/ld-ctype.c:3250:19: note: previous definition of
'cnt' was here
| glibc/locale/programs/ld-ctype.c:3254:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:3272:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:3276:19: error: redefinition of 'cnt'
| glibc/locale/programs/ld-ctype.c:3272:19: note: previous definition of
'cnt' was here
| glibc/locale/programs/ld-ctype.c:3276:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:3383:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:3389:19: error: redefinition of 'cnt'
| glibc/locale/programs/ld-ctype.c:3383:19: note: previous definition of
'cnt' was here
| glibc/locale/programs/ld-ctype.c:3389:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:3401:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c: In function 'allocate_arrays':
| glibc/locale/programs/ld-ctype.c:3887:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:4039:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:4062:19: error: redefinition of 'cnt'
| glibc/locale/programs/ld-ctype.c:4039:19: note: previous definition of
'cnt' was here
| glibc/locale/programs/ld-ctype.c:4062:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| make: *** [locarchive.o] Error 1

Ross

[-- Attachment #2: Type: text/html, Size: 7026 bytes --]

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Burton, Ross]

On 2 February 2015 at 10:54, Khem Raj <raj.khem@gmail.com> wrote:

> On Mon, Feb 2, 2015 at 2:40 AM, Burton, Ross <ross.burton@intel.com>
> wrote:
> > cross-localdef-native:
> >
> > | In file included from glibc/locale/programs/locarchive.c:696:0:
> > | glibc/locale/programs/../../intl/l10nflist.c: In function
> > '_nl_normalize_codeset':
> > | glibc/locale/programs/../../intl/l10nflist.c:306:12: error: missing
> binary
> > operator before token "("
> > | glibc/locale/programs/../../intl/l10nflist.c:313:9: error:
> > '_nl_C_locobj_ptr' undeclared (first use in this function)
> > | glibc/locale/programs/../../intl/l10nflist.c:313:9: note: each
> undeclared
> > identifier is reported only once for each function it appears in
>
>
> gcc would work with latest tree but I did not run into this error. So
> wait a while until I get to it.


I can confirm that the current branch builds gcc (and everything else in a
minimal image) apart from cross-localdef-native, with a long set of errors
for me now:

| In file included from glibc/locale/programs/locarchive.c:696:0:
| glibc/locale/programs/../../intl/l10nflist.c: In function
'_nl_normalize_codeset':
| glibc/locale/programs/../../intl/l10nflist.c:306:12: error: missing
binary operator before token "("
| glibc/locale/programs/../../intl/l10nflist.c:313:9: error:
'_nl_C_locobj_ptr' undeclared (first use in this function)
| glibc/locale/programs/../../intl/l10nflist.c:313:9: note: each undeclared
identifier is reported only once for each function it appears in
| glibc/locale/programs/locarchive.c: In function 'add_locales_to_archive':
| glibc/locale/programs/locarchive.c:1517:7: warning: passing argument 1 of
'__xpg_basename' discards 'const' qualifier from pointer target type
[enabled by default]
| In file included from
/data/poky-master/tmp/work/x86_64-linux/cross-localedef-native/2.21-r0/git/localedef/include/string.h:4:0,
|                  from glibc/locale/programs/locarchive.c:34:
| /usr/include/libgen.h:35:14: note: expected 'char *' but argument is of
type 'const char *'
| glibc/locale/programs/ld-ctype.c: In function 'set_class_defaults':
| glibc/locale/programs/ld-ctype.c:3012:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:3012:7: note: use option -std=c99 or
-std=gnu99 to compile your code
| glibc/locale/programs/ld-ctype.c:3016:19: error: redefinition of 'cnt'
| glibc/locale/programs/ld-ctype.c:3012:19: note: previous definition of
'cnt' was here
| glibc/locale/programs/ld-ctype.c:3016:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:3034:5: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:3038:17: error: redefinition of 'cnt'
| glibc/locale/programs/ld-ctype.c:3034:17: note: previous definition of
'cnt' was here
| glibc/locale/programs/ld-ctype.c:3038:5: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:3250:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:3254:19: error: redefinition of 'cnt'
| glibc/locale/programs/ld-ctype.c:3250:19: note: previous definition of
'cnt' was here
| glibc/locale/programs/ld-ctype.c:3254:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:3272:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:3276:19: error: redefinition of 'cnt'
| glibc/locale/programs/ld-ctype.c:3272:19: note: previous definition of
'cnt' was here
| glibc/locale/programs/ld-ctype.c:3276:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:3383:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:3389:19: error: redefinition of 'cnt'
| glibc/locale/programs/ld-ctype.c:3383:19: note: previous definition of
'cnt' was here
| glibc/locale/programs/ld-ctype.c:3389:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:3401:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c: In function 'allocate_arrays':
| glibc/locale/programs/ld-ctype.c:3887:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:4039:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:4062:19: error: redefinition of 'cnt'
| glibc/locale/programs/ld-ctype.c:4039:19: note: previous definition of
'cnt' was here
| glibc/locale/programs/ld-ctype.c:4062:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| make: *** [locarchive.o] Error 1

Ross

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 4953 bytes --]

On 2 February 2015 at 10:54, Khem Raj <raj.khem@gmail.com> wrote:

> On Mon, Feb 2, 2015 at 2:40 AM, Burton, Ross <ross.burton@intel.com>
> wrote:
> > cross-localdef-native:
> >
> > | In file included from glibc/locale/programs/locarchive.c:696:0:
> > | glibc/locale/programs/../../intl/l10nflist.c: In function
> > '_nl_normalize_codeset':
> > | glibc/locale/programs/../../intl/l10nflist.c:306:12: error: missing
> binary
> > operator before token "("
> > | glibc/locale/programs/../../intl/l10nflist.c:313:9: error:
> > '_nl_C_locobj_ptr' undeclared (first use in this function)
> > | glibc/locale/programs/../../intl/l10nflist.c:313:9: note: each
> undeclared
> > identifier is reported only once for each function it appears in
>
>
> gcc would work with latest tree but I did not run into this error. So
> wait a while until I get to it.


I can confirm that the current branch builds gcc (and everything else in a
minimal image) apart from cross-localdef-native, with a long set of errors
for me now:

| In file included from glibc/locale/programs/locarchive.c:696:0:
| glibc/locale/programs/../../intl/l10nflist.c: In function
'_nl_normalize_codeset':
| glibc/locale/programs/../../intl/l10nflist.c:306:12: error: missing
binary operator before token "("
| glibc/locale/programs/../../intl/l10nflist.c:313:9: error:
'_nl_C_locobj_ptr' undeclared (first use in this function)
| glibc/locale/programs/../../intl/l10nflist.c:313:9: note: each undeclared
identifier is reported only once for each function it appears in
| glibc/locale/programs/locarchive.c: In function 'add_locales_to_archive':
| glibc/locale/programs/locarchive.c:1517:7: warning: passing argument 1 of
'__xpg_basename' discards 'const' qualifier from pointer target type
[enabled by default]
| In file included from
/data/poky-master/tmp/work/x86_64-linux/cross-localedef-native/2.21-r0/git/localedef/include/string.h:4:0,
|                  from glibc/locale/programs/locarchive.c:34:
| /usr/include/libgen.h:35:14: note: expected 'char *' but argument is of
type 'const char *'
| glibc/locale/programs/ld-ctype.c: In function 'set_class_defaults':
| glibc/locale/programs/ld-ctype.c:3012:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:3012:7: note: use option -std=c99 or
-std=gnu99 to compile your code
| glibc/locale/programs/ld-ctype.c:3016:19: error: redefinition of 'cnt'
| glibc/locale/programs/ld-ctype.c:3012:19: note: previous definition of
'cnt' was here
| glibc/locale/programs/ld-ctype.c:3016:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:3034:5: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:3038:17: error: redefinition of 'cnt'
| glibc/locale/programs/ld-ctype.c:3034:17: note: previous definition of
'cnt' was here
| glibc/locale/programs/ld-ctype.c:3038:5: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:3250:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:3254:19: error: redefinition of 'cnt'
| glibc/locale/programs/ld-ctype.c:3250:19: note: previous definition of
'cnt' was here
| glibc/locale/programs/ld-ctype.c:3254:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:3272:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:3276:19: error: redefinition of 'cnt'
| glibc/locale/programs/ld-ctype.c:3272:19: note: previous definition of
'cnt' was here
| glibc/locale/programs/ld-ctype.c:3276:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:3383:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:3389:19: error: redefinition of 'cnt'
| glibc/locale/programs/ld-ctype.c:3383:19: note: previous definition of
'cnt' was here
| glibc/locale/programs/ld-ctype.c:3389:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:3401:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c: In function 'allocate_arrays':
| glibc/locale/programs/ld-ctype.c:3887:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:4039:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| glibc/locale/programs/ld-ctype.c:4062:19: error: redefinition of 'cnt'
| glibc/locale/programs/ld-ctype.c:4039:19: note: previous definition of
'cnt' was here
| glibc/locale/programs/ld-ctype.c:4062:7: error: 'for' loop initial
declarations are only allowed in C99 mode
| make: *** [locarchive.o] Error 1

Ross

[-- Attachment #2: Type: text/html, Size: 7026 bytes --]

Re: [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1609 bytes --]


> On Feb 2, 2015, at 9:25 AM, Burton, Ross <ross.burton@intel.com> wrote:
> 
> 
> On 2 February 2015 at 10:54, Khem Raj <raj.khem@gmail.com <mailto:raj.khem@gmail.com>> wrote:
> On Mon, Feb 2, 2015 at 2:40 AM, Burton, Ross <ross.burton@intel.com <mailto:ross.burton@intel.com>> wrote:
> > cross-localdef-native:
> >
> > | In file included from glibc/locale/programs/locarchive.c:696:0:
> > | glibc/locale/programs/../../intl/l10nflist.c: In function
> > '_nl_normalize_codeset':
> > | glibc/locale/programs/../../intl/l10nflist.c:306:12: error: missing binary
> > operator before token "("
> > | glibc/locale/programs/../../intl/l10nflist.c:313:9: error:
> > '_nl_C_locobj_ptr' undeclared (first use in this function)
> > | glibc/locale/programs/../../intl/l10nflist.c:313:9: note: each undeclared
> > identifier is reported only once for each function it appears in
> 
> 
> gcc would work with latest tree but I did not run into this error. So
> wait a while until I get to it.
> 
> I can confirm that the current branch builds gcc (and everything else in a minimal image) apart from cross-localdef-native, with a long set of errors for me now:
> 

Thanks guys.
Yeah, you must be using a weirdly compiled gcc on your host which is defaulting to -std  < c99 and hence the problem. I have fix for that issue already locally.
I could reproduce it once I passed -std=c89 in CFLAGS. but there is another issue where a new macro IS_IN(lib) is added in glibc 2.21 and is giving me a bit of heartache
I will update the branch soon when I have fix for it and then send a notification.


[-- Attachment #2: Type: text/html, Size: 2766 bytes --]

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

> On Feb 2, 2015, at 9:25 AM, Burton, Ross <ross.burton@intel.com> wrote:
> 
> 
> On 2 February 2015 at 10:54, Khem Raj <raj.khem@gmail.com <mailto:raj.khem@gmail.com>> wrote:
> On Mon, Feb 2, 2015 at 2:40 AM, Burton, Ross <ross.burton@intel.com <mailto:ross.burton@intel.com>> wrote:
> > cross-localdef-native:
> >
> > | In file included from glibc/locale/programs/locarchive.c:696:0:
> > | glibc/locale/programs/../../intl/l10nflist.c: In function
> > '_nl_normalize_codeset':
> > | glibc/locale/programs/../../intl/l10nflist.c:306:12: error: missing binary
> > operator before token "("
> > | glibc/locale/programs/../../intl/l10nflist.c:313:9: error:
> > '_nl_C_locobj_ptr' undeclared (first use in this function)
> > | glibc/locale/programs/../../intl/l10nflist.c:313:9: note: each undeclared
> > identifier is reported only once for each function it appears in
> 
> 
> gcc would work with latest tree but I did not run into this error. So
> wait a while until I get to it.
> 
> I can confirm that the current branch builds gcc (and everything else in a minimal image) apart from cross-localdef-native, with a long set of errors for me now:
> 

Thanks guys.
Yeah, you must be using a weirdly compiled gcc on your host which is defaulting to -std  < c99 and hence the problem. I have fix for that issue already locally.
I could reproduce it once I passed -std=c89 in CFLAGS. but there is another issue where a new macro IS_IN(lib) is added in glibc 2.21 and is giving me a bit of heartache
I will update the branch soon when I have fix for it and then send a notification.

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1609 bytes --]


> On Feb 2, 2015, at 9:25 AM, Burton, Ross <ross.burton@intel.com> wrote:
> 
> 
> On 2 February 2015 at 10:54, Khem Raj <raj.khem@gmail.com <mailto:raj.khem@gmail.com>> wrote:
> On Mon, Feb 2, 2015 at 2:40 AM, Burton, Ross <ross.burton@intel.com <mailto:ross.burton@intel.com>> wrote:
> > cross-localdef-native:
> >
> > | In file included from glibc/locale/programs/locarchive.c:696:0:
> > | glibc/locale/programs/../../intl/l10nflist.c: In function
> > '_nl_normalize_codeset':
> > | glibc/locale/programs/../../intl/l10nflist.c:306:12: error: missing binary
> > operator before token "("
> > | glibc/locale/programs/../../intl/l10nflist.c:313:9: error:
> > '_nl_C_locobj_ptr' undeclared (first use in this function)
> > | glibc/locale/programs/../../intl/l10nflist.c:313:9: note: each undeclared
> > identifier is reported only once for each function it appears in
> 
> 
> gcc would work with latest tree but I did not run into this error. So
> wait a while until I get to it.
> 
> I can confirm that the current branch builds gcc (and everything else in a minimal image) apart from cross-localdef-native, with a long set of errors for me now:
> 

Thanks guys.
Yeah, you must be using a weirdly compiled gcc on your host which is defaulting to -std  < c99 and hence the problem. I have fix for that issue already locally.
I could reproduce it once I passed -std=c89 in CFLAGS. but there is another issue where a new macro IS_IN(lib) is added in glibc 2.21 and is giving me a bit of heartache
I will update the branch soon when I have fix for it and then send a notification.


[-- Attachment #2: Type: text/html, Size: 2766 bytes --]

Re: [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 349 bytes --]

On 2 February 2015 at 17:40, Khem Raj <raj.khem@gmail.com> wrote:

> Yeah, you must be using a weirdly compiled gcc on your host which is
> defaulting to -std  < c99 and hence the problem. I have fix for that issue
> already locally.


$ gcc --version
gcc (Debian 4.7.2-5) 4.7.2

This is the default gcc in current Debian stable.

Ross

[-- Attachment #2: Type: text/html, Size: 875 bytes --]

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Burton, Ross]

On 2 February 2015 at 17:40, Khem Raj <raj.khem@gmail.com> wrote:

> Yeah, you must be using a weirdly compiled gcc on your host which is
> defaulting to -std  < c99 and hence the problem. I have fix for that issue
> already locally.


$ gcc --version
gcc (Debian 4.7.2-5) 4.7.2

This is the default gcc in current Debian stable.

Ross

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 349 bytes --]

On 2 February 2015 at 17:40, Khem Raj <raj.khem@gmail.com> wrote:

> Yeah, you must be using a weirdly compiled gcc on your host which is
> defaulting to -std  < c99 and hence the problem. I have fix for that issue
> already locally.


$ gcc --version
gcc (Debian 4.7.2-5) 4.7.2

This is the default gcc in current Debian stable.

Ross

[-- Attachment #2: Type: text/html, Size: 875 bytes --]

Re: [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 663 bytes --]


> On Feb 2, 2015, at 9:50 AM, Burton, Ross <ross.burton@intel.com> wrote:
> 
> 
> On 2 February 2015 at 17:40, Khem Raj <raj.khem@gmail.com <mailto:raj.khem@gmail.com>> wrote:
> Yeah, you must be using a weirdly compiled gcc on your host which is defaulting to -std  < c99 and hence the problem. I have fix for that issue already locally.
> 
> $ gcc --version
> gcc (Debian 4.7.2-5) 4.7.2
> 
> This is the default gcc in current Debian stable.

Yeah, I am on archlinux (the other end of spectrum). Nevertheless, I have updated the contrib tree which fixes cross-localedef-native compile time issue. So you should be good
to go now.

> 
> Ross


[-- Attachment #2: Type: text/html, Size: 1825 bytes --]

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

> On Feb 2, 2015, at 9:50 AM, Burton, Ross <ross.burton@intel.com> wrote:
> 
> 
> On 2 February 2015 at 17:40, Khem Raj <raj.khem@gmail.com <mailto:raj.khem@gmail.com>> wrote:
> Yeah, you must be using a weirdly compiled gcc on your host which is defaulting to -std  < c99 and hence the problem. I have fix for that issue already locally.
> 
> $ gcc --version
> gcc (Debian 4.7.2-5) 4.7.2
> 
> This is the default gcc in current Debian stable.

Yeah, I am on archlinux (the other end of spectrum). Nevertheless, I have updated the contrib tree which fixes cross-localedef-native compile time issue. So you should be good
to go now.

> 
> Ross

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 663 bytes --]


> On Feb 2, 2015, at 9:50 AM, Burton, Ross <ross.burton@intel.com> wrote:
> 
> 
> On 2 February 2015 at 17:40, Khem Raj <raj.khem@gmail.com <mailto:raj.khem@gmail.com>> wrote:
> Yeah, you must be using a weirdly compiled gcc on your host which is defaulting to -std  < c99 and hence the problem. I have fix for that issue already locally.
> 
> $ gcc --version
> gcc (Debian 4.7.2-5) 4.7.2
> 
> This is the default gcc in current Debian stable.

Yeah, I am on archlinux (the other end of spectrum). Nevertheless, I have updated the contrib tree which fixes cross-localedef-native compile time issue. So you should be good
to go now.

> 
> Ross


[-- Attachment #2: Type: text/html, Size: 1825 bytes --]

Re: [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 3080 bytes --]

On 2 February 2015 at 18:33, Khem Raj <raj.khem@gmail.com> wrote:

> Yeah, I am on archlinux (the other end of spectrum). Nevertheless, I have
> updated the contrib tree which fixes cross-localedef-native compile time
> issue. So you should be good
> to go now.
>

Bad news, glibc is now failing:

| x86_64-poky-linux-gcc  -m64 -march=corei7 -mtune=corei7 -mfpmath=sse
-msse4.2
--sysroot=/data/poky-master/tmp/sysroots/intel-corei7-64-tcbootstrap
dl-open.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Werror -Winline
-Wno-error=undef -Wundef -Wwrite-strings -feliminate-unused-debug-types
-fmerge-all-constants -frounding-math -g -pipe -Wstrict-prototypes   -fPIC
 -mno-sse -mno-mmx        -I../include
-I/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf
 -I/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux
 -I../sysdeps/unix/sysv/linux/x86_64/64
 -I../sysdeps/unix/sysv/linux/x86_64  -I../sysdeps/unix/sysv/linux/x86
 -I../sysdeps/unix/sysv/linux/wordsize-64  -I../sysdeps/x86_64/nptl
 -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux
 -I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu
 -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv  -I../sysdeps/unix/x86_64
 -I../sysdeps/unix  -I../sysdeps/posix  -I../sysdeps/x86_64/64
 -I../sysdeps/x86_64/fpu/multiarch  -I../sysdeps/x86_64/fpu
 -I../sysdeps/x86/fpu/include -I../sysdeps/x86/fpu
 -I../sysdeps/x86_64/multiarch  -I../sysdeps/x86_64  -I../sysdeps/x86
 -I../sysdeps/ieee754/ldbl-96  -I../sysdeps/ieee754/dbl-64/wordsize-64
 -I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754/flt-32
 -I../sysdeps/wordsize-64  -I../sysdeps/ieee754  -I../sysdeps/generic  -I..
-I../libio -I. -nostdinc -isystem
/data/poky-master/tmp/sysroots/x86_64-linux/usr/lib/x86_64-poky-linux.gcc-cross-initial-x86_64/gcc/x86_64-poky-linux/4.9.2/include
-isystem
/data/poky-master/tmp/sysroots/x86_64-linux/usr/lib/x86_64-poky-linux.gcc-cross-initial-x86_64/gcc/x86_64-poky-linux/4.9.2/include-fixed
-isystem /data/poky-master/tmp/sysroots/intel-corei7-64/usr/include
 -D_LIBC_REENTRANT -include
/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/libc-modules.h
-DMODULE_NAME=rtld -include ../include/libc-symbols.h  -DPIC -DSHARED
-o
/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os
-MD -MP -MF
/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os.dt
-MT
/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os
| dl-caller.c:1:0: error: SSE instruction set disabled, using 387
arithmetics [-Werror]
|  /* Check whether caller comes from the right place.
|  ^
| dl-open.c:1:0: error: SSE instruction set disabled, using 387 arithmetics
[-Werror]
|  /* Load a shared object at runtime, relocate it, and run its initializer.
|  ^
| cc1: all warnings being treated as errors
| cc1: all warnings being treated as errors

Ross

[-- Attachment #2: Type: text/html, Size: 3835 bytes --]

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Burton, Ross]

On 2 February 2015 at 18:33, Khem Raj <raj.khem@gmail.com> wrote:

> Yeah, I am on archlinux (the other end of spectrum). Nevertheless, I have
> updated the contrib tree which fixes cross-localedef-native compile time
> issue. So you should be good
> to go now.
>

Bad news, glibc is now failing:

| x86_64-poky-linux-gcc  -m64 -march=corei7 -mtune=corei7 -mfpmath=sse
-msse4.2
--sysroot=/data/poky-master/tmp/sysroots/intel-corei7-64-tcbootstrap
dl-open.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Werror -Winline
-Wno-error=undef -Wundef -Wwrite-strings -feliminate-unused-debug-types
-fmerge-all-constants -frounding-math -g -pipe -Wstrict-prototypes   -fPIC
 -mno-sse -mno-mmx        -I../include
-I/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf
 -I/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux
 -I../sysdeps/unix/sysv/linux/x86_64/64
 -I../sysdeps/unix/sysv/linux/x86_64  -I../sysdeps/unix/sysv/linux/x86
 -I../sysdeps/unix/sysv/linux/wordsize-64  -I../sysdeps/x86_64/nptl
 -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux
 -I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu
 -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv  -I../sysdeps/unix/x86_64
 -I../sysdeps/unix  -I../sysdeps/posix  -I../sysdeps/x86_64/64
 -I../sysdeps/x86_64/fpu/multiarch  -I../sysdeps/x86_64/fpu
 -I../sysdeps/x86/fpu/include -I../sysdeps/x86/fpu
 -I../sysdeps/x86_64/multiarch  -I../sysdeps/x86_64  -I../sysdeps/x86
 -I../sysdeps/ieee754/ldbl-96  -I../sysdeps/ieee754/dbl-64/wordsize-64
 -I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754/flt-32
 -I../sysdeps/wordsize-64  -I../sysdeps/ieee754  -I../sysdeps/generic  -I..
-I../libio -I. -nostdinc -isystem
/data/poky-master/tmp/sysroots/x86_64-linux/usr/lib/x86_64-poky-linux.gcc-cross-initial-x86_64/gcc/x86_64-poky-linux/4.9.2/include
-isystem
/data/poky-master/tmp/sysroots/x86_64-linux/usr/lib/x86_64-poky-linux.gcc-cross-initial-x86_64/gcc/x86_64-poky-linux/4.9.2/include-fixed
-isystem /data/poky-master/tmp/sysroots/intel-corei7-64/usr/include
 -D_LIBC_REENTRANT -include
/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/libc-modules.h
-DMODULE_NAME=rtld -include ../include/libc-symbols.h  -DPIC -DSHARED
-o
/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os
-MD -MP -MF
/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os.dt
-MT
/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os
| dl-caller.c:1:0: error: SSE instruction set disabled, using 387
arithmetics [-Werror]
|  /* Check whether caller comes from the right place.
|  ^
| dl-open.c:1:0: error: SSE instruction set disabled, using 387 arithmetics
[-Werror]
|  /* Load a shared object at runtime, relocate it, and run its initializer.
|  ^
| cc1: all warnings being treated as errors
| cc1: all warnings being treated as errors

Ross

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 3080 bytes --]

On 2 February 2015 at 18:33, Khem Raj <raj.khem@gmail.com> wrote:

> Yeah, I am on archlinux (the other end of spectrum). Nevertheless, I have
> updated the contrib tree which fixes cross-localedef-native compile time
> issue. So you should be good
> to go now.
>

Bad news, glibc is now failing:

| x86_64-poky-linux-gcc  -m64 -march=corei7 -mtune=corei7 -mfpmath=sse
-msse4.2
--sysroot=/data/poky-master/tmp/sysroots/intel-corei7-64-tcbootstrap
dl-open.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Werror -Winline
-Wno-error=undef -Wundef -Wwrite-strings -feliminate-unused-debug-types
-fmerge-all-constants -frounding-math -g -pipe -Wstrict-prototypes   -fPIC
 -mno-sse -mno-mmx        -I../include
-I/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf
 -I/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux
 -I../sysdeps/unix/sysv/linux/x86_64/64
 -I../sysdeps/unix/sysv/linux/x86_64  -I../sysdeps/unix/sysv/linux/x86
 -I../sysdeps/unix/sysv/linux/wordsize-64  -I../sysdeps/x86_64/nptl
 -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux
 -I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu
 -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv  -I../sysdeps/unix/x86_64
 -I../sysdeps/unix  -I../sysdeps/posix  -I../sysdeps/x86_64/64
 -I../sysdeps/x86_64/fpu/multiarch  -I../sysdeps/x86_64/fpu
 -I../sysdeps/x86/fpu/include -I../sysdeps/x86/fpu
 -I../sysdeps/x86_64/multiarch  -I../sysdeps/x86_64  -I../sysdeps/x86
 -I../sysdeps/ieee754/ldbl-96  -I../sysdeps/ieee754/dbl-64/wordsize-64
 -I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754/flt-32
 -I../sysdeps/wordsize-64  -I../sysdeps/ieee754  -I../sysdeps/generic  -I..
-I../libio -I. -nostdinc -isystem
/data/poky-master/tmp/sysroots/x86_64-linux/usr/lib/x86_64-poky-linux.gcc-cross-initial-x86_64/gcc/x86_64-poky-linux/4.9.2/include
-isystem
/data/poky-master/tmp/sysroots/x86_64-linux/usr/lib/x86_64-poky-linux.gcc-cross-initial-x86_64/gcc/x86_64-poky-linux/4.9.2/include-fixed
-isystem /data/poky-master/tmp/sysroots/intel-corei7-64/usr/include
 -D_LIBC_REENTRANT -include
/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/libc-modules.h
-DMODULE_NAME=rtld -include ../include/libc-symbols.h  -DPIC -DSHARED
-o
/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os
-MD -MP -MF
/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os.dt
-MT
/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os
| dl-caller.c:1:0: error: SSE instruction set disabled, using 387
arithmetics [-Werror]
|  /* Check whether caller comes from the right place.
|  ^
| dl-open.c:1:0: error: SSE instruction set disabled, using 387 arithmetics
[-Werror]
|  /* Load a shared object at runtime, relocate it, and run its initializer.
|  ^
| cc1: all warnings being treated as errors
| cc1: all warnings being treated as errors

Ross

[-- Attachment #2: Type: text/html, Size: 3835 bytes --]

Re: [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

On Mon, Feb 2, 2015 at 1:45 PM, Burton, Ross <ross.burton@intel.com> wrote:
>
> On 2 February 2015 at 18:33, Khem Raj <raj.khem@gmail.com> wrote:
>>
>> Yeah, I am on archlinux (the other end of spectrum). Nevertheless, I have
>> updated the contrib tree which fixes cross-localedef-native compile time
>> issue. So you should be good
>> to go now.
>
>
> Bad news, glibc is now failing:
>
> | x86_64-poky-linux-gcc  -m64 -march=corei7 -mtune=corei7 -mfpmath=sse
> -msse4.2
> --sysroot=/data/poky-master/tmp/sysroots/intel-corei7-64-tcbootstrap
> dl-open.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Werror -Winline
> -Wno-error=undef -Wundef -Wwrite-strings -feliminate-unused-debug-types
> -fmerge-all-constants -frounding-math -g -pipe -Wstrict-prototypes   -fPIC
> -mno-sse -mno-mmx        -I../include
> -I/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf
> -I/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux
> -I../sysdeps/unix/sysv/linux/x86_64/64  -I../sysdeps/unix/sysv/linux/x86_64
> -I../sysdeps/unix/sysv/linux/x86  -I../sysdeps/unix/sysv/linux/wordsize-64
> -I../sysdeps/x86_64/nptl  -I../sysdeps/unix/sysv/linux/include
> -I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread
> -I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv
> -I../sysdeps/unix/x86_64  -I../sysdeps/unix  -I../sysdeps/posix
> -I../sysdeps/x86_64/64  -I../sysdeps/x86_64/fpu/multiarch
> -I../sysdeps/x86_64/fpu  -I../sysdeps/x86/fpu/include -I../sysdeps/x86/fpu
> -I../sysdeps/x86_64/multiarch  -I../sysdeps/x86_64  -I../sysdeps/x86
> -I../sysdeps/ieee754/ldbl-96  -I../sysdeps/ieee754/dbl-64/wordsize-64
> -I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754/flt-32
> -I../sysdeps/wordsize-64  -I../sysdeps/ieee754  -I../sysdeps/generic  -I..
> -I../libio -I. -nostdinc -isystem
> /data/poky-master/tmp/sysroots/x86_64-linux/usr/lib/x86_64-poky-linux.gcc-cross-initial-x86_64/gcc/x86_64-poky-linux/4.9.2/include
> -isystem
> /data/poky-master/tmp/sysroots/x86_64-linux/usr/lib/x86_64-poky-linux.gcc-cross-initial-x86_64/gcc/x86_64-poky-linux/4.9.2/include-fixed
> -isystem /data/poky-master/tmp/sysroots/intel-corei7-64/usr/include
> -D_LIBC_REENTRANT -include
> /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/libc-modules.h
> -DMODULE_NAME=rtld -include ../include/libc-symbols.h  -DPIC -DSHARED     -o
> /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os
> -MD -MP -MF
> /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os.dt
> -MT
> /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os
> | dl-caller.c:1:0: error: SSE instruction set disabled, using 387
> arithmetics [-Werror]
> |  /* Check whether caller comes from the right place.
> |  ^
> | dl-open.c:1:0: error: SSE instruction set disabled, using 387 arithmetics
> [-Werror]
> |  /* Load a shared object at runtime, relocate it, and run its initializer.
> |  ^
> | cc1: all warnings being treated as errors
> | cc1: all warnings being treated as errors

The real problem is we are injecting -mfpmath=sse -msse4.2 via CCARGS
and for this particular file glibc says  -mno-sse -mno-mmx
so it defaults to x87 80bit arithmetics. May be we should get a bit
milder with optimizations for this case when compiling glibc. Since
glibc has its own notion about floating point.

I think this issue was there even with older version of glibc for i7
but it was flagged as a warning, glibc 2.21 now uses -Werror by
default. Can you confirm that via inspecting 2.20 glibc build logs for
this machine ?

I have pushed another patch to disable sse for replacing fpu. Please
try it out and let me know if it fixed it.

>
> Ross

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

On Mon, Feb 2, 2015 at 1:45 PM, Burton, Ross <ross.burton@intel.com> wrote:
>
> On 2 February 2015 at 18:33, Khem Raj <raj.khem@gmail.com> wrote:
>>
>> Yeah, I am on archlinux (the other end of spectrum). Nevertheless, I have
>> updated the contrib tree which fixes cross-localedef-native compile time
>> issue. So you should be good
>> to go now.
>
>
> Bad news, glibc is now failing:
>
> | x86_64-poky-linux-gcc  -m64 -march=corei7 -mtune=corei7 -mfpmath=sse
> -msse4.2
> --sysroot=/data/poky-master/tmp/sysroots/intel-corei7-64-tcbootstrap
> dl-open.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Werror -Winline
> -Wno-error=undef -Wundef -Wwrite-strings -feliminate-unused-debug-types
> -fmerge-all-constants -frounding-math -g -pipe -Wstrict-prototypes   -fPIC
> -mno-sse -mno-mmx        -I../include
> -I/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf
> -I/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux
> -I../sysdeps/unix/sysv/linux/x86_64/64  -I../sysdeps/unix/sysv/linux/x86_64
> -I../sysdeps/unix/sysv/linux/x86  -I../sysdeps/unix/sysv/linux/wordsize-64
> -I../sysdeps/x86_64/nptl  -I../sysdeps/unix/sysv/linux/include
> -I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread
> -I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv
> -I../sysdeps/unix/x86_64  -I../sysdeps/unix  -I../sysdeps/posix
> -I../sysdeps/x86_64/64  -I../sysdeps/x86_64/fpu/multiarch
> -I../sysdeps/x86_64/fpu  -I../sysdeps/x86/fpu/include -I../sysdeps/x86/fpu
> -I../sysdeps/x86_64/multiarch  -I../sysdeps/x86_64  -I../sysdeps/x86
> -I../sysdeps/ieee754/ldbl-96  -I../sysdeps/ieee754/dbl-64/wordsize-64
> -I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754/flt-32
> -I../sysdeps/wordsize-64  -I../sysdeps/ieee754  -I../sysdeps/generic  -I..
> -I../libio -I. -nostdinc -isystem
> /data/poky-master/tmp/sysroots/x86_64-linux/usr/lib/x86_64-poky-linux.gcc-cross-initial-x86_64/gcc/x86_64-poky-linux/4.9.2/include
> -isystem
> /data/poky-master/tmp/sysroots/x86_64-linux/usr/lib/x86_64-poky-linux.gcc-cross-initial-x86_64/gcc/x86_64-poky-linux/4.9.2/include-fixed
> -isystem /data/poky-master/tmp/sysroots/intel-corei7-64/usr/include
> -D_LIBC_REENTRANT -include
> /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/libc-modules.h
> -DMODULE_NAME=rtld -include ../include/libc-symbols.h  -DPIC -DSHARED     -o
> /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os
> -MD -MP -MF
> /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os.dt
> -MT
> /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os
> | dl-caller.c:1:0: error: SSE instruction set disabled, using 387
> arithmetics [-Werror]
> |  /* Check whether caller comes from the right place.
> |  ^
> | dl-open.c:1:0: error: SSE instruction set disabled, using 387 arithmetics
> [-Werror]
> |  /* Load a shared object at runtime, relocate it, and run its initializer.
> |  ^
> | cc1: all warnings being treated as errors
> | cc1: all warnings being treated as errors

The real problem is we are injecting -mfpmath=sse -msse4.2 via CCARGS
and for this particular file glibc says  -mno-sse -mno-mmx
so it defaults to x87 80bit arithmetics. May be we should get a bit
milder with optimizations for this case when compiling glibc. Since
glibc has its own notion about floating point.

I think this issue was there even with older version of glibc for i7
but it was flagged as a warning, glibc 2.21 now uses -Werror by
default. Can you confirm that via inspecting 2.20 glibc build logs for
this machine ?

I have pushed another patch to disable sse for replacing fpu. Please
try it out and let me know if it fixed it.

>
> Ross

Re: [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 691 bytes --]

On 3 February 2015 at 05:03, Khem Raj <raj.khem@gmail.com> wrote:

> I think this issue was there even with older version of glibc for i7
> but it was flagged as a warning, glibc 2.21 now uses -Werror by
> default. Can you confirm that via inspecting 2.20 glibc build logs for
> this machine ?
>

dl-caller.c:1:0: warning: SSE instruction set disabled, using 387
arithmetics
 /* Check whether caller comes from the right place.
 ^
../sysdeps/unix/sysv/linux/dl-execstack.c:1:0: warning: SSE instruction set
disabled, using 387 arithmetics
 /* Stack executability handling for GNU dynamic linker.  Linux version.
 ^

You're right.  I'll test the new branch shortly.

Ross

[-- Attachment #2: Type: text/html, Size: 1406 bytes --]

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Burton, Ross]

On 3 February 2015 at 05:03, Khem Raj <raj.khem@gmail.com> wrote:

> I think this issue was there even with older version of glibc for i7
> but it was flagged as a warning, glibc 2.21 now uses -Werror by
> default. Can you confirm that via inspecting 2.20 glibc build logs for
> this machine ?
>

dl-caller.c:1:0: warning: SSE instruction set disabled, using 387
arithmetics
 /* Check whether caller comes from the right place.
 ^
../sysdeps/unix/sysv/linux/dl-execstack.c:1:0: warning: SSE instruction set
disabled, using 387 arithmetics
 /* Stack executability handling for GNU dynamic linker.  Linux version.
 ^

You're right.  I'll test the new branch shortly.

Ross

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 691 bytes --]

On 3 February 2015 at 05:03, Khem Raj <raj.khem@gmail.com> wrote:

> I think this issue was there even with older version of glibc for i7
> but it was flagged as a warning, glibc 2.21 now uses -Werror by
> default. Can you confirm that via inspecting 2.20 glibc build logs for
> this machine ?
>

dl-caller.c:1:0: warning: SSE instruction set disabled, using 387
arithmetics
 /* Check whether caller comes from the right place.
 ^
../sysdeps/unix/sysv/linux/dl-execstack.c:1:0: warning: SSE instruction set
disabled, using 387 arithmetics
 /* Stack executability handling for GNU dynamic linker.  Linux version.
 ^

You're right.  I'll test the new branch shortly.

Ross

[-- Attachment #2: Type: text/html, Size: 1406 bytes --]

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Dan McGregor]

On 2 February 2015 at 23:03, Khem Raj <raj.khem@gmail.com> wrote:
> On Mon, Feb 2, 2015 at 1:45 PM, Burton, Ross <ross.burton@intel.com> wrote:
>>
>> On 2 February 2015 at 18:33, Khem Raj <raj.khem@gmail.com> wrote:
>>>
>>> Yeah, I am on archlinux (the other end of spectrum). Nevertheless, I have
>>> updated the contrib tree which fixes cross-localedef-native compile time
>>> issue. So you should be good
>>> to go now.
>>
>>
>> Bad news, glibc is now failing:
>>
>> | x86_64-poky-linux-gcc  -m64 -march=corei7 -mtune=corei7 -mfpmath=sse
>> -msse4.2
>> --sysroot=/data/poky-master/tmp/sysroots/intel-corei7-64-tcbootstrap
>> dl-open.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Werror -Winline
>> -Wno-error=undef -Wundef -Wwrite-strings -feliminate-unused-debug-types
>> -fmerge-all-constants -frounding-math -g -pipe -Wstrict-prototypes   -fPIC
>> -mno-sse -mno-mmx        -I../include
>> -I/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf
>> -I/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux
>> -I../sysdeps/unix/sysv/linux/x86_64/64  -I../sysdeps/unix/sysv/linux/x86_64
>> -I../sysdeps/unix/sysv/linux/x86  -I../sysdeps/unix/sysv/linux/wordsize-64
>> -I../sysdeps/x86_64/nptl  -I../sysdeps/unix/sysv/linux/include
>> -I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread
>> -I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv
>> -I../sysdeps/unix/x86_64  -I../sysdeps/unix  -I../sysdeps/posix
>> -I../sysdeps/x86_64/64  -I../sysdeps/x86_64/fpu/multiarch
>> -I../sysdeps/x86_64/fpu  -I../sysdeps/x86/fpu/include -I../sysdeps/x86/fpu
>> -I../sysdeps/x86_64/multiarch  -I../sysdeps/x86_64  -I../sysdeps/x86
>> -I../sysdeps/ieee754/ldbl-96  -I../sysdeps/ieee754/dbl-64/wordsize-64
>> -I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754/flt-32
>> -I../sysdeps/wordsize-64  -I../sysdeps/ieee754  -I../sysdeps/generic  -I..
>> -I../libio -I. -nostdinc -isystem
>> /data/poky-master/tmp/sysroots/x86_64-linux/usr/lib/x86_64-poky-linux.gcc-cross-initial-x86_64/gcc/x86_64-poky-linux/4.9.2/include
>> -isystem
>> /data/poky-master/tmp/sysroots/x86_64-linux/usr/lib/x86_64-poky-linux.gcc-cross-initial-x86_64/gcc/x86_64-poky-linux/4.9.2/include-fixed
>> -isystem /data/poky-master/tmp/sysroots/intel-corei7-64/usr/include
>> -D_LIBC_REENTRANT -include
>> /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/libc-modules.h
>> -DMODULE_NAME=rtld -include ../include/libc-symbols.h  -DPIC -DSHARED     -o
>> /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os
>> -MD -MP -MF
>> /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os.dt
>> -MT
>> /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os
>> | dl-caller.c:1:0: error: SSE instruction set disabled, using 387
>> arithmetics [-Werror]
>> |  /* Check whether caller comes from the right place.
>> |  ^
>> | dl-open.c:1:0: error: SSE instruction set disabled, using 387 arithmetics
>> [-Werror]
>> |  /* Load a shared object at runtime, relocate it, and run its initializer.
>> |  ^
>> | cc1: all warnings being treated as errors
>> | cc1: all warnings being treated as errors
>
> The real problem is we are injecting -mfpmath=sse -msse4.2 via CCARGS
> and for this particular file glibc says  -mno-sse -mno-mmx
> so it defaults to x87 80bit arithmetics. May be we should get a bit
> milder with optimizations for this case when compiling glibc. Since
> glibc has its own notion about floating point.
>
> I think this issue was there even with older version of glibc for i7
> but it was flagged as a warning, glibc 2.21 now uses -Werror by
> default. Can you confirm that via inspecting 2.20 glibc build logs for
> this machine ?
>
> I have pushed another patch to disable sse for replacing fpu. Please
> try it out and let me know if it fixed it.
>

The new branch is working well for me, for wandboard-quad, beaglebone,
and cubieboard2.

>>
>> Ross
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Dan McGregor]

On 2 February 2015 at 23:03, Khem Raj <raj.khem@gmail.com> wrote:
> On Mon, Feb 2, 2015 at 1:45 PM, Burton, Ross <ross.burton@intel.com> wrote:
>>
>> On 2 February 2015 at 18:33, Khem Raj <raj.khem@gmail.com> wrote:
>>>
>>> Yeah, I am on archlinux (the other end of spectrum). Nevertheless, I have
>>> updated the contrib tree which fixes cross-localedef-native compile time
>>> issue. So you should be good
>>> to go now.
>>
>>
>> Bad news, glibc is now failing:
>>
>> | x86_64-poky-linux-gcc  -m64 -march=corei7 -mtune=corei7 -mfpmath=sse
>> -msse4.2
>> --sysroot=/data/poky-master/tmp/sysroots/intel-corei7-64-tcbootstrap
>> dl-open.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Werror -Winline
>> -Wno-error=undef -Wundef -Wwrite-strings -feliminate-unused-debug-types
>> -fmerge-all-constants -frounding-math -g -pipe -Wstrict-prototypes   -fPIC
>> -mno-sse -mno-mmx        -I../include
>> -I/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf
>> -I/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux
>> -I../sysdeps/unix/sysv/linux/x86_64/64  -I../sysdeps/unix/sysv/linux/x86_64
>> -I../sysdeps/unix/sysv/linux/x86  -I../sysdeps/unix/sysv/linux/wordsize-64
>> -I../sysdeps/x86_64/nptl  -I../sysdeps/unix/sysv/linux/include
>> -I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread
>> -I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv
>> -I../sysdeps/unix/x86_64  -I../sysdeps/unix  -I../sysdeps/posix
>> -I../sysdeps/x86_64/64  -I../sysdeps/x86_64/fpu/multiarch
>> -I../sysdeps/x86_64/fpu  -I../sysdeps/x86/fpu/include -I../sysdeps/x86/fpu
>> -I../sysdeps/x86_64/multiarch  -I../sysdeps/x86_64  -I../sysdeps/x86
>> -I../sysdeps/ieee754/ldbl-96  -I../sysdeps/ieee754/dbl-64/wordsize-64
>> -I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754/flt-32
>> -I../sysdeps/wordsize-64  -I../sysdeps/ieee754  -I../sysdeps/generic  -I..
>> -I../libio -I. -nostdinc -isystem
>> /data/poky-master/tmp/sysroots/x86_64-linux/usr/lib/x86_64-poky-linux.gcc-cross-initial-x86_64/gcc/x86_64-poky-linux/4.9.2/include
>> -isystem
>> /data/poky-master/tmp/sysroots/x86_64-linux/usr/lib/x86_64-poky-linux.gcc-cross-initial-x86_64/gcc/x86_64-poky-linux/4.9.2/include-fixed
>> -isystem /data/poky-master/tmp/sysroots/intel-corei7-64/usr/include
>> -D_LIBC_REENTRANT -include
>> /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/libc-modules.h
>> -DMODULE_NAME=rtld -include ../include/libc-symbols.h  -DPIC -DSHARED     -o
>> /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os
>> -MD -MP -MF
>> /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os.dt
>> -MT
>> /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os
>> | dl-caller.c:1:0: error: SSE instruction set disabled, using 387
>> arithmetics [-Werror]
>> |  /* Check whether caller comes from the right place.
>> |  ^
>> | dl-open.c:1:0: error: SSE instruction set disabled, using 387 arithmetics
>> [-Werror]
>> |  /* Load a shared object at runtime, relocate it, and run its initializer.
>> |  ^
>> | cc1: all warnings being treated as errors
>> | cc1: all warnings being treated as errors
>
> The real problem is we are injecting -mfpmath=sse -msse4.2 via CCARGS
> and for this particular file glibc says  -mno-sse -mno-mmx
> so it defaults to x87 80bit arithmetics. May be we should get a bit
> milder with optimizations for this case when compiling glibc. Since
> glibc has its own notion about floating point.
>
> I think this issue was there even with older version of glibc for i7
> but it was flagged as a warning, glibc 2.21 now uses -Werror by
> default. Can you confirm that via inspecting 2.20 glibc build logs for
> this machine ?
>
> I have pushed another patch to disable sse for replacing fpu. Please
> try it out and let me know if it fixed it.
>

The new branch is working well for me, for wandboard-quad, beaglebone,
and cubieboard2.

>>
>> Ross
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

Hi Richard/All

I have refreshed the branch to include the patch which moves the src
uri to use the newly released glibc 2.21 branch
and please run it via autobuilder ( top 5 commits )

Thanks
-Khem



On Tue, Feb 3, 2015 at 10:43 PM, Dan McGregor <danismostlikely@gmail.com> wrote:
> On 2 February 2015 at 23:03, Khem Raj <raj.khem@gmail.com> wrote:
>> On Mon, Feb 2, 2015 at 1:45 PM, Burton, Ross <ross.burton@intel.com> wrote:
>>>
>>> On 2 February 2015 at 18:33, Khem Raj <raj.khem@gmail.com> wrote:
>>>>
>>>> Yeah, I am on archlinux (the other end of spectrum). Nevertheless, I have
>>>> updated the contrib tree which fixes cross-localedef-native compile time
>>>> issue. So you should be good
>>>> to go now.
>>>
>>>
>>> Bad news, glibc is now failing:
>>>
>>> | x86_64-poky-linux-gcc  -m64 -march=corei7 -mtune=corei7 -mfpmath=sse
>>> -msse4.2
>>> --sysroot=/data/poky-master/tmp/sysroots/intel-corei7-64-tcbootstrap
>>> dl-open.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Werror -Winline
>>> -Wno-error=undef -Wundef -Wwrite-strings -feliminate-unused-debug-types
>>> -fmerge-all-constants -frounding-math -g -pipe -Wstrict-prototypes   -fPIC
>>> -mno-sse -mno-mmx        -I../include
>>> -I/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf
>>> -I/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux
>>> -I../sysdeps/unix/sysv/linux/x86_64/64  -I../sysdeps/unix/sysv/linux/x86_64
>>> -I../sysdeps/unix/sysv/linux/x86  -I../sysdeps/unix/sysv/linux/wordsize-64
>>> -I../sysdeps/x86_64/nptl  -I../sysdeps/unix/sysv/linux/include
>>> -I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread
>>> -I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv
>>> -I../sysdeps/unix/x86_64  -I../sysdeps/unix  -I../sysdeps/posix
>>> -I../sysdeps/x86_64/64  -I../sysdeps/x86_64/fpu/multiarch
>>> -I../sysdeps/x86_64/fpu  -I../sysdeps/x86/fpu/include -I../sysdeps/x86/fpu
>>> -I../sysdeps/x86_64/multiarch  -I../sysdeps/x86_64  -I../sysdeps/x86
>>> -I../sysdeps/ieee754/ldbl-96  -I../sysdeps/ieee754/dbl-64/wordsize-64
>>> -I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754/flt-32
>>> -I../sysdeps/wordsize-64  -I../sysdeps/ieee754  -I../sysdeps/generic  -I..
>>> -I../libio -I. -nostdinc -isystem
>>> /data/poky-master/tmp/sysroots/x86_64-linux/usr/lib/x86_64-poky-linux.gcc-cross-initial-x86_64/gcc/x86_64-poky-linux/4.9.2/include
>>> -isystem
>>> /data/poky-master/tmp/sysroots/x86_64-linux/usr/lib/x86_64-poky-linux.gcc-cross-initial-x86_64/gcc/x86_64-poky-linux/4.9.2/include-fixed
>>> -isystem /data/poky-master/tmp/sysroots/intel-corei7-64/usr/include
>>> -D_LIBC_REENTRANT -include
>>> /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/libc-modules.h
>>> -DMODULE_NAME=rtld -include ../include/libc-symbols.h  -DPIC -DSHARED     -o
>>> /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os
>>> -MD -MP -MF
>>> /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os.dt
>>> -MT
>>> /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os
>>> | dl-caller.c:1:0: error: SSE instruction set disabled, using 387
>>> arithmetics [-Werror]
>>> |  /* Check whether caller comes from the right place.
>>> |  ^
>>> | dl-open.c:1:0: error: SSE instruction set disabled, using 387 arithmetics
>>> [-Werror]
>>> |  /* Load a shared object at runtime, relocate it, and run its initializer.
>>> |  ^
>>> | cc1: all warnings being treated as errors
>>> | cc1: all warnings being treated as errors
>>
>> The real problem is we are injecting -mfpmath=sse -msse4.2 via CCARGS
>> and for this particular file glibc says  -mno-sse -mno-mmx
>> so it defaults to x87 80bit arithmetics. May be we should get a bit
>> milder with optimizations for this case when compiling glibc. Since
>> glibc has its own notion about floating point.
>>
>> I think this issue was there even with older version of glibc for i7
>> but it was flagged as a warning, glibc 2.21 now uses -Werror by
>> default. Can you confirm that via inspecting 2.20 glibc build logs for
>> this machine ?
>>
>> I have pushed another patch to disable sse for replacing fpu. Please
>> try it out and let me know if it fixed it.
>>
>
> The new branch is working well for me, for wandboard-quad, beaglebone,
> and cubieboard2.
>
>>>
>>> Ross
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

Hi Richard/All

I have refreshed the branch to include the patch which moves the src
uri to use the newly released glibc 2.21 branch
and please run it via autobuilder ( top 5 commits )

Thanks
-Khem



On Tue, Feb 3, 2015 at 10:43 PM, Dan McGregor <danismostlikely@gmail.com> wrote:
> On 2 February 2015 at 23:03, Khem Raj <raj.khem@gmail.com> wrote:
>> On Mon, Feb 2, 2015 at 1:45 PM, Burton, Ross <ross.burton@intel.com> wrote:
>>>
>>> On 2 February 2015 at 18:33, Khem Raj <raj.khem@gmail.com> wrote:
>>>>
>>>> Yeah, I am on archlinux (the other end of spectrum). Nevertheless, I have
>>>> updated the contrib tree which fixes cross-localedef-native compile time
>>>> issue. So you should be good
>>>> to go now.
>>>
>>>
>>> Bad news, glibc is now failing:
>>>
>>> | x86_64-poky-linux-gcc  -m64 -march=corei7 -mtune=corei7 -mfpmath=sse
>>> -msse4.2
>>> --sysroot=/data/poky-master/tmp/sysroots/intel-corei7-64-tcbootstrap
>>> dl-open.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Werror -Winline
>>> -Wno-error=undef -Wundef -Wwrite-strings -feliminate-unused-debug-types
>>> -fmerge-all-constants -frounding-math -g -pipe -Wstrict-prototypes   -fPIC
>>> -mno-sse -mno-mmx        -I../include
>>> -I/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf
>>> -I/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux
>>> -I../sysdeps/unix/sysv/linux/x86_64/64  -I../sysdeps/unix/sysv/linux/x86_64
>>> -I../sysdeps/unix/sysv/linux/x86  -I../sysdeps/unix/sysv/linux/wordsize-64
>>> -I../sysdeps/x86_64/nptl  -I../sysdeps/unix/sysv/linux/include
>>> -I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread
>>> -I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv
>>> -I../sysdeps/unix/x86_64  -I../sysdeps/unix  -I../sysdeps/posix
>>> -I../sysdeps/x86_64/64  -I../sysdeps/x86_64/fpu/multiarch
>>> -I../sysdeps/x86_64/fpu  -I../sysdeps/x86/fpu/include -I../sysdeps/x86/fpu
>>> -I../sysdeps/x86_64/multiarch  -I../sysdeps/x86_64  -I../sysdeps/x86
>>> -I../sysdeps/ieee754/ldbl-96  -I../sysdeps/ieee754/dbl-64/wordsize-64
>>> -I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754/flt-32
>>> -I../sysdeps/wordsize-64  -I../sysdeps/ieee754  -I../sysdeps/generic  -I..
>>> -I../libio -I. -nostdinc -isystem
>>> /data/poky-master/tmp/sysroots/x86_64-linux/usr/lib/x86_64-poky-linux.gcc-cross-initial-x86_64/gcc/x86_64-poky-linux/4.9.2/include
>>> -isystem
>>> /data/poky-master/tmp/sysroots/x86_64-linux/usr/lib/x86_64-poky-linux.gcc-cross-initial-x86_64/gcc/x86_64-poky-linux/4.9.2/include-fixed
>>> -isystem /data/poky-master/tmp/sysroots/intel-corei7-64/usr/include
>>> -D_LIBC_REENTRANT -include
>>> /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/libc-modules.h
>>> -DMODULE_NAME=rtld -include ../include/libc-symbols.h  -DPIC -DSHARED     -o
>>> /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os
>>> -MD -MP -MF
>>> /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os.dt
>>> -MT
>>> /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os
>>> | dl-caller.c:1:0: error: SSE instruction set disabled, using 387
>>> arithmetics [-Werror]
>>> |  /* Check whether caller comes from the right place.
>>> |  ^
>>> | dl-open.c:1:0: error: SSE instruction set disabled, using 387 arithmetics
>>> [-Werror]
>>> |  /* Load a shared object at runtime, relocate it, and run its initializer.
>>> |  ^
>>> | cc1: all warnings being treated as errors
>>> | cc1: all warnings being treated as errors
>>
>> The real problem is we are injecting -mfpmath=sse -msse4.2 via CCARGS
>> and for this particular file glibc says  -mno-sse -mno-mmx
>> so it defaults to x87 80bit arithmetics. May be we should get a bit
>> milder with optimizations for this case when compiling glibc. Since
>> glibc has its own notion about floating point.
>>
>> I think this issue was there even with older version of glibc for i7
>> but it was flagged as a warning, glibc 2.21 now uses -Werror by
>> default. Can you confirm that via inspecting 2.20 glibc build logs for
>> this machine ?
>>
>> I have pushed another patch to disable sse for replacing fpu. Please
>> try it out and let me know if it fixed it.
>>
>
> The new branch is working well for me, for wandboard-quad, beaglebone,
> and cubieboard2.
>
>>>
>>> Ross
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

Hi Richard/All

I have refreshed the branch to include the patch which moves the src
uri to use the newly released glibc 2.21 branch
and please run it via autobuilder ( top 5 commits )

Thanks
-Khem



On Tue, Feb 3, 2015 at 10:43 PM, Dan McGregor <danismostlikely@gmail.com> wrote:
> On 2 February 2015 at 23:03, Khem Raj <raj.khem@gmail.com> wrote:
>> On Mon, Feb 2, 2015 at 1:45 PM, Burton, Ross <ross.burton@intel.com> wrote:
>>>
>>> On 2 February 2015 at 18:33, Khem Raj <raj.khem@gmail.com> wrote:
>>>>
>>>> Yeah, I am on archlinux (the other end of spectrum). Nevertheless, I have
>>>> updated the contrib tree which fixes cross-localedef-native compile time
>>>> issue. So you should be good
>>>> to go now.
>>>
>>>
>>> Bad news, glibc is now failing:
>>>
>>> | x86_64-poky-linux-gcc  -m64 -march=corei7 -mtune=corei7 -mfpmath=sse
>>> -msse4.2
>>> --sysroot=/data/poky-master/tmp/sysroots/intel-corei7-64-tcbootstrap
>>> dl-open.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Werror -Winline
>>> -Wno-error=undef -Wundef -Wwrite-strings -feliminate-unused-debug-types
>>> -fmerge-all-constants -frounding-math -g -pipe -Wstrict-prototypes   -fPIC
>>> -mno-sse -mno-mmx        -I../include
>>> -I/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf
>>> -I/data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux
>>> -I../sysdeps/unix/sysv/linux/x86_64/64  -I../sysdeps/unix/sysv/linux/x86_64
>>> -I../sysdeps/unix/sysv/linux/x86  -I../sysdeps/unix/sysv/linux/wordsize-64
>>> -I../sysdeps/x86_64/nptl  -I../sysdeps/unix/sysv/linux/include
>>> -I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread
>>> -I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv
>>> -I../sysdeps/unix/x86_64  -I../sysdeps/unix  -I../sysdeps/posix
>>> -I../sysdeps/x86_64/64  -I../sysdeps/x86_64/fpu/multiarch
>>> -I../sysdeps/x86_64/fpu  -I../sysdeps/x86/fpu/include -I../sysdeps/x86/fpu
>>> -I../sysdeps/x86_64/multiarch  -I../sysdeps/x86_64  -I../sysdeps/x86
>>> -I../sysdeps/ieee754/ldbl-96  -I../sysdeps/ieee754/dbl-64/wordsize-64
>>> -I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754/flt-32
>>> -I../sysdeps/wordsize-64  -I../sysdeps/ieee754  -I../sysdeps/generic  -I..
>>> -I../libio -I. -nostdinc -isystem
>>> /data/poky-master/tmp/sysroots/x86_64-linux/usr/lib/x86_64-poky-linux.gcc-cross-initial-x86_64/gcc/x86_64-poky-linux/4.9.2/include
>>> -isystem
>>> /data/poky-master/tmp/sysroots/x86_64-linux/usr/lib/x86_64-poky-linux.gcc-cross-initial-x86_64/gcc/x86_64-poky-linux/4.9.2/include-fixed
>>> -isystem /data/poky-master/tmp/sysroots/intel-corei7-64/usr/include
>>> -D_LIBC_REENTRANT -include
>>> /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/libc-modules.h
>>> -DMODULE_NAME=rtld -include ../include/libc-symbols.h  -DPIC -DSHARED     -o
>>> /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os
>>> -MD -MP -MF
>>> /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os.dt
>>> -MT
>>> /data/poky-master/tmp/work/corei7-64-poky-linux/glibc/2.21-r0/build-x86_64-poky-linux/elf/dl-open.os
>>> | dl-caller.c:1:0: error: SSE instruction set disabled, using 387
>>> arithmetics [-Werror]
>>> |  /* Check whether caller comes from the right place.
>>> |  ^
>>> | dl-open.c:1:0: error: SSE instruction set disabled, using 387 arithmetics
>>> [-Werror]
>>> |  /* Load a shared object at runtime, relocate it, and run its initializer.
>>> |  ^
>>> | cc1: all warnings being treated as errors
>>> | cc1: all warnings being treated as errors
>>
>> The real problem is we are injecting -mfpmath=sse -msse4.2 via CCARGS
>> and for this particular file glibc says  -mno-sse -mno-mmx
>> so it defaults to x87 80bit arithmetics. May be we should get a bit
>> milder with optimizations for this case when compiling glibc. Since
>> glibc has its own notion about floating point.
>>
>> I think this issue was there even with older version of glibc for i7
>> but it was flagged as a warning, glibc 2.21 now uses -Werror by
>> default. Can you confirm that via inspecting 2.20 glibc build logs for
>> this machine ?
>>
>> I have pushed another patch to disable sse for replacing fpu. Please
>> try it out and let me know if it fixed it.
>>
>
> The new branch is working well for me, for wandboard-quad, beaglebone,
> and cubieboard2.
>
>>>
>>> Ross
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 453 bytes --]

Hi Khem,

On 12 February 2015 at 07:35, Khem Raj <raj.khem@gmail.com> wrote:

> I have refreshed the branch to include the patch which moves the src
> uri to use the newly released glibc 2.21 branch
> and please run it via autobuilder ( top 5 commits )
>

I did a preliminary test on my local build machines (core-image-sato-sdk on
all arches), and valgrind fails with "unsupported version 2.21, Valgrind
requires glibc 2.2 - 2.19".

Ross

[-- Attachment #2: Type: text/html, Size: 917 bytes --]

Re: [OE-core] [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Burton, Ross]

Hi Khem,

On 12 February 2015 at 07:35, Khem Raj <raj.khem@gmail.com> wrote:

> I have refreshed the branch to include the patch which moves the src
> uri to use the newly released glibc 2.21 branch
> and please run it via autobuilder ( top 5 commits )
>

I did a preliminary test on my local build machines (core-image-sato-sdk on
all arches), and valgrind fails with "unsupported version 2.21, Valgrind
requires glibc 2.2 - 2.19".

Ross

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 453 bytes --]

Hi Khem,

On 12 February 2015 at 07:35, Khem Raj <raj.khem@gmail.com> wrote:

> I have refreshed the branch to include the patch which moves the src
> uri to use the newly released glibc 2.21 branch
> and please run it via autobuilder ( top 5 commits )
>

I did a preliminary test on my local build machines (core-image-sato-sdk on
all arches), and valgrind fails with "unsupported version 2.21, Valgrind
requires glibc 2.2 - 2.19".

Ross

[-- Attachment #2: Type: text/html, Size: 917 bytes --]

Re: [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Richard Purdie]

Hi Khem,

On Thu, 2015-02-12 at 15:35 +0800, Khem Raj wrote:
> I have refreshed the branch to include the patch which moves the src
> uri to use the newly released glibc 2.21 branch
> and please run it via autobuilder ( top 5 commits )

Its running on the autobuilder at the moment. Errors will be reported to
the error reporting system and can be seen at:

http://errors.yoctoproject.org/Errors/Search/?items=10&query=be29d13a847d458efaf542ed302e48050f67a655

Right now, poky-tiny failed due to warning are errors and unused
symbols. Minnow failed due to SSE instruction issues. Full build logs
are also available on the autobuilder:

https://autobuilder.yoctoproject.org/main/tgrid

as ross/mut-next. We do have other changes in the branch but the above
are pretty clearly glibc.

Other errors will go to the places above as the builds complete/fail.

Cheers,

Richard

Re: [OE-core] [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Richard Purdie]

Hi Khem,

On Thu, 2015-02-12 at 15:35 +0800, Khem Raj wrote:
> I have refreshed the branch to include the patch which moves the src
> uri to use the newly released glibc 2.21 branch
> and please run it via autobuilder ( top 5 commits )

Its running on the autobuilder at the moment. Errors will be reported to
the error reporting system and can be seen at:

http://errors.yoctoproject.org/Errors/Search/?items=10&query=be29d13a847d458efaf542ed302e48050f67a655

Right now, poky-tiny failed due to warning are errors and unused
symbols. Minnow failed due to SSE instruction issues. Full build logs
are also available on the autobuilder:

https://autobuilder.yoctoproject.org/main/tgrid

as ross/mut-next. We do have other changes in the branch but the above
are pretty clearly glibc.

Other errors will go to the places above as the builds complete/fail.

Cheers,

Richard

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Richard Purdie]

Hi Khem,

On Thu, 2015-02-12 at 15:35 +0800, Khem Raj wrote:
> I have refreshed the branch to include the patch which moves the src
> uri to use the newly released glibc 2.21 branch
> and please run it via autobuilder ( top 5 commits )

Its running on the autobuilder at the moment. Errors will be reported to
the error reporting system and can be seen at:

http://errors.yoctoproject.org/Errors/Search/?items=10&query=be29d13a847d458efaf542ed302e48050f67a655

Right now, poky-tiny failed due to warning are errors and unused
symbols. Minnow failed due to SSE instruction issues. Full build logs
are also available on the autobuilder:

https://autobuilder.yoctoproject.org/main/tgrid

as ross/mut-next. We do have other changes in the branch but the above
are pretty clearly glibc.

Other errors will go to the places above as the builds complete/fail.

Cheers,

Richard

Re: [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 414 bytes --]

Hi,

On 14 February 2015 at 10:06, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> Right now, poky-tiny failed due to warning are errors and unused
> symbols. Minnow failed due to SSE instruction issues. Full build logs
> are also available on the autobuilder:
>

Now those SSE errors I thought were fixed - is this more of the same or did
I manage to drop a patch when merging?

Ross

[-- Attachment #2: Type: text/html, Size: 859 bytes --]

Re: [OE-core] [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Burton, Ross]

Hi,

On 14 February 2015 at 10:06, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> Right now, poky-tiny failed due to warning are errors and unused
> symbols. Minnow failed due to SSE instruction issues. Full build logs
> are also available on the autobuilder:
>

Now those SSE errors I thought were fixed - is this more of the same or did
I manage to drop a patch when merging?

Ross

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 414 bytes --]

Hi,

On 14 February 2015 at 10:06, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> Right now, poky-tiny failed due to warning are errors and unused
> symbols. Minnow failed due to SSE instruction issues. Full build logs
> are also available on the autobuilder:
>

Now those SSE errors I thought were fixed - is this more of the same or did
I manage to drop a patch when merging?

Ross

[-- Attachment #2: Type: text/html, Size: 859 bytes --]

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Dan McGregor]

[-- Attachment #1: Type: text/plain, Size: 856 bytes --]

On 14 Feb 2015 07:09, "Burton, Ross" <ross.burton@intel.com> wrote:
>
> Hi,
>
> On 14 February 2015 at 10:06, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:
>>
>> Right now, poky-tiny failed due to warning are errors and unused
>> symbols. Minnow failed due to SSE instruction issues. Full build logs
>> are also available on the autobuilder:
>
>
> Now those SSE errors I thought were fixed - is this more of the same or
did I manage to drop a patch when merging?
>
> Ross
>

There are SSE errors that were fixed upstream post-release. I don't know if
that's what's affecting you, but they're not in these recipes.

> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 1337 bytes --]

Re: [OE-core] [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Dan McGregor]

On 14 Feb 2015 07:09, "Burton, Ross" <ross.burton@intel.com> wrote:
>
> Hi,
>
> On 14 February 2015 at 10:06, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:
>>
>> Right now, poky-tiny failed due to warning are errors and unused
>> symbols. Minnow failed due to SSE instruction issues. Full build logs
>> are also available on the autobuilder:
>
>
> Now those SSE errors I thought were fixed - is this more of the same or
did I manage to drop a patch when merging?
>
> Ross
>

There are SSE errors that were fixed upstream post-release. I don't know if
that's what's affecting you, but they're not in these recipes.

> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

Re: [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Richard Purdie]

On Sat, 2015-02-14 at 10:06 +0000, Richard Purdie wrote:
> Hi Khem,
> 
> On Thu, 2015-02-12 at 15:35 +0800, Khem Raj wrote:
> > I have refreshed the branch to include the patch which moves the src
> > uri to use the newly released glibc 2.21 branch
> > and please run it via autobuilder ( top 5 commits )
> 
> Its running on the autobuilder at the moment. Errors will be reported to
> the error reporting system and can be seen at:
> 
> http://errors.yoctoproject.org/Errors/Search/?items=10&query=be29d13a847d458efaf542ed302e48050f67a655
> 
> Right now, poky-tiny failed due to warning are errors and unused
> symbols. Minnow failed due to SSE instruction issues. Full build logs
> are also available on the autobuilder:
> 
> https://autobuilder.yoctoproject.org/main/tgrid
> 
> as ross/mut-next. We do have other changes in the branch but the above
> are pretty clearly glibc.
> 
> Other errors will go to the places above as the builds complete/fail.

FWIW I tested the gcc upgrade without glibc and that seems ok so I've
merged that whilst we work out the issues with glibc.

Cheers,

Richard

Re: [OE-core] [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Richard Purdie]

On Sat, 2015-02-14 at 10:06 +0000, Richard Purdie wrote:
> Hi Khem,
> 
> On Thu, 2015-02-12 at 15:35 +0800, Khem Raj wrote:
> > I have refreshed the branch to include the patch which moves the src
> > uri to use the newly released glibc 2.21 branch
> > and please run it via autobuilder ( top 5 commits )
> 
> Its running on the autobuilder at the moment. Errors will be reported to
> the error reporting system and can be seen at:
> 
> http://errors.yoctoproject.org/Errors/Search/?items=10&query=be29d13a847d458efaf542ed302e48050f67a655
> 
> Right now, poky-tiny failed due to warning are errors and unused
> symbols. Minnow failed due to SSE instruction issues. Full build logs
> are also available on the autobuilder:
> 
> https://autobuilder.yoctoproject.org/main/tgrid
> 
> as ross/mut-next. We do have other changes in the branch but the above
> are pretty clearly glibc.
> 
> Other errors will go to the places above as the builds complete/fail.

FWIW I tested the gcc upgrade without glibc and that seems ok so I've
merged that whilst we work out the issues with glibc.

Cheers,

Richard

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Richard Purdie]

On Sat, 2015-02-14 at 10:06 +0000, Richard Purdie wrote:
> Hi Khem,
> 
> On Thu, 2015-02-12 at 15:35 +0800, Khem Raj wrote:
> > I have refreshed the branch to include the patch which moves the src
> > uri to use the newly released glibc 2.21 branch
> > and please run it via autobuilder ( top 5 commits )
> 
> Its running on the autobuilder at the moment. Errors will be reported to
> the error reporting system and can be seen at:
> 
> http://errors.yoctoproject.org/Errors/Search/?items=10&query=be29d13a847d458efaf542ed302e48050f67a655
> 
> Right now, poky-tiny failed due to warning are errors and unused
> symbols. Minnow failed due to SSE instruction issues. Full build logs
> are also available on the autobuilder:
> 
> https://autobuilder.yoctoproject.org/main/tgrid
> 
> as ross/mut-next. We do have other changes in the branch but the above
> are pretty clearly glibc.
> 
> Other errors will go to the places above as the builds complete/fail.

FWIW I tested the gcc upgrade without glibc and that seems ok so I've
merged that whilst we work out the issues with glibc.

Cheers,

Richard

Re: [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1886 bytes --]

We should extend:
./meta/recipes-devtools/valgrind/valgrind/glibc-2.20.patch

to allow building valgrind with glibc-2.21, currently it fails with:

| checking the GLIBC_VERSION version... unsupported version 2.21
| configure: error: Valgrind requires glibc version 2.2 - 2.19
| Configure failed. The contents of all config.log files follows to aid
debugging
| ERROR: oe_runconf failed


On Sun, Feb 15, 2015 at 10:59 PM, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> On Sat, 2015-02-14 at 10:06 +0000, Richard Purdie wrote:
> > Hi Khem,
> >
> > On Thu, 2015-02-12 at 15:35 +0800, Khem Raj wrote:
> > > I have refreshed the branch to include the patch which moves the src
> > > uri to use the newly released glibc 2.21 branch
> > > and please run it via autobuilder ( top 5 commits )
> >
> > Its running on the autobuilder at the moment. Errors will be reported to
> > the error reporting system and can be seen at:
> >
> >
> http://errors.yoctoproject.org/Errors/Search/?items=10&query=be29d13a847d458efaf542ed302e48050f67a655
> >
> > Right now, poky-tiny failed due to warning are errors and unused
> > symbols. Minnow failed due to SSE instruction issues. Full build logs
> > are also available on the autobuilder:
> >
> > https://autobuilder.yoctoproject.org/main/tgrid
> >
> > as ross/mut-next. We do have other changes in the branch but the above
> > are pretty clearly glibc.
> >
> > Other errors will go to the places above as the builds complete/fail.
>
> FWIW I tested the gcc upgrade without glibc and that seems ok so I've
> merged that whilst we work out the issues with glibc.
>
> Cheers,
>
> Richard
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 2890 bytes --]

Re: [OE-core] [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Martin Jansa]

We should extend:
./meta/recipes-devtools/valgrind/valgrind/glibc-2.20.patch

to allow building valgrind with glibc-2.21, currently it fails with:

| checking the GLIBC_VERSION version... unsupported version 2.21
| configure: error: Valgrind requires glibc version 2.2 - 2.19
| Configure failed. The contents of all config.log files follows to aid
debugging
| ERROR: oe_runconf failed


On Sun, Feb 15, 2015 at 10:59 PM, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> On Sat, 2015-02-14 at 10:06 +0000, Richard Purdie wrote:
> > Hi Khem,
> >
> > On Thu, 2015-02-12 at 15:35 +0800, Khem Raj wrote:
> > > I have refreshed the branch to include the patch which moves the src
> > > uri to use the newly released glibc 2.21 branch
> > > and please run it via autobuilder ( top 5 commits )
> >
> > Its running on the autobuilder at the moment. Errors will be reported to
> > the error reporting system and can be seen at:
> >
> >
> http://errors.yoctoproject.org/Errors/Search/?items=10&query=be29d13a847d458efaf542ed302e48050f67a655
> >
> > Right now, poky-tiny failed due to warning are errors and unused
> > symbols. Minnow failed due to SSE instruction issues. Full build logs
> > are also available on the autobuilder:
> >
> > https://autobuilder.yoctoproject.org/main/tgrid
> >
> > as ross/mut-next. We do have other changes in the branch but the above
> > are pretty clearly glibc.
> >
> > Other errors will go to the places above as the builds complete/fail.
>
> FWIW I tested the gcc upgrade without glibc and that seems ok so I've
> merged that whilst we work out the issues with glibc.
>
> Cheers,
>
> Richard
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1886 bytes --]

We should extend:
./meta/recipes-devtools/valgrind/valgrind/glibc-2.20.patch

to allow building valgrind with glibc-2.21, currently it fails with:

| checking the GLIBC_VERSION version... unsupported version 2.21
| configure: error: Valgrind requires glibc version 2.2 - 2.19
| Configure failed. The contents of all config.log files follows to aid
debugging
| ERROR: oe_runconf failed


On Sun, Feb 15, 2015 at 10:59 PM, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> On Sat, 2015-02-14 at 10:06 +0000, Richard Purdie wrote:
> > Hi Khem,
> >
> > On Thu, 2015-02-12 at 15:35 +0800, Khem Raj wrote:
> > > I have refreshed the branch to include the patch which moves the src
> > > uri to use the newly released glibc 2.21 branch
> > > and please run it via autobuilder ( top 5 commits )
> >
> > Its running on the autobuilder at the moment. Errors will be reported to
> > the error reporting system and can be seen at:
> >
> >
> http://errors.yoctoproject.org/Errors/Search/?items=10&query=be29d13a847d458efaf542ed302e48050f67a655
> >
> > Right now, poky-tiny failed due to warning are errors and unused
> > symbols. Minnow failed due to SSE instruction issues. Full build logs
> > are also available on the autobuilder:
> >
> > https://autobuilder.yoctoproject.org/main/tgrid
> >
> > as ross/mut-next. We do have other changes in the branch but the above
> > are pretty clearly glibc.
> >
> > Other errors will go to the places above as the builds complete/fail.
>
> FWIW I tested the gcc upgrade without glibc and that seems ok so I've
> merged that whilst we work out the issues with glibc.
>
> Cheers,
>
> Richard
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 2890 bytes --]

[PATCH 1/2] valgrind: add glibc-2.21 to glibc.patch

[Martin Jansa]

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
 .../valgrind/valgrind/glibc-2.20.patch             | 30 ------------------
 .../recipes-devtools/valgrind/valgrind/glibc.patch | 37 ++++++++++++++++++++++
 meta/recipes-devtools/valgrind/valgrind_3.10.1.bb  |  2 +-
 3 files changed, 38 insertions(+), 31 deletions(-)
 delete mode 100644 meta/recipes-devtools/valgrind/valgrind/glibc-2.20.patch
 create mode 100644 meta/recipes-devtools/valgrind/valgrind/glibc.patch

diff --git a/meta/recipes-devtools/valgrind/valgrind/glibc-2.20.patch b/meta/recipes-devtools/valgrind/valgrind/glibc-2.20.patch
deleted file mode 100644
index fab4044..0000000
--- a/meta/recipes-devtools/valgrind/valgrind/glibc-2.20.patch
+++ /dev/null
@@ -1,30 +0,0 @@
-Backport of glibc 2.19 and 2.20 support.
-
-Upstream-Status: Backport
-Signed-off-by: Ross Burton <ross.burton@intel.com>
-
-diff --git a/configure.ac b/configure.ac
-index 229ab98..1c18108 100644
---- a/configure.ac
-+++ b/configure.ac
-@@ -918,6 +918,20 @@ case "${GLIBC_VERSION}" in
- 	DEFAULT_SUPP="glibc-2.34567-NPTL-helgrind.supp ${DEFAULT_SUPP}"
- 	DEFAULT_SUPP="glibc-2.X-drd.supp ${DEFAULT_SUPP}"
- 	;;
-+     2.19)
-+	AC_MSG_RESULT(2.19 family)
-+	AC_DEFINE([GLIBC_2_19], 1, [Define to 1 if you're using glibc 2.19.x])
-+	DEFAULT_SUPP="glibc-2.X.supp ${DEFAULT_SUPP}"
-+	DEFAULT_SUPP="$srcdir/glibc-2.34567-NPTL-helgrind.supp ${DEFAULT_SUPP}"
-+	DEFAULT_SUPP="$srcdir/glibc-2.X-drd.supp ${DEFAULT_SUPP}"
-+	;;
-+     2.20)
-+	AC_MSG_RESULT(2.20 family)
-+	AC_DEFINE([GLIBC_2_20], 1, [Define to 1 if you're using glibc 2.20.x])
-+	DEFAULT_SUPP="glibc-2.X.supp ${DEFAULT_SUPP}"
-+	DEFAULT_SUPP="$srcdir/glibc-2.34567-NPTL-helgrind.supp ${DEFAULT_SUPP}"
-+	DEFAULT_SUPP="$srcdir/glibc-2.X-drd.supp ${DEFAULT_SUPP}"
-+	;;
-      darwin)
- 	AC_MSG_RESULT(Darwin)
- 	AC_DEFINE([DARWIN_LIBC], 1, [Define to 1 if you're using Darwin])
diff --git a/meta/recipes-devtools/valgrind/valgrind/glibc.patch b/meta/recipes-devtools/valgrind/valgrind/glibc.patch
new file mode 100644
index 0000000..8b902dd
--- /dev/null
+++ b/meta/recipes-devtools/valgrind/valgrind/glibc.patch
@@ -0,0 +1,37 @@
+Backport of glibc 2.19 and 2.20 and 2.21 support.
+
+Upstream-Status: Backport
+Signed-off-by: Ross Burton <ross.burton@intel.com>
+
+diff --git a/configure.ac b/configure.ac
+index 229ab98..1c18108 100644
+--- a/configure.ac
++++ b/configure.ac
+@@ -918,6 +918,27 @@ case "${GLIBC_VERSION}" in
+ 	DEFAULT_SUPP="glibc-2.34567-NPTL-helgrind.supp ${DEFAULT_SUPP}"
+ 	DEFAULT_SUPP="glibc-2.X-drd.supp ${DEFAULT_SUPP}"
+ 	;;
++     2.19)
++	AC_MSG_RESULT(2.19 family)
++	AC_DEFINE([GLIBC_2_19], 1, [Define to 1 if you're using glibc 2.19.x])
++	DEFAULT_SUPP="glibc-2.X.supp ${DEFAULT_SUPP}"
++	DEFAULT_SUPP="$srcdir/glibc-2.34567-NPTL-helgrind.supp ${DEFAULT_SUPP}"
++	DEFAULT_SUPP="$srcdir/glibc-2.X-drd.supp ${DEFAULT_SUPP}"
++	;;
++     2.20)
++	AC_MSG_RESULT(2.20 family)
++	AC_DEFINE([GLIBC_2_20], 1, [Define to 1 if you're using glibc 2.20.x])
++	DEFAULT_SUPP="glibc-2.X.supp ${DEFAULT_SUPP}"
++	DEFAULT_SUPP="$srcdir/glibc-2.34567-NPTL-helgrind.supp ${DEFAULT_SUPP}"
++	DEFAULT_SUPP="$srcdir/glibc-2.X-drd.supp ${DEFAULT_SUPP}"
++	;;
++     2.21)
++	AC_MSG_RESULT(2.21 family)
++	AC_DEFINE([GLIBC_2_21], 1, [Define to 1 if you're using glibc 2.21.x])
++	DEFAULT_SUPP="glibc-2.X.supp ${DEFAULT_SUPP}"
++	DEFAULT_SUPP="$srcdir/glibc-2.34567-NPTL-helgrind.supp ${DEFAULT_SUPP}"
++	DEFAULT_SUPP="$srcdir/glibc-2.X-drd.supp ${DEFAULT_SUPP}"
++	;;
+      darwin)
+ 	AC_MSG_RESULT(Darwin)
+ 	AC_DEFINE([DARWIN_LIBC], 1, [Define to 1 if you're using Darwin])
diff --git a/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb b/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
index 7d02b9f..1c2ac61 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.10.1.bb
@@ -16,7 +16,7 @@ SRC_URI = "http://www.valgrind.org/downloads/valgrind-${PV}.tar.bz2 \
            file://fixed-perl-path.patch \
            file://Added-support-for-PPC-instructions-mfatbu-mfatbl.patch \
            file://sepbuildfix.patch \
-           file://glibc-2.20.patch \
+           file://glibc.patch \
            file://force-nostabs.patch \
            file://remove-arm-variant-specific.patch \
            file://remove-ppc-tests-failing-build.patch \
-- 
2.3.0

[PATCH 2/2] license.bbclass: fix unexpected operator for LICENSE values with space

[Martin Jansa]

* add quotes around pkged_lic so that it works correctly with spaces
* fixes following error:
  run.license_create_manifest.50601: 193: [: GPLv2: unexpected operator

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
 meta/classes/license.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass
index 13c1a0f..044b3b0 100644
--- a/meta/classes/license.bbclass
+++ b/meta/classes/license.bbclass
@@ -50,7 +50,7 @@ license_create_manifest() {
 		pkged_pv="$(sed -n 's/^PV: //p' ${filename})"
 		pkged_name="$(basename $(readlink ${filename}))"
 		pkged_lic="$(sed -n "/^LICENSE_${pkged_name}: /{ s/^LICENSE_${pkged_name}: //; p }" ${filename})"
-		if [ -z ${pkged_lic} ]; then
+		if [ -z "${pkged_lic}" ]; then
 			# fallback checking value of LICENSE
 			pkged_lic="$(sed -n "/^LICENSE: /{ s/^LICENSE: //; p }" ${filename})"
 		fi
-- 
2.3.0

Re: [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

On Sat, Feb 14, 2015 at 2:06 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> Hi Khem,
>
> On Thu, 2015-02-12 at 15:35 +0800, Khem Raj wrote:
>> I have refreshed the branch to include the patch which moves the src
>> uri to use the newly released glibc 2.21 branch
>> and please run it via autobuilder ( top 5 commits )
>
> Its running on the autobuilder at the moment. Errors will be reported to
> the error reporting system and can be seen at:
>
> http://errors.yoctoproject.org/Errors/Search/?items=10&query=be29d13a847d458efaf542ed302e48050f67a655
>
> Right now, poky-tiny failed due to warning are errors and unused
> symbols. Minnow failed due to SSE instruction issues. Full build logs
> are also available on the autobuilder:
>
> https://autobuilder.yoctoproject.org/main/tgrid
>
> as ross/mut-next. We do have other changes in the branch but the above
> are pretty clearly glibc.
>
> Other errors will go to the places above as the builds complete/fail.

Thanks. So I see following errors categories and status

1. valgrind - Martin already sent a patch for that
2. slang - I could not yet reproduce it on my active build (mips) (
seems specific to x86/ppc )
3. poky-tiny - glibc build - ( pushed a fix for that in latest pull tree)
4. minnow/qemux86 - glibc failure - ( pushed a fix for that in latest
pull tree )
5. glibc build failure on qemuarm - need to reproduce here
6. Image failures are probably due to above not building

I might get slang reproduced soon on qemux86 if I do I will try to
push for a fix




>
> Cheers,
>
> Richard
>

Re: [OE-core] [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

On Sat, Feb 14, 2015 at 2:06 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> Hi Khem,
>
> On Thu, 2015-02-12 at 15:35 +0800, Khem Raj wrote:
>> I have refreshed the branch to include the patch which moves the src
>> uri to use the newly released glibc 2.21 branch
>> and please run it via autobuilder ( top 5 commits )
>
> Its running on the autobuilder at the moment. Errors will be reported to
> the error reporting system and can be seen at:
>
> http://errors.yoctoproject.org/Errors/Search/?items=10&query=be29d13a847d458efaf542ed302e48050f67a655
>
> Right now, poky-tiny failed due to warning are errors and unused
> symbols. Minnow failed due to SSE instruction issues. Full build logs
> are also available on the autobuilder:
>
> https://autobuilder.yoctoproject.org/main/tgrid
>
> as ross/mut-next. We do have other changes in the branch but the above
> are pretty clearly glibc.
>
> Other errors will go to the places above as the builds complete/fail.

Thanks. So I see following errors categories and status

1. valgrind - Martin already sent a patch for that
2. slang - I could not yet reproduce it on my active build (mips) (
seems specific to x86/ppc )
3. poky-tiny - glibc build - ( pushed a fix for that in latest pull tree)
4. minnow/qemux86 - glibc failure - ( pushed a fix for that in latest
pull tree )
5. glibc build failure on qemuarm - need to reproduce here
6. Image failures are probably due to above not building

I might get slang reproduced soon on qemux86 if I do I will try to
push for a fix




>
> Cheers,
>
> Richard
>

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

On Sat, Feb 14, 2015 at 2:06 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> Hi Khem,
>
> On Thu, 2015-02-12 at 15:35 +0800, Khem Raj wrote:
>> I have refreshed the branch to include the patch which moves the src
>> uri to use the newly released glibc 2.21 branch
>> and please run it via autobuilder ( top 5 commits )
>
> Its running on the autobuilder at the moment. Errors will be reported to
> the error reporting system and can be seen at:
>
> http://errors.yoctoproject.org/Errors/Search/?items=10&query=be29d13a847d458efaf542ed302e48050f67a655
>
> Right now, poky-tiny failed due to warning are errors and unused
> symbols. Minnow failed due to SSE instruction issues. Full build logs
> are also available on the autobuilder:
>
> https://autobuilder.yoctoproject.org/main/tgrid
>
> as ross/mut-next. We do have other changes in the branch but the above
> are pretty clearly glibc.
>
> Other errors will go to the places above as the builds complete/fail.

Thanks. So I see following errors categories and status

1. valgrind - Martin already sent a patch for that
2. slang - I could not yet reproduce it on my active build (mips) (
seems specific to x86/ppc )
3. poky-tiny - glibc build - ( pushed a fix for that in latest pull tree)
4. minnow/qemux86 - glibc failure - ( pushed a fix for that in latest
pull tree )
5. glibc build failure on qemuarm - need to reproduce here
6. Image failures are probably due to above not building

I might get slang reproduced soon on qemux86 if I do I will try to
push for a fix




>
> Cheers,
>
> Richard
>

Re: [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Richard Purdie]

On Tue, 2015-02-17 at 23:15 -0800, Khem Raj wrote:
> On Sat, Feb 14, 2015 at 2:06 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > Hi Khem,
> >
> > On Thu, 2015-02-12 at 15:35 +0800, Khem Raj wrote:
> >> I have refreshed the branch to include the patch which moves the src
> >> uri to use the newly released glibc 2.21 branch
> >> and please run it via autobuilder ( top 5 commits )
> >
> > Its running on the autobuilder at the moment. Errors will be reported to
> > the error reporting system and can be seen at:
> >
> > http://errors.yoctoproject.org/Errors/Search/?items=10&query=be29d13a847d458efaf542ed302e48050f67a655
> >
> > Right now, poky-tiny failed due to warning are errors and unused
> > symbols. Minnow failed due to SSE instruction issues. Full build logs
> > are also available on the autobuilder:
> >
> > https://autobuilder.yoctoproject.org/main/tgrid
> >
> > as ross/mut-next. We do have other changes in the branch but the above
> > are pretty clearly glibc.
> >
> > Other errors will go to the places above as the builds complete/fail.
> 
> Thanks. So I see following errors categories and status
> 
> 1. valgrind - Martin already sent a patch for that
> 2. slang - I could not yet reproduce it on my active build (mips) (
> seems specific to x86/ppc )
> 3. poky-tiny - glibc build - ( pushed a fix for that in latest pull tree)
> 4. minnow/qemux86 - glibc failure - ( pushed a fix for that in latest
> pull tree )
> 5. glibc build failure on qemuarm - need to reproduce here
> 6. Image failures are probably due to above not building
> 
> I might get slang reproduced soon on qemux86 if I do I will try to
> push for a fix

I think slang is a parallel make race from another patch so don't worry
about that one, Robert will likely get that when he comes back.

Cheers,

Richard

Re: [OE-core] [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Richard Purdie]

On Tue, 2015-02-17 at 23:15 -0800, Khem Raj wrote:
> On Sat, Feb 14, 2015 at 2:06 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > Hi Khem,
> >
> > On Thu, 2015-02-12 at 15:35 +0800, Khem Raj wrote:
> >> I have refreshed the branch to include the patch which moves the src
> >> uri to use the newly released glibc 2.21 branch
> >> and please run it via autobuilder ( top 5 commits )
> >
> > Its running on the autobuilder at the moment. Errors will be reported to
> > the error reporting system and can be seen at:
> >
> > http://errors.yoctoproject.org/Errors/Search/?items=10&query=be29d13a847d458efaf542ed302e48050f67a655
> >
> > Right now, poky-tiny failed due to warning are errors and unused
> > symbols. Minnow failed due to SSE instruction issues. Full build logs
> > are also available on the autobuilder:
> >
> > https://autobuilder.yoctoproject.org/main/tgrid
> >
> > as ross/mut-next. We do have other changes in the branch but the above
> > are pretty clearly glibc.
> >
> > Other errors will go to the places above as the builds complete/fail.
> 
> Thanks. So I see following errors categories and status
> 
> 1. valgrind - Martin already sent a patch for that
> 2. slang - I could not yet reproduce it on my active build (mips) (
> seems specific to x86/ppc )
> 3. poky-tiny - glibc build - ( pushed a fix for that in latest pull tree)
> 4. minnow/qemux86 - glibc failure - ( pushed a fix for that in latest
> pull tree )
> 5. glibc build failure on qemuarm - need to reproduce here
> 6. Image failures are probably due to above not building
> 
> I might get slang reproduced soon on qemux86 if I do I will try to
> push for a fix

I think slang is a parallel make race from another patch so don't worry
about that one, Robert will likely get that when he comes back.

Cheers,

Richard

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Richard Purdie]

On Tue, 2015-02-17 at 23:15 -0800, Khem Raj wrote:
> On Sat, Feb 14, 2015 at 2:06 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > Hi Khem,
> >
> > On Thu, 2015-02-12 at 15:35 +0800, Khem Raj wrote:
> >> I have refreshed the branch to include the patch which moves the src
> >> uri to use the newly released glibc 2.21 branch
> >> and please run it via autobuilder ( top 5 commits )
> >
> > Its running on the autobuilder at the moment. Errors will be reported to
> > the error reporting system and can be seen at:
> >
> > http://errors.yoctoproject.org/Errors/Search/?items=10&query=be29d13a847d458efaf542ed302e48050f67a655
> >
> > Right now, poky-tiny failed due to warning are errors and unused
> > symbols. Minnow failed due to SSE instruction issues. Full build logs
> > are also available on the autobuilder:
> >
> > https://autobuilder.yoctoproject.org/main/tgrid
> >
> > as ross/mut-next. We do have other changes in the branch but the above
> > are pretty clearly glibc.
> >
> > Other errors will go to the places above as the builds complete/fail.
> 
> Thanks. So I see following errors categories and status
> 
> 1. valgrind - Martin already sent a patch for that
> 2. slang - I could not yet reproduce it on my active build (mips) (
> seems specific to x86/ppc )
> 3. poky-tiny - glibc build - ( pushed a fix for that in latest pull tree)
> 4. minnow/qemux86 - glibc failure - ( pushed a fix for that in latest
> pull tree )
> 5. glibc build failure on qemuarm - need to reproduce here
> 6. Image failures are probably due to above not building
> 
> I might get slang reproduced soon on qemux86 if I do I will try to
> push for a fix

I think slang is a parallel make race from another patch so don't worry
about that one, Robert will likely get that when he comes back.

Cheers,

Richard

Re: [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

> On Feb 17, 2015, at 11:46 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> 
> On Tue, 2015-02-17 at 23:15 -0800, Khem Raj wrote:
>> On Sat, Feb 14, 2015 at 2:06 AM, Richard Purdie
>> <richard.purdie@linuxfoundation.org> wrote:
>>> Hi Khem,
>>> 
>>> On Thu, 2015-02-12 at 15:35 +0800, Khem Raj wrote:
>>>> I have refreshed the branch to include the patch which moves the src
>>>> uri to use the newly released glibc 2.21 branch
>>>> and please run it via autobuilder ( top 5 commits )
>>> 
>>> Its running on the autobuilder at the moment. Errors will be reported to
>>> the error reporting system and can be seen at:
>>> 
>>> http://errors.yoctoproject.org/Errors/Search/?items=10&query=be29d13a847d458efaf542ed302e48050f67a655
>>> 
>>> Right now, poky-tiny failed due to warning are errors and unused
>>> symbols. Minnow failed due to SSE instruction issues. Full build logs
>>> are also available on the autobuilder:
>>> 
>>> https://autobuilder.yoctoproject.org/main/tgrid
>>> 
>>> as ross/mut-next. We do have other changes in the branch but the above
>>> are pretty clearly glibc.
>>> 
>>> Other errors will go to the places above as the builds complete/fail.
>> 
>> Thanks. So I see following errors categories and status
>> 
>> 1. valgrind - Martin already sent a patch for that
>> 2. slang - I could not yet reproduce it on my active build (mips) (
>> seems specific to x86/ppc )
>> 3. poky-tiny - glibc build - ( pushed a fix for that in latest pull tree)
>> 4. minnow/qemux86 - glibc failure - ( pushed a fix for that in latest
>> pull tree )
>> 5. glibc build failure on qemuarm - need to reproduce here
>> 6. Image failures are probably due to above not building
>> 
>> I might get slang reproduced soon on qemux86 if I do I will try to
>> push for a fix
> 
> I think slang is a parallel make race from another patch so don't worry
> about that one, Robert will likely get that when he comes back.

OK thats why I am not seeing it on my qemux86 build. 

this leaves us with only one problem - glibc/qemuarm issue

http://errors.yoctoproject.org/Errors/Details/8679/

I have seen this error with eglibc-2.19 and glibc 2.20 as well on x86 and arm as well in cases when using
toolchain from sstate and rebuilding glibc with that. I assume this could be  unrelated to glibc upgrade
and may be a latent problem. Could be missing dependency on a native tool or some such. I have been attributing it to gold
but that just might have been a red herring.

I will see if I can get to reproduce it.

Re: [OE-core] [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

> On Feb 17, 2015, at 11:46 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> 
> On Tue, 2015-02-17 at 23:15 -0800, Khem Raj wrote:
>> On Sat, Feb 14, 2015 at 2:06 AM, Richard Purdie
>> <richard.purdie@linuxfoundation.org> wrote:
>>> Hi Khem,
>>> 
>>> On Thu, 2015-02-12 at 15:35 +0800, Khem Raj wrote:
>>>> I have refreshed the branch to include the patch which moves the src
>>>> uri to use the newly released glibc 2.21 branch
>>>> and please run it via autobuilder ( top 5 commits )
>>> 
>>> Its running on the autobuilder at the moment. Errors will be reported to
>>> the error reporting system and can be seen at:
>>> 
>>> http://errors.yoctoproject.org/Errors/Search/?items=10&query=be29d13a847d458efaf542ed302e48050f67a655
>>> 
>>> Right now, poky-tiny failed due to warning are errors and unused
>>> symbols. Minnow failed due to SSE instruction issues. Full build logs
>>> are also available on the autobuilder:
>>> 
>>> https://autobuilder.yoctoproject.org/main/tgrid
>>> 
>>> as ross/mut-next. We do have other changes in the branch but the above
>>> are pretty clearly glibc.
>>> 
>>> Other errors will go to the places above as the builds complete/fail.
>> 
>> Thanks. So I see following errors categories and status
>> 
>> 1. valgrind - Martin already sent a patch for that
>> 2. slang - I could not yet reproduce it on my active build (mips) (
>> seems specific to x86/ppc )
>> 3. poky-tiny - glibc build - ( pushed a fix for that in latest pull tree)
>> 4. minnow/qemux86 - glibc failure - ( pushed a fix for that in latest
>> pull tree )
>> 5. glibc build failure on qemuarm - need to reproduce here
>> 6. Image failures are probably due to above not building
>> 
>> I might get slang reproduced soon on qemux86 if I do I will try to
>> push for a fix
> 
> I think slang is a parallel make race from another patch so don't worry
> about that one, Robert will likely get that when he comes back.

OK thats why I am not seeing it on my qemux86 build. 

this leaves us with only one problem - glibc/qemuarm issue

http://errors.yoctoproject.org/Errors/Details/8679/

I have seen this error with eglibc-2.19 and glibc 2.20 as well on x86 and arm as well in cases when using
toolchain from sstate and rebuilding glibc with that. I assume this could be  unrelated to glibc upgrade
and may be a latent problem. Could be missing dependency on a native tool or some such. I have been attributing it to gold
but that just might have been a red herring.

I will see if I can get to reproduce it.

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

> On Feb 17, 2015, at 11:46 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> 
> On Tue, 2015-02-17 at 23:15 -0800, Khem Raj wrote:
>> On Sat, Feb 14, 2015 at 2:06 AM, Richard Purdie
>> <richard.purdie@linuxfoundation.org> wrote:
>>> Hi Khem,
>>> 
>>> On Thu, 2015-02-12 at 15:35 +0800, Khem Raj wrote:
>>>> I have refreshed the branch to include the patch which moves the src
>>>> uri to use the newly released glibc 2.21 branch
>>>> and please run it via autobuilder ( top 5 commits )
>>> 
>>> Its running on the autobuilder at the moment. Errors will be reported to
>>> the error reporting system and can be seen at:
>>> 
>>> http://errors.yoctoproject.org/Errors/Search/?items=10&query=be29d13a847d458efaf542ed302e48050f67a655
>>> 
>>> Right now, poky-tiny failed due to warning are errors and unused
>>> symbols. Minnow failed due to SSE instruction issues. Full build logs
>>> are also available on the autobuilder:
>>> 
>>> https://autobuilder.yoctoproject.org/main/tgrid
>>> 
>>> as ross/mut-next. We do have other changes in the branch but the above
>>> are pretty clearly glibc.
>>> 
>>> Other errors will go to the places above as the builds complete/fail.
>> 
>> Thanks. So I see following errors categories and status
>> 
>> 1. valgrind - Martin already sent a patch for that
>> 2. slang - I could not yet reproduce it on my active build (mips) (
>> seems specific to x86/ppc )
>> 3. poky-tiny - glibc build - ( pushed a fix for that in latest pull tree)
>> 4. minnow/qemux86 - glibc failure - ( pushed a fix for that in latest
>> pull tree )
>> 5. glibc build failure on qemuarm - need to reproduce here
>> 6. Image failures are probably due to above not building
>> 
>> I might get slang reproduced soon on qemux86 if I do I will try to
>> push for a fix
> 
> I think slang is a parallel make race from another patch so don't worry
> about that one, Robert will likely get that when he comes back.

OK thats why I am not seeing it on my qemux86 build. 

this leaves us with only one problem - glibc/qemuarm issue

http://errors.yoctoproject.org/Errors/Details/8679/

I have seen this error with eglibc-2.19 and glibc 2.20 as well on x86 and arm as well in cases when using
toolchain from sstate and rebuilding glibc with that. I assume this could be  unrelated to glibc upgrade
and may be a latent problem. Could be missing dependency on a native tool or some such. I have been attributing it to gold
but that just might have been a red herring.

I will see if I can get to reproduce it.

Re: [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Richard Purdie]

On Wed, 2015-02-18 at 01:01 -0800, Khem Raj wrote:
> OK thats why I am not seeing it on my qemux86 build. 
> 
> this leaves us with only one problem - glibc/qemuarm issue
> 
> http://errors.yoctoproject.org/Errors/Details/8679/
> 
> I have seen this error with eglibc-2.19 and glibc 2.20 as well on x86 and arm as well in cases when using
> toolchain from sstate and rebuilding glibc with that. I assume this could be  unrelated to glibc upgrade
> and may be a latent problem. Could be missing dependency on a native tool or some such. I have been attributing it to gold
> but that just might have been a red herring.
> 
> I will see if I can get to reproduce it.

I tried another build with the three patches from your oe-core contrib
branch applied. Error report out is:

http://errors.yoctoproject.org/Errors/Search/?items=10&query=b75fed99f2aa86b49844dd0cf06991767f6f26d3

i.e. we're still seeing SSE errors in glibc builds. Am I missing some
patches or something?

Cheers,

Richard

Re: [OE-core] [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Richard Purdie]

On Wed, 2015-02-18 at 01:01 -0800, Khem Raj wrote:
> OK thats why I am not seeing it on my qemux86 build. 
> 
> this leaves us with only one problem - glibc/qemuarm issue
> 
> http://errors.yoctoproject.org/Errors/Details/8679/
> 
> I have seen this error with eglibc-2.19 and glibc 2.20 as well on x86 and arm as well in cases when using
> toolchain from sstate and rebuilding glibc with that. I assume this could be  unrelated to glibc upgrade
> and may be a latent problem. Could be missing dependency on a native tool or some such. I have been attributing it to gold
> but that just might have been a red herring.
> 
> I will see if I can get to reproduce it.

I tried another build with the three patches from your oe-core contrib
branch applied. Error report out is:

http://errors.yoctoproject.org/Errors/Search/?items=10&query=b75fed99f2aa86b49844dd0cf06991767f6f26d3

i.e. we're still seeing SSE errors in glibc builds. Am I missing some
patches or something?

Cheers,

Richard

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Richard Purdie]

On Wed, 2015-02-18 at 01:01 -0800, Khem Raj wrote:
> OK thats why I am not seeing it on my qemux86 build. 
> 
> this leaves us with only one problem - glibc/qemuarm issue
> 
> http://errors.yoctoproject.org/Errors/Details/8679/
> 
> I have seen this error with eglibc-2.19 and glibc 2.20 as well on x86 and arm as well in cases when using
> toolchain from sstate and rebuilding glibc with that. I assume this could be  unrelated to glibc upgrade
> and may be a latent problem. Could be missing dependency on a native tool or some such. I have been attributing it to gold
> but that just might have been a red herring.
> 
> I will see if I can get to reproduce it.

I tried another build with the three patches from your oe-core contrib
branch applied. Error report out is:

http://errors.yoctoproject.org/Errors/Search/?items=10&query=b75fed99f2aa86b49844dd0cf06991767f6f26d3

i.e. we're still seeing SSE errors in glibc builds. Am I missing some
patches or something?

Cheers,

Richard

Re: [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Richard Purdie]

On Wed, 2015-02-18 at 11:51 +0000, Richard Purdie wrote:
> On Wed, 2015-02-18 at 01:01 -0800, Khem Raj wrote:
> > OK thats why I am not seeing it on my qemux86 build. 
> > 
> > this leaves us with only one problem - glibc/qemuarm issue
> > 
> > http://errors.yoctoproject.org/Errors/Details/8679/
> > 
> > I have seen this error with eglibc-2.19 and glibc 2.20 as well on x86 and arm as well in cases when using
> > toolchain from sstate and rebuilding glibc with that. I assume this could be  unrelated to glibc upgrade
> > and may be a latent problem. Could be missing dependency on a native tool or some such. I have been attributing it to gold
> > but that just might have been a red herring.
> > 
> > I will see if I can get to reproduce it.
> 
> I tried another build with the three patches from your oe-core contrib
> branch applied. Error report out is:
> 
> http://errors.yoctoproject.org/Errors/Search/?items=10&query=b75fed99f2aa86b49844dd0cf06991767f6f26d3
> 
> i.e. we're still seeing SSE errors in glibc builds. Am I missing some
> patches or something?

The series needs:

 TUNE_CCARGS_x86 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}"
+TUNE_CCARGS_x86-64 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}"

since the x86 override doesn't cover x86_64. I'll queue that and run yet
another build. We do have another poky-tiny issue too:

https://autobuilder.yoctoproject.org/main/builders/poky-tiny/builds/204

Cheers,

RIchard

Re: [yocto] [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Richard Purdie]

On Wed, 2015-02-18 at 11:51 +0000, Richard Purdie wrote:
> On Wed, 2015-02-18 at 01:01 -0800, Khem Raj wrote:
> > OK thats why I am not seeing it on my qemux86 build. 
> > 
> > this leaves us with only one problem - glibc/qemuarm issue
> > 
> > http://errors.yoctoproject.org/Errors/Details/8679/
> > 
> > I have seen this error with eglibc-2.19 and glibc 2.20 as well on x86 and arm as well in cases when using
> > toolchain from sstate and rebuilding glibc with that. I assume this could be  unrelated to glibc upgrade
> > and may be a latent problem. Could be missing dependency on a native tool or some such. I have been attributing it to gold
> > but that just might have been a red herring.
> > 
> > I will see if I can get to reproduce it.
> 
> I tried another build with the three patches from your oe-core contrib
> branch applied. Error report out is:
> 
> http://errors.yoctoproject.org/Errors/Search/?items=10&query=b75fed99f2aa86b49844dd0cf06991767f6f26d3
> 
> i.e. we're still seeing SSE errors in glibc builds. Am I missing some
> patches or something?

The series needs:

 TUNE_CCARGS_x86 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}"
+TUNE_CCARGS_x86-64 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}"

since the x86 override doesn't cover x86_64. I'll queue that and run yet
another build. We do have another poky-tiny issue too:

https://autobuilder.yoctoproject.org/main/builders/poky-tiny/builds/204

Cheers,

RIchard

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Richard Purdie]

On Wed, 2015-02-18 at 11:51 +0000, Richard Purdie wrote:
> On Wed, 2015-02-18 at 01:01 -0800, Khem Raj wrote:
> > OK thats why I am not seeing it on my qemux86 build. 
> > 
> > this leaves us with only one problem - glibc/qemuarm issue
> > 
> > http://errors.yoctoproject.org/Errors/Details/8679/
> > 
> > I have seen this error with eglibc-2.19 and glibc 2.20 as well on x86 and arm as well in cases when using
> > toolchain from sstate and rebuilding glibc with that. I assume this could be  unrelated to glibc upgrade
> > and may be a latent problem. Could be missing dependency on a native tool or some such. I have been attributing it to gold
> > but that just might have been a red herring.
> > 
> > I will see if I can get to reproduce it.
> 
> I tried another build with the three patches from your oe-core contrib
> branch applied. Error report out is:
> 
> http://errors.yoctoproject.org/Errors/Search/?items=10&query=b75fed99f2aa86b49844dd0cf06991767f6f26d3
> 
> i.e. we're still seeing SSE errors in glibc builds. Am I missing some
> patches or something?

The series needs:

 TUNE_CCARGS_x86 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}"
+TUNE_CCARGS_x86-64 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}"

since the x86 override doesn't cover x86_64. I'll queue that and run yet
another build. We do have another poky-tiny issue too:

https://autobuilder.yoctoproject.org/main/builders/poky-tiny/builds/204

Cheers,

RIchard

Re: [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

> On Feb 18, 2015, at 5:06 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> 
> On Wed, 2015-02-18 at 11:51 +0000, Richard Purdie wrote:
>> On Wed, 2015-02-18 at 01:01 -0800, Khem Raj wrote:
>>> OK thats why I am not seeing it on my qemux86 build. 
>>> 
>>> this leaves us with only one problem - glibc/qemuarm issue
>>> 
>>> http://errors.yoctoproject.org/Errors/Details/8679/
>>> 
>>> I have seen this error with eglibc-2.19 and glibc 2.20 as well on x86 and arm as well in cases when using
>>> toolchain from sstate and rebuilding glibc with that. I assume this could be  unrelated to glibc upgrade
>>> and may be a latent problem. Could be missing dependency on a native tool or some such. I have been attributing it to gold
>>> but that just might have been a red herring.
>>> 
>>> I will see if I can get to reproduce it.
>> 
>> I tried another build with the three patches from your oe-core contrib
>> branch applied. Error report out is:
>> 
>> http://errors.yoctoproject.org/Errors/Search/?items=10&query=b75fed99f2aa86b49844dd0cf06991767f6f26d3
>> 
>> i.e. we're still seeing SSE errors in glibc builds. Am I missing some
>> patches or something?
> 
> The series needs:
> 
> TUNE_CCARGS_x86 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}"
> +TUNE_CCARGS_x86-64 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}”
> 

hmmm I assumed x86 was common across 32bit and 64bit x86 but seems not so I replaced the old patch instead of appending it 


> since the x86 override doesn't cover x86_64. I'll queue that and run yet
> another build. We do have another poky-tiny issue too:
> 
> https://autobuilder.yoctoproject.org/main/builders/poky-tiny/builds/204
> 

OK. I am creating a local config to use tiny config for libc and weed out remaining build issues for tiny config 

> Cheers,
> 
> RIchard

Re: [yocto] [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

> On Feb 18, 2015, at 5:06 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> 
> On Wed, 2015-02-18 at 11:51 +0000, Richard Purdie wrote:
>> On Wed, 2015-02-18 at 01:01 -0800, Khem Raj wrote:
>>> OK thats why I am not seeing it on my qemux86 build. 
>>> 
>>> this leaves us with only one problem - glibc/qemuarm issue
>>> 
>>> http://errors.yoctoproject.org/Errors/Details/8679/
>>> 
>>> I have seen this error with eglibc-2.19 and glibc 2.20 as well on x86 and arm as well in cases when using
>>> toolchain from sstate and rebuilding glibc with that. I assume this could be  unrelated to glibc upgrade
>>> and may be a latent problem. Could be missing dependency on a native tool or some such. I have been attributing it to gold
>>> but that just might have been a red herring.
>>> 
>>> I will see if I can get to reproduce it.
>> 
>> I tried another build with the three patches from your oe-core contrib
>> branch applied. Error report out is:
>> 
>> http://errors.yoctoproject.org/Errors/Search/?items=10&query=b75fed99f2aa86b49844dd0cf06991767f6f26d3
>> 
>> i.e. we're still seeing SSE errors in glibc builds. Am I missing some
>> patches or something?
> 
> The series needs:
> 
> TUNE_CCARGS_x86 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}"
> +TUNE_CCARGS_x86-64 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}”
> 

hmmm I assumed x86 was common across 32bit and 64bit x86 but seems not so I replaced the old patch instead of appending it 


> since the x86 override doesn't cover x86_64. I'll queue that and run yet
> another build. We do have another poky-tiny issue too:
> 
> https://autobuilder.yoctoproject.org/main/builders/poky-tiny/builds/204
> 

OK. I am creating a local config to use tiny config for libc and weed out remaining build issues for tiny config 

> Cheers,
> 
> RIchard

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

> On Feb 18, 2015, at 5:06 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> 
> On Wed, 2015-02-18 at 11:51 +0000, Richard Purdie wrote:
>> On Wed, 2015-02-18 at 01:01 -0800, Khem Raj wrote:
>>> OK thats why I am not seeing it on my qemux86 build. 
>>> 
>>> this leaves us with only one problem - glibc/qemuarm issue
>>> 
>>> http://errors.yoctoproject.org/Errors/Details/8679/
>>> 
>>> I have seen this error with eglibc-2.19 and glibc 2.20 as well on x86 and arm as well in cases when using
>>> toolchain from sstate and rebuilding glibc with that. I assume this could be  unrelated to glibc upgrade
>>> and may be a latent problem. Could be missing dependency on a native tool or some such. I have been attributing it to gold
>>> but that just might have been a red herring.
>>> 
>>> I will see if I can get to reproduce it.
>> 
>> I tried another build with the three patches from your oe-core contrib
>> branch applied. Error report out is:
>> 
>> http://errors.yoctoproject.org/Errors/Search/?items=10&query=b75fed99f2aa86b49844dd0cf06991767f6f26d3
>> 
>> i.e. we're still seeing SSE errors in glibc builds. Am I missing some
>> patches or something?
> 
> The series needs:
> 
> TUNE_CCARGS_x86 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}"
> +TUNE_CCARGS_x86-64 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}”
> 

hmmm I assumed x86 was common across 32bit and 64bit x86 but seems not so I replaced the old patch instead of appending it 


> since the x86 override doesn't cover x86_64. I'll queue that and run yet
> another build. We do have another poky-tiny issue too:
> 
> https://autobuilder.yoctoproject.org/main/builders/poky-tiny/builds/204
> 

OK. I am creating a local config to use tiny config for libc and weed out remaining build issues for tiny config 

> Cheers,
> 
> RIchard

Re: [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Richard Purdie]

On Wed, 2015-02-18 at 10:38 -0800, Khem Raj wrote:
> > On Feb 18, 2015, at 5:06 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> > On Wed, 2015-02-18 at 11:51 +0000, Richard Purdie wrote:
> >> On Wed, 2015-02-18 at 01:01 -0800, Khem Raj wrote:
> > The series needs:
> > 
> > TUNE_CCARGS_x86 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}"
> > +TUNE_CCARGS_x86-64 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}”
> > 
> 
> hmmm I assumed x86 was common across 32bit and 64bit x86 but seems not so I replaced the old patch instead of appending it 

Thanks, I'll update the patch for the next round.

> 
> > since the x86 override doesn't cover x86_64. I'll queue that and run yet
> > another build. We do have another poky-tiny issue too:
> > 
> > https://autobuilder.yoctoproject.org/main/builders/poky-tiny/builds/204
> > 
> 
> OK. I am creating a local config to use tiny config for libc and weed out remaining build issues for tiny config 

Cool, thanks.

The next build is in progress and looking greener than the last. Next up
it appears we still have multilib issues:

https://autobuilder.yoctoproject.org/main/builders/nightly-multilib/builds/201

There is a possibility this "from sstate" build may have run into a
problem with sstate but something looks to be wrong with glibc in some
regard.

Cheers,

Richard

Re: [yocto] [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Richard Purdie]

On Wed, 2015-02-18 at 10:38 -0800, Khem Raj wrote:
> > On Feb 18, 2015, at 5:06 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> > On Wed, 2015-02-18 at 11:51 +0000, Richard Purdie wrote:
> >> On Wed, 2015-02-18 at 01:01 -0800, Khem Raj wrote:
> > The series needs:
> > 
> > TUNE_CCARGS_x86 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}"
> > +TUNE_CCARGS_x86-64 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}”
> > 
> 
> hmmm I assumed x86 was common across 32bit and 64bit x86 but seems not so I replaced the old patch instead of appending it 

Thanks, I'll update the patch for the next round.

> 
> > since the x86 override doesn't cover x86_64. I'll queue that and run yet
> > another build. We do have another poky-tiny issue too:
> > 
> > https://autobuilder.yoctoproject.org/main/builders/poky-tiny/builds/204
> > 
> 
> OK. I am creating a local config to use tiny config for libc and weed out remaining build issues for tiny config 

Cool, thanks.

The next build is in progress and looking greener than the last. Next up
it appears we still have multilib issues:

https://autobuilder.yoctoproject.org/main/builders/nightly-multilib/builds/201

There is a possibility this "from sstate" build may have run into a
problem with sstate but something looks to be wrong with glibc in some
regard.

Cheers,

Richard

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Richard Purdie]

On Wed, 2015-02-18 at 10:38 -0800, Khem Raj wrote:
> > On Feb 18, 2015, at 5:06 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> > On Wed, 2015-02-18 at 11:51 +0000, Richard Purdie wrote:
> >> On Wed, 2015-02-18 at 01:01 -0800, Khem Raj wrote:
> > The series needs:
> > 
> > TUNE_CCARGS_x86 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}"
> > +TUNE_CCARGS_x86-64 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}”
> > 
> 
> hmmm I assumed x86 was common across 32bit and 64bit x86 but seems not so I replaced the old patch instead of appending it 

Thanks, I'll update the patch for the next round.

> 
> > since the x86 override doesn't cover x86_64. I'll queue that and run yet
> > another build. We do have another poky-tiny issue too:
> > 
> > https://autobuilder.yoctoproject.org/main/builders/poky-tiny/builds/204
> > 
> 
> OK. I am creating a local config to use tiny config for libc and weed out remaining build issues for tiny config 

Cool, thanks.

The next build is in progress and looking greener than the last. Next up
it appears we still have multilib issues:

https://autobuilder.yoctoproject.org/main/builders/nightly-multilib/builds/201

There is a possibility this "from sstate" build may have run into a
problem with sstate but something looks to be wrong with glibc in some
regard.

Cheers,

Richard

Re: [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

> On Feb 18, 2015, at 1:41 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> 
> On Wed, 2015-02-18 at 10:38 -0800, Khem Raj wrote:
>>> On Feb 18, 2015, at 5:06 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
>>> On Wed, 2015-02-18 at 11:51 +0000, Richard Purdie wrote:
>>>> On Wed, 2015-02-18 at 01:01 -0800, Khem Raj wrote:
>>> The series needs:
>>> 
>>> TUNE_CCARGS_x86 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}"
>>> +TUNE_CCARGS_x86-64 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}”
>>> 
>> 
>> hmmm I assumed x86 was common across 32bit and 64bit x86 but seems not so I replaced the old patch instead of appending it 
> 
> Thanks, I'll update the patch for the next round.
> 
>> 
>>> since the x86 override doesn't cover x86_64. I'll queue that and run yet
>>> another build. We do have another poky-tiny issue too:
>>> 
>>> https://autobuilder.yoctoproject.org/main/builders/poky-tiny/builds/204
>>> 
>> 
>> OK. I am creating a local config to use tiny config for libc and weed out remaining build issues for tiny config 
> 
> Cool, thanks.
> 
> The next build is in progress and looking greener than the last. Next up
> it appears we still have multilib issues:

I have pushed a new patchset to same branch. That should fix the tiny build issues.

> 
> https://autobuilder.yoctoproject.org/main/builders/nightly-multilib/builds/201


| dcigettext.c: In function '__dcigettext':
| dcigettext.c:856:30: error: '__libc_setlocale_lock' undeclared (first use in this function)
|         __libc_rwlock_unlock (__libc_setlocale_lock);

is what I see.

I have fixed this in the latest patchset. So lets start with the new patchset.


> There is a possibility this "from sstate" build may have run into a
> problem with sstate but something looks to be wrong with glibc in some
> regard.
> 
> Cheers,
> 
> Richard
> 

Re: [yocto] [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

> On Feb 18, 2015, at 1:41 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> 
> On Wed, 2015-02-18 at 10:38 -0800, Khem Raj wrote:
>>> On Feb 18, 2015, at 5:06 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
>>> On Wed, 2015-02-18 at 11:51 +0000, Richard Purdie wrote:
>>>> On Wed, 2015-02-18 at 01:01 -0800, Khem Raj wrote:
>>> The series needs:
>>> 
>>> TUNE_CCARGS_x86 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}"
>>> +TUNE_CCARGS_x86-64 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}”
>>> 
>> 
>> hmmm I assumed x86 was common across 32bit and 64bit x86 but seems not so I replaced the old patch instead of appending it 
> 
> Thanks, I'll update the patch for the next round.
> 
>> 
>>> since the x86 override doesn't cover x86_64. I'll queue that and run yet
>>> another build. We do have another poky-tiny issue too:
>>> 
>>> https://autobuilder.yoctoproject.org/main/builders/poky-tiny/builds/204
>>> 
>> 
>> OK. I am creating a local config to use tiny config for libc and weed out remaining build issues for tiny config 
> 
> Cool, thanks.
> 
> The next build is in progress and looking greener than the last. Next up
> it appears we still have multilib issues:

I have pushed a new patchset to same branch. That should fix the tiny build issues.

> 
> https://autobuilder.yoctoproject.org/main/builders/nightly-multilib/builds/201


| dcigettext.c: In function '__dcigettext':
| dcigettext.c:856:30: error: '__libc_setlocale_lock' undeclared (first use in this function)
|         __libc_rwlock_unlock (__libc_setlocale_lock);

is what I see.

I have fixed this in the latest patchset. So lets start with the new patchset.


> There is a possibility this "from sstate" build may have run into a
> problem with sstate but something looks to be wrong with glibc in some
> regard.
> 
> Cheers,
> 
> Richard
> 

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

> On Feb 18, 2015, at 1:41 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> 
> On Wed, 2015-02-18 at 10:38 -0800, Khem Raj wrote:
>>> On Feb 18, 2015, at 5:06 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
>>> On Wed, 2015-02-18 at 11:51 +0000, Richard Purdie wrote:
>>>> On Wed, 2015-02-18 at 01:01 -0800, Khem Raj wrote:
>>> The series needs:
>>> 
>>> TUNE_CCARGS_x86 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}"
>>> +TUNE_CCARGS_x86-64 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}”
>>> 
>> 
>> hmmm I assumed x86 was common across 32bit and 64bit x86 but seems not so I replaced the old patch instead of appending it 
> 
> Thanks, I'll update the patch for the next round.
> 
>> 
>>> since the x86 override doesn't cover x86_64. I'll queue that and run yet
>>> another build. We do have another poky-tiny issue too:
>>> 
>>> https://autobuilder.yoctoproject.org/main/builders/poky-tiny/builds/204
>>> 
>> 
>> OK. I am creating a local config to use tiny config for libc and weed out remaining build issues for tiny config 
> 
> Cool, thanks.
> 
> The next build is in progress and looking greener than the last. Next up
> it appears we still have multilib issues:

I have pushed a new patchset to same branch. That should fix the tiny build issues.

> 
> https://autobuilder.yoctoproject.org/main/builders/nightly-multilib/builds/201


| dcigettext.c: In function '__dcigettext':
| dcigettext.c:856:30: error: '__libc_setlocale_lock' undeclared (first use in this function)
|         __libc_rwlock_unlock (__libc_setlocale_lock);

is what I see.

I have fixed this in the latest patchset. So lets start with the new patchset.


> There is a possibility this "from sstate" build may have run into a
> problem with sstate but something looks to be wrong with glibc in some
> regard.
> 
> Cheers,
> 
> Richard
> 

Re: [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

> On Feb 18, 2015, at 4:23 PM, Khem Raj <raj.khem@gmail.com> wrote:
> 
> 
>> On Feb 18, 2015, at 1:41 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
>> 
>> On Wed, 2015-02-18 at 10:38 -0800, Khem Raj wrote:
>>>> On Feb 18, 2015, at 5:06 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
>>>> On Wed, 2015-02-18 at 11:51 +0000, Richard Purdie wrote:
>>>>> On Wed, 2015-02-18 at 01:01 -0800, Khem Raj wrote:
>>>> The series needs:
>>>> 
>>>> TUNE_CCARGS_x86 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}"
>>>> +TUNE_CCARGS_x86-64 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}”
>>>> 
>>> 
>>> hmmm I assumed x86 was common across 32bit and 64bit x86 but seems not so I replaced the old patch instead of appending it 
>> 
>> Thanks, I'll update the patch for the next round.
>> 
>>> 
>>>> since the x86 override doesn't cover x86_64. I'll queue that and run yet
>>>> another build. We do have another poky-tiny issue too:
>>>> 
>>>> https://autobuilder.yoctoproject.org/main/builders/poky-tiny/builds/204
>>>> 
>>> 
>>> OK. I am creating a local config to use tiny config for libc and weed out remaining build issues for tiny config 
>> 
>> Cool, thanks.
>> 
>> The next build is in progress and looking greener than the last. Next up
>> it appears we still have multilib issues:
> 
> I have pushed a new patchset to same branch. That should fix the tiny build issues.
> 
>> 
>> https://autobuilder.yoctoproject.org/main/builders/nightly-multilib/builds/201
> 
> 
> | dcigettext.c: In function '__dcigettext':
> | dcigettext.c:856:30: error: '__libc_setlocale_lock' undeclared (first use in this function)
> |         __libc_rwlock_unlock (__libc_setlocale_lock);
> 
> is what I see.
> 
> I have fixed this in the latest patchset. So lets start with the new patchset.
> 

in https://autobuilder.yoctoproject.org/main/builders/nightly-multilib/builds/201/steps/BuildImages/logs/stdio

| make: *** [/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/core2-64-poky-linux/glibc-locale/2.21-r0/locale-tree/usr/lib64/locale/es_HN] Aborted (core dumped)

thats new its probably a crash in localedef.


> 
>> There is a possibility this "from sstate" build may have run into a
>> problem with sstate but something looks to be wrong with glibc in some
>> regard.
>> 
>> Cheers,
>> 
>> Richard
>> 
> 

Re: [yocto] [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

> On Feb 18, 2015, at 4:23 PM, Khem Raj <raj.khem@gmail.com> wrote:
> 
> 
>> On Feb 18, 2015, at 1:41 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
>> 
>> On Wed, 2015-02-18 at 10:38 -0800, Khem Raj wrote:
>>>> On Feb 18, 2015, at 5:06 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
>>>> On Wed, 2015-02-18 at 11:51 +0000, Richard Purdie wrote:
>>>>> On Wed, 2015-02-18 at 01:01 -0800, Khem Raj wrote:
>>>> The series needs:
>>>> 
>>>> TUNE_CCARGS_x86 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}"
>>>> +TUNE_CCARGS_x86-64 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}”
>>>> 
>>> 
>>> hmmm I assumed x86 was common across 32bit and 64bit x86 but seems not so I replaced the old patch instead of appending it 
>> 
>> Thanks, I'll update the patch for the next round.
>> 
>>> 
>>>> since the x86 override doesn't cover x86_64. I'll queue that and run yet
>>>> another build. We do have another poky-tiny issue too:
>>>> 
>>>> https://autobuilder.yoctoproject.org/main/builders/poky-tiny/builds/204
>>>> 
>>> 
>>> OK. I am creating a local config to use tiny config for libc and weed out remaining build issues for tiny config 
>> 
>> Cool, thanks.
>> 
>> The next build is in progress and looking greener than the last. Next up
>> it appears we still have multilib issues:
> 
> I have pushed a new patchset to same branch. That should fix the tiny build issues.
> 
>> 
>> https://autobuilder.yoctoproject.org/main/builders/nightly-multilib/builds/201
> 
> 
> | dcigettext.c: In function '__dcigettext':
> | dcigettext.c:856:30: error: '__libc_setlocale_lock' undeclared (first use in this function)
> |         __libc_rwlock_unlock (__libc_setlocale_lock);
> 
> is what I see.
> 
> I have fixed this in the latest patchset. So lets start with the new patchset.
> 

in https://autobuilder.yoctoproject.org/main/builders/nightly-multilib/builds/201/steps/BuildImages/logs/stdio

| make: *** [/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/core2-64-poky-linux/glibc-locale/2.21-r0/locale-tree/usr/lib64/locale/es_HN] Aborted (core dumped)

thats new its probably a crash in localedef.


> 
>> There is a possibility this "from sstate" build may have run into a
>> problem with sstate but something looks to be wrong with glibc in some
>> regard.
>> 
>> Cheers,
>> 
>> Richard
>> 
> 

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

> On Feb 18, 2015, at 4:23 PM, Khem Raj <raj.khem@gmail.com> wrote:
> 
> 
>> On Feb 18, 2015, at 1:41 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
>> 
>> On Wed, 2015-02-18 at 10:38 -0800, Khem Raj wrote:
>>>> On Feb 18, 2015, at 5:06 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
>>>> On Wed, 2015-02-18 at 11:51 +0000, Richard Purdie wrote:
>>>>> On Wed, 2015-02-18 at 01:01 -0800, Khem Raj wrote:
>>>> The series needs:
>>>> 
>>>> TUNE_CCARGS_x86 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}"
>>>> +TUNE_CCARGS_x86-64 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}”
>>>> 
>>> 
>>> hmmm I assumed x86 was common across 32bit and 64bit x86 but seems not so I replaced the old patch instead of appending it 
>> 
>> Thanks, I'll update the patch for the next round.
>> 
>>> 
>>>> since the x86 override doesn't cover x86_64. I'll queue that and run yet
>>>> another build. We do have another poky-tiny issue too:
>>>> 
>>>> https://autobuilder.yoctoproject.org/main/builders/poky-tiny/builds/204
>>>> 
>>> 
>>> OK. I am creating a local config to use tiny config for libc and weed out remaining build issues for tiny config 
>> 
>> Cool, thanks.
>> 
>> The next build is in progress and looking greener than the last. Next up
>> it appears we still have multilib issues:
> 
> I have pushed a new patchset to same branch. That should fix the tiny build issues.
> 
>> 
>> https://autobuilder.yoctoproject.org/main/builders/nightly-multilib/builds/201
> 
> 
> | dcigettext.c: In function '__dcigettext':
> | dcigettext.c:856:30: error: '__libc_setlocale_lock' undeclared (first use in this function)
> |         __libc_rwlock_unlock (__libc_setlocale_lock);
> 
> is what I see.
> 
> I have fixed this in the latest patchset. So lets start with the new patchset.
> 

in https://autobuilder.yoctoproject.org/main/builders/nightly-multilib/builds/201/steps/BuildImages/logs/stdio

| make: *** [/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/core2-64-poky-linux/glibc-locale/2.21-r0/locale-tree/usr/lib64/locale/es_HN] Aborted (core dumped)

thats new its probably a crash in localedef.


> 
>> There is a possibility this "from sstate" build may have run into a
>> problem with sstate but something looks to be wrong with glibc in some
>> regard.
>> 
>> Cheers,
>> 
>> Richard
>> 
> 

Re: [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

> On Feb 18, 2015, at 4:28 PM, Khem Raj <raj.khem@gmail.com> wrote:
> 
> 
>> On Feb 18, 2015, at 4:23 PM, Khem Raj <raj.khem@gmail.com> wrote:
>> 
>> 
>>> On Feb 18, 2015, at 1:41 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
>>> 
>>> On Wed, 2015-02-18 at 10:38 -0800, Khem Raj wrote:
>>>>> On Feb 18, 2015, at 5:06 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
>>>>> On Wed, 2015-02-18 at 11:51 +0000, Richard Purdie wrote:
>>>>>> On Wed, 2015-02-18 at 01:01 -0800, Khem Raj wrote:
>>>>> The series needs:
>>>>> 
>>>>> TUNE_CCARGS_x86 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}"
>>>>> +TUNE_CCARGS_x86-64 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}”
>>>>> 
>>>> 
>>>> hmmm I assumed x86 was common across 32bit and 64bit x86 but seems not so I replaced the old patch instead of appending it 
>>> 
>>> Thanks, I'll update the patch for the next round.
>>> 
>>>> 
>>>>> since the x86 override doesn't cover x86_64. I'll queue that and run yet
>>>>> another build. We do have another poky-tiny issue too:
>>>>> 
>>>>> https://autobuilder.yoctoproject.org/main/builders/poky-tiny/builds/204
>>>>> 
>>>> 
>>>> OK. I am creating a local config to use tiny config for libc and weed out remaining build issues for tiny config 
>>> 
>>> Cool, thanks.
>>> 
>>> The next build is in progress and looking greener than the last. Next up
>>> it appears we still have multilib issues:
>> 
>> I have pushed a new patchset to same branch. That should fix the tiny build issues.
>> 
>>> 
>>> https://autobuilder.yoctoproject.org/main/builders/nightly-multilib/builds/201
>> 
>> 
>> | dcigettext.c: In function '__dcigettext':
>> | dcigettext.c:856:30: error: '__libc_setlocale_lock' undeclared (first use in this function)
>> |         __libc_rwlock_unlock (__libc_setlocale_lock);
>> 
>> is what I see.
>> 
>> I have fixed this in the latest patchset. So lets start with the new patchset.
>> 
> 
> in https://autobuilder.yoctoproject.org/main/builders/nightly-multilib/builds/201/steps/BuildImages/logs/stdio
> 
> | make: *** [/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/core2-64-poky-linux/glibc-locale/2.21-r0/locale-tree/usr/lib64/locale/es_HN] Aborted (core dumped)
> 
> thats new its probably a crash in localedef.
> 


| checking for i586-pokymllib32-linux-gcc... i586-pokymllib32-linux-gcc -m64 -march=core2 -mtune=core2 -msse3 --sysroot=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/sysroots/lib32-qemux86-64-tcbootstrap
| checking for suffix of object files... configure: error: in `/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/x86-pokymllib32-linux/lib32-glibc-initial/2.21-r0/build-i586-pokymllib32-linux':
| configure: error: cannot compute suffix of object files: cannot compile
| See `config.log' for more details
| WARNING: /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/x86-pokymllib32-linux/lib32-glibc-initial/2.21-r0/temp/run.do_configure.1095:1 exit 1 from
|   /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/x86-pokymllib32-linux/lib32-glibc-initial/2.21-r0/git/configure --host=i586-pokymllib32-linux --build=x86_64-linux --prefix=/usr --without-cvs --disable-sanity-checks --with-headers=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/sysroots/lib32-qemux86-64/usr/include --with-kconfig=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/sysroots/x86_64-linux/usr/bin --enable-hacker-mode --enable-addons
| ERROR: Function failed: do_configure (log file is located at /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/x86-pokymllib32-linux/lib32-glibc-initial/2.21-r0/temp/log.do_configure.1095)
NOTE: recipe lib32-glibc-initial-2.21-r0: task do_configure: Failed


Can you post config.log ? here

I don’t have multilib setup so hard to reproduce it here

Re: [yocto] [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

> On Feb 18, 2015, at 4:28 PM, Khem Raj <raj.khem@gmail.com> wrote:
> 
> 
>> On Feb 18, 2015, at 4:23 PM, Khem Raj <raj.khem@gmail.com> wrote:
>> 
>> 
>>> On Feb 18, 2015, at 1:41 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
>>> 
>>> On Wed, 2015-02-18 at 10:38 -0800, Khem Raj wrote:
>>>>> On Feb 18, 2015, at 5:06 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
>>>>> On Wed, 2015-02-18 at 11:51 +0000, Richard Purdie wrote:
>>>>>> On Wed, 2015-02-18 at 01:01 -0800, Khem Raj wrote:
>>>>> The series needs:
>>>>> 
>>>>> TUNE_CCARGS_x86 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}"
>>>>> +TUNE_CCARGS_x86-64 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}”
>>>>> 
>>>> 
>>>> hmmm I assumed x86 was common across 32bit and 64bit x86 but seems not so I replaced the old patch instead of appending it 
>>> 
>>> Thanks, I'll update the patch for the next round.
>>> 
>>>> 
>>>>> since the x86 override doesn't cover x86_64. I'll queue that and run yet
>>>>> another build. We do have another poky-tiny issue too:
>>>>> 
>>>>> https://autobuilder.yoctoproject.org/main/builders/poky-tiny/builds/204
>>>>> 
>>>> 
>>>> OK. I am creating a local config to use tiny config for libc and weed out remaining build issues for tiny config 
>>> 
>>> Cool, thanks.
>>> 
>>> The next build is in progress and looking greener than the last. Next up
>>> it appears we still have multilib issues:
>> 
>> I have pushed a new patchset to same branch. That should fix the tiny build issues.
>> 
>>> 
>>> https://autobuilder.yoctoproject.org/main/builders/nightly-multilib/builds/201
>> 
>> 
>> | dcigettext.c: In function '__dcigettext':
>> | dcigettext.c:856:30: error: '__libc_setlocale_lock' undeclared (first use in this function)
>> |         __libc_rwlock_unlock (__libc_setlocale_lock);
>> 
>> is what I see.
>> 
>> I have fixed this in the latest patchset. So lets start with the new patchset.
>> 
> 
> in https://autobuilder.yoctoproject.org/main/builders/nightly-multilib/builds/201/steps/BuildImages/logs/stdio
> 
> | make: *** [/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/core2-64-poky-linux/glibc-locale/2.21-r0/locale-tree/usr/lib64/locale/es_HN] Aborted (core dumped)
> 
> thats new its probably a crash in localedef.
> 


| checking for i586-pokymllib32-linux-gcc... i586-pokymllib32-linux-gcc -m64 -march=core2 -mtune=core2 -msse3 --sysroot=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/sysroots/lib32-qemux86-64-tcbootstrap
| checking for suffix of object files... configure: error: in `/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/x86-pokymllib32-linux/lib32-glibc-initial/2.21-r0/build-i586-pokymllib32-linux':
| configure: error: cannot compute suffix of object files: cannot compile
| See `config.log' for more details
| WARNING: /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/x86-pokymllib32-linux/lib32-glibc-initial/2.21-r0/temp/run.do_configure.1095:1 exit 1 from
|   /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/x86-pokymllib32-linux/lib32-glibc-initial/2.21-r0/git/configure --host=i586-pokymllib32-linux --build=x86_64-linux --prefix=/usr --without-cvs --disable-sanity-checks --with-headers=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/sysroots/lib32-qemux86-64/usr/include --with-kconfig=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/sysroots/x86_64-linux/usr/bin --enable-hacker-mode --enable-addons
| ERROR: Function failed: do_configure (log file is located at /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/x86-pokymllib32-linux/lib32-glibc-initial/2.21-r0/temp/log.do_configure.1095)
NOTE: recipe lib32-glibc-initial-2.21-r0: task do_configure: Failed


Can you post config.log ? here

I don’t have multilib setup so hard to reproduce it here

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

> On Feb 18, 2015, at 4:28 PM, Khem Raj <raj.khem@gmail.com> wrote:
> 
> 
>> On Feb 18, 2015, at 4:23 PM, Khem Raj <raj.khem@gmail.com> wrote:
>> 
>> 
>>> On Feb 18, 2015, at 1:41 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
>>> 
>>> On Wed, 2015-02-18 at 10:38 -0800, Khem Raj wrote:
>>>>> On Feb 18, 2015, at 5:06 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
>>>>> On Wed, 2015-02-18 at 11:51 +0000, Richard Purdie wrote:
>>>>>> On Wed, 2015-02-18 at 01:01 -0800, Khem Raj wrote:
>>>>> The series needs:
>>>>> 
>>>>> TUNE_CCARGS_x86 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}"
>>>>> +TUNE_CCARGS_x86-64 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}”
>>>>> 
>>>> 
>>>> hmmm I assumed x86 was common across 32bit and 64bit x86 but seems not so I replaced the old patch instead of appending it 
>>> 
>>> Thanks, I'll update the patch for the next round.
>>> 
>>>> 
>>>>> since the x86 override doesn't cover x86_64. I'll queue that and run yet
>>>>> another build. We do have another poky-tiny issue too:
>>>>> 
>>>>> https://autobuilder.yoctoproject.org/main/builders/poky-tiny/builds/204
>>>>> 
>>>> 
>>>> OK. I am creating a local config to use tiny config for libc and weed out remaining build issues for tiny config 
>>> 
>>> Cool, thanks.
>>> 
>>> The next build is in progress and looking greener than the last. Next up
>>> it appears we still have multilib issues:
>> 
>> I have pushed a new patchset to same branch. That should fix the tiny build issues.
>> 
>>> 
>>> https://autobuilder.yoctoproject.org/main/builders/nightly-multilib/builds/201
>> 
>> 
>> | dcigettext.c: In function '__dcigettext':
>> | dcigettext.c:856:30: error: '__libc_setlocale_lock' undeclared (first use in this function)
>> |         __libc_rwlock_unlock (__libc_setlocale_lock);
>> 
>> is what I see.
>> 
>> I have fixed this in the latest patchset. So lets start with the new patchset.
>> 
> 
> in https://autobuilder.yoctoproject.org/main/builders/nightly-multilib/builds/201/steps/BuildImages/logs/stdio
> 
> | make: *** [/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/core2-64-poky-linux/glibc-locale/2.21-r0/locale-tree/usr/lib64/locale/es_HN] Aborted (core dumped)
> 
> thats new its probably a crash in localedef.
> 


| checking for i586-pokymllib32-linux-gcc... i586-pokymllib32-linux-gcc -m64 -march=core2 -mtune=core2 -msse3 --sysroot=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/sysroots/lib32-qemux86-64-tcbootstrap
| checking for suffix of object files... configure: error: in `/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/x86-pokymllib32-linux/lib32-glibc-initial/2.21-r0/build-i586-pokymllib32-linux':
| configure: error: cannot compute suffix of object files: cannot compile
| See `config.log' for more details
| WARNING: /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/x86-pokymllib32-linux/lib32-glibc-initial/2.21-r0/temp/run.do_configure.1095:1 exit 1 from
|   /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/x86-pokymllib32-linux/lib32-glibc-initial/2.21-r0/git/configure --host=i586-pokymllib32-linux --build=x86_64-linux --prefix=/usr --without-cvs --disable-sanity-checks --with-headers=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/sysroots/lib32-qemux86-64/usr/include --with-kconfig=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/sysroots/x86_64-linux/usr/bin --enable-hacker-mode --enable-addons
| ERROR: Function failed: do_configure (log file is located at /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/x86-pokymllib32-linux/lib32-glibc-initial/2.21-r0/temp/log.do_configure.1095)
NOTE: recipe lib32-glibc-initial-2.21-r0: task do_configure: Failed


Can you post config.log ? here

I don’t have multilib setup so hard to reproduce it here

Re: [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

> On Feb 18, 2015, at 4:31 PM, Khem Raj <raj.khem@gmail.com> wrote:
> 
> 
>> On Feb 18, 2015, at 4:28 PM, Khem Raj <raj.khem@gmail.com> wrote:
>> 
>> 
>>> On Feb 18, 2015, at 4:23 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>> 
>>> 
>>>> On Feb 18, 2015, at 1:41 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
>>>> 
>>>> On Wed, 2015-02-18 at 10:38 -0800, Khem Raj wrote:
>>>>>> On Feb 18, 2015, at 5:06 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
>>>>>> On Wed, 2015-02-18 at 11:51 +0000, Richard Purdie wrote:
>>>>>>> On Wed, 2015-02-18 at 01:01 -0800, Khem Raj wrote:
>>>>>> The series needs:
>>>>>> 
>>>>>> TUNE_CCARGS_x86 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}"
>>>>>> +TUNE_CCARGS_x86-64 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}”
>>>>>> 
>>>>> 
>>>>> hmmm I assumed x86 was common across 32bit and 64bit x86 but seems not so I replaced the old patch instead of appending it 
>>>> 
>>>> Thanks, I'll update the patch for the next round.
>>>> 
>>>>> 
>>>>>> since the x86 override doesn't cover x86_64. I'll queue that and run yet
>>>>>> another build. We do have another poky-tiny issue too:
>>>>>> 
>>>>>> https://autobuilder.yoctoproject.org/main/builders/poky-tiny/builds/204
>>>>>> 
>>>>> 
>>>>> OK. I am creating a local config to use tiny config for libc and weed out remaining build issues for tiny config 
>>>> 
>>>> Cool, thanks.
>>>> 
>>>> The next build is in progress and looking greener than the last. Next up
>>>> it appears we still have multilib issues:
>>> 
>>> I have pushed a new patchset to same branch. That should fix the tiny build issues.
>>> 
>>>> 
>>>> https://autobuilder.yoctoproject.org/main/builders/nightly-multilib/builds/201
>>> 
>>> 
>>> | dcigettext.c: In function '__dcigettext':
>>> | dcigettext.c:856:30: error: '__libc_setlocale_lock' undeclared (first use in this function)
>>> |         __libc_rwlock_unlock (__libc_setlocale_lock);
>>> 
>>> is what I see.
>>> 
>>> I have fixed this in the latest patchset. So lets start with the new patchset.
>>> 
>> 
>> in https://autobuilder.yoctoproject.org/main/builders/nightly-multilib/builds/201/steps/BuildImages/logs/stdio
>> 
>> | make: *** [/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/core2-64-poky-linux/glibc-locale/2.21-r0/locale-tree/usr/lib64/locale/es_HN] Aborted (core dumped)
>> 
>> thats new its probably a crash in localedef.
>> 
> 
> 
> | checking for i586-pokymllib32-linux-gcc... i586-pokymllib32-linux-gcc -m64 -march=core2 -mtune=core2 -msse3 --sysroot=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/sysroots/lib32-qemux86-64-tcbootstrap
> | checking for suffix of object files... configure: error: in `/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/x86-pokymllib32-linux/lib32-glibc-initial/2.21-r0/build-i586-pokymllib32-linux':
> | configure: error: cannot compute suffix of object files: cannot compile
> | See `config.log' for more details
> | WARNING: /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/x86-pokymllib32-linux/lib32-glibc-initial/2.21-r0/temp/run.do_configure.1095:1 exit 1 from
> |   /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/x86-pokymllib32-linux/lib32-glibc-initial/2.21-r0/git/configure --host=i586-pokymllib32-linux --build=x86_64-linux --prefix=/usr --without-cvs --disable-sanity-checks --with-headers=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/sysroots/lib32-qemux86-64/usr/include --with-kconfig=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/sysroots/x86_64-linux/usr/bin --enable-hacker-mode --enable-addons
> | ERROR: Function failed: do_configure (log file is located at /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/x86-pokymllib32-linux/lib32-glibc-initial/2.21-r0/temp/log.do_configure.1095)
> NOTE: recipe lib32-glibc-initial-2.21-r0: task do_configure: Failed
> 
> 
> Can you post config.log ? here
> 
> I don’t have multilib setup so hard to reproduce it here
> 


Nevermind. I think I understood the problem. This tweaking of TUNE_CCARGS is resulting in premature evaluation in case of multilib and we are ending up with 64bit options when using 32bit gcc
Now, I have fixed this by patching glibc itself. see

http://git.openembedded.org/openembedded-core-contrib/tree/meta/recipes-core/glibc/glibc/0001-When-disabling-SSE-also-make-sure-that-fpmath-is-not.patch?h=kraj/gcc-glibc-upgrade

as a result all CCARGS patches aren’t needed any longer.

This should be good with multilib now. Please try the latest patchset.

Thinking of TUNE_CCARGS pruning, I think mips multilib will have similar issues, probably that flag should also move into glibc build system but I will leave that for another day

Re: [yocto] [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

> On Feb 18, 2015, at 4:31 PM, Khem Raj <raj.khem@gmail.com> wrote:
> 
> 
>> On Feb 18, 2015, at 4:28 PM, Khem Raj <raj.khem@gmail.com> wrote:
>> 
>> 
>>> On Feb 18, 2015, at 4:23 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>> 
>>> 
>>>> On Feb 18, 2015, at 1:41 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
>>>> 
>>>> On Wed, 2015-02-18 at 10:38 -0800, Khem Raj wrote:
>>>>>> On Feb 18, 2015, at 5:06 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
>>>>>> On Wed, 2015-02-18 at 11:51 +0000, Richard Purdie wrote:
>>>>>>> On Wed, 2015-02-18 at 01:01 -0800, Khem Raj wrote:
>>>>>> The series needs:
>>>>>> 
>>>>>> TUNE_CCARGS_x86 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}"
>>>>>> +TUNE_CCARGS_x86-64 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}”
>>>>>> 
>>>>> 
>>>>> hmmm I assumed x86 was common across 32bit and 64bit x86 but seems not so I replaced the old patch instead of appending it 
>>>> 
>>>> Thanks, I'll update the patch for the next round.
>>>> 
>>>>> 
>>>>>> since the x86 override doesn't cover x86_64. I'll queue that and run yet
>>>>>> another build. We do have another poky-tiny issue too:
>>>>>> 
>>>>>> https://autobuilder.yoctoproject.org/main/builders/poky-tiny/builds/204
>>>>>> 
>>>>> 
>>>>> OK. I am creating a local config to use tiny config for libc and weed out remaining build issues for tiny config 
>>>> 
>>>> Cool, thanks.
>>>> 
>>>> The next build is in progress and looking greener than the last. Next up
>>>> it appears we still have multilib issues:
>>> 
>>> I have pushed a new patchset to same branch. That should fix the tiny build issues.
>>> 
>>>> 
>>>> https://autobuilder.yoctoproject.org/main/builders/nightly-multilib/builds/201
>>> 
>>> 
>>> | dcigettext.c: In function '__dcigettext':
>>> | dcigettext.c:856:30: error: '__libc_setlocale_lock' undeclared (first use in this function)
>>> |         __libc_rwlock_unlock (__libc_setlocale_lock);
>>> 
>>> is what I see.
>>> 
>>> I have fixed this in the latest patchset. So lets start with the new patchset.
>>> 
>> 
>> in https://autobuilder.yoctoproject.org/main/builders/nightly-multilib/builds/201/steps/BuildImages/logs/stdio
>> 
>> | make: *** [/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/core2-64-poky-linux/glibc-locale/2.21-r0/locale-tree/usr/lib64/locale/es_HN] Aborted (core dumped)
>> 
>> thats new its probably a crash in localedef.
>> 
> 
> 
> | checking for i586-pokymllib32-linux-gcc... i586-pokymllib32-linux-gcc -m64 -march=core2 -mtune=core2 -msse3 --sysroot=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/sysroots/lib32-qemux86-64-tcbootstrap
> | checking for suffix of object files... configure: error: in `/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/x86-pokymllib32-linux/lib32-glibc-initial/2.21-r0/build-i586-pokymllib32-linux':
> | configure: error: cannot compute suffix of object files: cannot compile
> | See `config.log' for more details
> | WARNING: /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/x86-pokymllib32-linux/lib32-glibc-initial/2.21-r0/temp/run.do_configure.1095:1 exit 1 from
> |   /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/x86-pokymllib32-linux/lib32-glibc-initial/2.21-r0/git/configure --host=i586-pokymllib32-linux --build=x86_64-linux --prefix=/usr --without-cvs --disable-sanity-checks --with-headers=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/sysroots/lib32-qemux86-64/usr/include --with-kconfig=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/sysroots/x86_64-linux/usr/bin --enable-hacker-mode --enable-addons
> | ERROR: Function failed: do_configure (log file is located at /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/x86-pokymllib32-linux/lib32-glibc-initial/2.21-r0/temp/log.do_configure.1095)
> NOTE: recipe lib32-glibc-initial-2.21-r0: task do_configure: Failed
> 
> 
> Can you post config.log ? here
> 
> I don’t have multilib setup so hard to reproduce it here
> 


Nevermind. I think I understood the problem. This tweaking of TUNE_CCARGS is resulting in premature evaluation in case of multilib and we are ending up with 64bit options when using 32bit gcc
Now, I have fixed this by patching glibc itself. see

http://git.openembedded.org/openembedded-core-contrib/tree/meta/recipes-core/glibc/glibc/0001-When-disabling-SSE-also-make-sure-that-fpmath-is-not.patch?h=kraj/gcc-glibc-upgrade

as a result all CCARGS patches aren’t needed any longer.

This should be good with multilib now. Please try the latest patchset.

Thinking of TUNE_CCARGS pruning, I think mips multilib will have similar issues, probably that flag should also move into glibc build system but I will leave that for another day

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

> On Feb 18, 2015, at 4:31 PM, Khem Raj <raj.khem@gmail.com> wrote:
> 
> 
>> On Feb 18, 2015, at 4:28 PM, Khem Raj <raj.khem@gmail.com> wrote:
>> 
>> 
>>> On Feb 18, 2015, at 4:23 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>> 
>>> 
>>>> On Feb 18, 2015, at 1:41 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
>>>> 
>>>> On Wed, 2015-02-18 at 10:38 -0800, Khem Raj wrote:
>>>>>> On Feb 18, 2015, at 5:06 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
>>>>>> On Wed, 2015-02-18 at 11:51 +0000, Richard Purdie wrote:
>>>>>>> On Wed, 2015-02-18 at 01:01 -0800, Khem Raj wrote:
>>>>>> The series needs:
>>>>>> 
>>>>>> TUNE_CCARGS_x86 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}"
>>>>>> +TUNE_CCARGS_x86-64 := "${@oe_filter_out('-mfpmath=sse', '${TUNE_CCARGS}', d)}”
>>>>>> 
>>>>> 
>>>>> hmmm I assumed x86 was common across 32bit and 64bit x86 but seems not so I replaced the old patch instead of appending it 
>>>> 
>>>> Thanks, I'll update the patch for the next round.
>>>> 
>>>>> 
>>>>>> since the x86 override doesn't cover x86_64. I'll queue that and run yet
>>>>>> another build. We do have another poky-tiny issue too:
>>>>>> 
>>>>>> https://autobuilder.yoctoproject.org/main/builders/poky-tiny/builds/204
>>>>>> 
>>>>> 
>>>>> OK. I am creating a local config to use tiny config for libc and weed out remaining build issues for tiny config 
>>>> 
>>>> Cool, thanks.
>>>> 
>>>> The next build is in progress and looking greener than the last. Next up
>>>> it appears we still have multilib issues:
>>> 
>>> I have pushed a new patchset to same branch. That should fix the tiny build issues.
>>> 
>>>> 
>>>> https://autobuilder.yoctoproject.org/main/builders/nightly-multilib/builds/201
>>> 
>>> 
>>> | dcigettext.c: In function '__dcigettext':
>>> | dcigettext.c:856:30: error: '__libc_setlocale_lock' undeclared (first use in this function)
>>> |         __libc_rwlock_unlock (__libc_setlocale_lock);
>>> 
>>> is what I see.
>>> 
>>> I have fixed this in the latest patchset. So lets start with the new patchset.
>>> 
>> 
>> in https://autobuilder.yoctoproject.org/main/builders/nightly-multilib/builds/201/steps/BuildImages/logs/stdio
>> 
>> | make: *** [/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/core2-64-poky-linux/glibc-locale/2.21-r0/locale-tree/usr/lib64/locale/es_HN] Aborted (core dumped)
>> 
>> thats new its probably a crash in localedef.
>> 
> 
> 
> | checking for i586-pokymllib32-linux-gcc... i586-pokymllib32-linux-gcc -m64 -march=core2 -mtune=core2 -msse3 --sysroot=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/sysroots/lib32-qemux86-64-tcbootstrap
> | checking for suffix of object files... configure: error: in `/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/x86-pokymllib32-linux/lib32-glibc-initial/2.21-r0/build-i586-pokymllib32-linux':
> | configure: error: cannot compute suffix of object files: cannot compile
> | See `config.log' for more details
> | WARNING: /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/x86-pokymllib32-linux/lib32-glibc-initial/2.21-r0/temp/run.do_configure.1095:1 exit 1 from
> |   /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/x86-pokymllib32-linux/lib32-glibc-initial/2.21-r0/git/configure --host=i586-pokymllib32-linux --build=x86_64-linux --prefix=/usr --without-cvs --disable-sanity-checks --with-headers=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/sysroots/lib32-qemux86-64/usr/include --with-kconfig=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/sysroots/x86_64-linux/usr/bin --enable-hacker-mode --enable-addons
> | ERROR: Function failed: do_configure (log file is located at /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/build/tmp/work/x86-pokymllib32-linux/lib32-glibc-initial/2.21-r0/temp/log.do_configure.1095)
> NOTE: recipe lib32-glibc-initial-2.21-r0: task do_configure: Failed
> 
> 
> Can you post config.log ? here
> 
> I don’t have multilib setup so hard to reproduce it here
> 


Nevermind. I think I understood the problem. This tweaking of TUNE_CCARGS is resulting in premature evaluation in case of multilib and we are ending up with 64bit options when using 32bit gcc
Now, I have fixed this by patching glibc itself. see

http://git.openembedded.org/openembedded-core-contrib/tree/meta/recipes-core/glibc/glibc/0001-When-disabling-SSE-also-make-sure-that-fpmath-is-not.patch?h=kraj/gcc-glibc-upgrade

as a result all CCARGS patches aren’t needed any longer.

This should be good with multilib now. Please try the latest patchset.

Thinking of TUNE_CCARGS pruning, I think mips multilib will have similar issues, probably that flag should also move into glibc build system but I will leave that for another day

Re: [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[akuster]

Khem,

If I knew what "testing' entailed I would through some time at this.

- Armin

On 02/02/2015 02:02 AM, Khem Raj wrote:
> Hi All
>
> I have put together upgrade to gcc 4.9.2 as well as glibc 2.21 (
> upcoming ) on  a contrib branch ( top 2 patches) its has not got much
> testing besides x86 qemu thus far.
>
> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-glibc-upgrade
>
> I would like to request some help in testing these out in your
> respective environments and please report any issues you see so we can
> start sorting them out at earlier and making its way into OE-Core.
>
> Thanks for your help
>
> -Khem
>

Re: [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 236 bytes --]

Armin,

On 2 February 2015 at 16:41, akuster <akuster@mvista.com> wrote:

> If I knew what "testing' entailed I would through some time at this.
>

"Please build your stuff with this glibc/gcc and check it still works".

Ross

[-- Attachment #2: Type: text/html, Size: 668 bytes --]

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Burton, Ross]

Armin,

On 2 February 2015 at 16:41, akuster <akuster@mvista.com> wrote:

> If I knew what "testing' entailed I would through some time at this.
>

"Please build your stuff with this glibc/gcc and check it still works".

Ross

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 236 bytes --]

Armin,

On 2 February 2015 at 16:41, akuster <akuster@mvista.com> wrote:

> If I knew what "testing' entailed I would through some time at this.
>

"Please build your stuff with this glibc/gcc and check it still works".

Ross

[-- Attachment #2: Type: text/html, Size: 668 bytes --]

Re: [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 730 bytes --]


> On Feb 2, 2015, at 9:26 AM, Burton, Ross <ross.burton@intel.com> wrote:
> 
> Armin,
> 
> On 2 February 2015 at 16:41, akuster <akuster@mvista.com <mailto:akuster@mvista.com>> wrote:
> If I knew what "testing' entailed I would through some time at this.
> 
> "Please build your stuff with this glibc/gcc and check it still works".
> 

anything helps. apply the patches and see if they apply and parse correctly with your layer combo
then second step is compile and build images/sdks as Ross said.
Third would be boot and runt the images and workloads which you normally do
4th would be run your tests
5th would be run gcc and glibc unit tests.
and repeat same for as many architectures as possible.

> Ross


[-- Attachment #2: Type: text/html, Size: 1879 bytes --]

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

> On Feb 2, 2015, at 9:26 AM, Burton, Ross <ross.burton@intel.com> wrote:
> 
> Armin,
> 
> On 2 February 2015 at 16:41, akuster <akuster@mvista.com <mailto:akuster@mvista.com>> wrote:
> If I knew what "testing' entailed I would through some time at this.
> 
> "Please build your stuff with this glibc/gcc and check it still works".
> 

anything helps. apply the patches and see if they apply and parse correctly with your layer combo
then second step is compile and build images/sdks as Ross said.
Third would be boot and runt the images and workloads which you normally do
4th would be run your tests
5th would be run gcc and glibc unit tests.
and repeat same for as many architectures as possible.

> Ross

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 730 bytes --]


> On Feb 2, 2015, at 9:26 AM, Burton, Ross <ross.burton@intel.com> wrote:
> 
> Armin,
> 
> On 2 February 2015 at 16:41, akuster <akuster@mvista.com <mailto:akuster@mvista.com>> wrote:
> If I knew what "testing' entailed I would through some time at this.
> 
> "Please build your stuff with this glibc/gcc and check it still works".
> 

anything helps. apply the patches and see if they apply and parse correctly with your layer combo
then second step is compile and build images/sdks as Ross said.
Third would be boot and runt the images and workloads which you normally do
4th would be run your tests
5th would be run gcc and glibc unit tests.
and repeat same for as many architectures as possible.

> Ross


[-- Attachment #2: Type: text/html, Size: 1879 bytes --]

Re: [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Richard Purdie]

On Mon, 2015-02-02 at 02:02 -0800, Khem Raj wrote:
> I have put together upgrade to gcc 4.9.2 as well as glibc 2.21 (
> upcoming ) on  a contrib branch ( top 2 patches) its has not got much
> testing besides x86 qemu thus far.
> 
> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-glibc-upgrade
> 
> I would like to request some help in testing these out in your
> respective environments and please report any issues you see so we can
> start sorting them out at earlier and making its way into OE-Core.
> 
> Thanks for your help

For info, I've now merged the glibc part of this change now too.

Khem: Thanks for the work on this!

Cheers,

Richard

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Richard Purdie]

On Mon, 2015-02-02 at 02:02 -0800, Khem Raj wrote:
> I have put together upgrade to gcc 4.9.2 as well as glibc 2.21 (
> upcoming ) on  a contrib branch ( top 2 patches) its has not got much
> testing besides x86 qemu thus far.
> 
> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-glibc-upgrade
> 
> I would like to request some help in testing these out in your
> respective environments and please report any issues you see so we can
> start sorting them out at earlier and making its way into OE-Core.
> 
> Thanks for your help

For info, I've now merged the glibc part of this change now too.

Khem: Thanks for the work on this!

Cheers,

Richard

Re: [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Peter Urbanec]

On 21/02/15 05:03, Richard Purdie wrote:
> On Mon, 2015-02-02 at 02:02 -0800, Khem Raj wrote:
>> I have put together upgrade to gcc 4.9.2 as well as glibc 2.21 (
...
> For info, I've now merged the glibc part of this change now too.

It looks like the new glibc turns all gcc warnings into errors. That does not seem to work too well in all cases:

| mipsel-oe-linux-gcc -mel -mabi=32 -mhard-float --sysroot=/home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/sysroots/inihdp-tcbootstrap pthread_equal.c -c -std=gnu99 -fgnu89-inline  -Os -Wall -Werror -Winline -Wno-error=undef -Wundef -Wwrite-strings -feliminate-unused-debug-types -fmerge-all-constants -frounding-math -g -pipe -Wstrict-prototypes   -fPIC        -I../include -I/home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/nptl  -I/home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux  -I../sysdeps/unix/sysv/linux/mips/mips32/fpu  -I../sysdeps/unix/sysv/linux/mips/mips32  -I../sysdeps/unix/sysv/linux/mips  -I../sysdeps/mips/nptl  -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu  -I../!
 sysdeps/un
ix/inet  -I../sysdeps/unix/sysv  -I../sysdeps/unix/mips/mips32  -I../sysdeps/unix/mips  -I../sysdeps/unix  -I../sysdeps/posix  -I../sysdeps/mips/mips32/fpu  -I../sysdeps/mips/mips32  -I../sysdeps/mips/ieee754  -I../sysdeps/mips/soft-fp  -I../sysdeps/mips/include -I../sysdeps/mips  -I../sysdeps/ieee754/flt-32  -I../sysdeps/ieee754/dbl-64  -I../sysdeps/wordsize-32  -I../sysdeps/mips/fpu  -I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio -I. -nostdinc -isystem /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/sysroots/x86_64-linux/usr/lib/mipsel-oe-linux.gcc-cross-initial-mipsel/gcc/mipsel-oe-linux/4.9.2/include -isystem /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/sysroots/x86_64-linux/usr/lib/mipsel-oe-linux.gcc-cross-initial-mipsel/gcc/mipsel-oe-linux/4.9.2/include-fixed -isystem /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/sysroots/inihdp/usr/include  -D_LIBC_REE!
 NTRANT -in
clude /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/libc-modules.h -DMODULE_NAME=libpthread -include ../include/libc-symbols.h  -DPIC -DSHARED     -o /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/nptl/pthread_equal.os -MD -MP -MF /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/nptl/pthread_equal.os.dt -MT /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/nptl/pthread_equal.os
| In file included from allocatestack.c:30:0,
|                  from pthread_create.c:55:
| allocatestack.c: In function 'stack_list_add':
| ../include/list.h:58:1: error: inlining failed in call to 'list_add': call is unlikely and code size would grow [-Werror=inline]
|  list_add (list_t *newp, list_t *head)
|  ^
| In file included from pthread_create.c:55:0:
| allocatestack.c:159:3: error: called from here [-Werror=inline]
|    list_add (elem, list);
|    ^

Re: [OE-core] [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Peter Urbanec]

On 21/02/15 05:03, Richard Purdie wrote:
> On Mon, 2015-02-02 at 02:02 -0800, Khem Raj wrote:
>> I have put together upgrade to gcc 4.9.2 as well as glibc 2.21 (
...
> For info, I've now merged the glibc part of this change now too.

It looks like the new glibc turns all gcc warnings into errors. That does not seem to work too well in all cases:

| mipsel-oe-linux-gcc -mel -mabi=32 -mhard-float --sysroot=/home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/sysroots/inihdp-tcbootstrap pthread_equal.c -c -std=gnu99 -fgnu89-inline  -Os -Wall -Werror -Winline -Wno-error=undef -Wundef -Wwrite-strings -feliminate-unused-debug-types -fmerge-all-constants -frounding-math -g -pipe -Wstrict-prototypes   -fPIC        -I../include -I/home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/nptl  -I/home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux  -I../sysdeps/unix/sysv/linux/mips/mips32/fpu  -I../sysdeps/unix/sysv/linux/mips/mips32  -I../sysdeps/unix/sysv/linux/mips  -I../sysdeps/mips/nptl  -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu  -I../!
 sysdeps/un
ix/inet  -I../sysdeps/unix/sysv  -I../sysdeps/unix/mips/mips32  -I../sysdeps/unix/mips  -I../sysdeps/unix  -I../sysdeps/posix  -I../sysdeps/mips/mips32/fpu  -I../sysdeps/mips/mips32  -I../sysdeps/mips/ieee754  -I../sysdeps/mips/soft-fp  -I../sysdeps/mips/include -I../sysdeps/mips  -I../sysdeps/ieee754/flt-32  -I../sysdeps/ieee754/dbl-64  -I../sysdeps/wordsize-32  -I../sysdeps/mips/fpu  -I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio -I. -nostdinc -isystem /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/sysroots/x86_64-linux/usr/lib/mipsel-oe-linux.gcc-cross-initial-mipsel/gcc/mipsel-oe-linux/4.9.2/include -isystem /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/sysroots/x86_64-linux/usr/lib/mipsel-oe-linux.gcc-cross-initial-mipsel/gcc/mipsel-oe-linux/4.9.2/include-fixed -isystem /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/sysroots/inihdp/usr/include  -D_LIBC_REE!
 NTRANT -in
clude /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/libc-modules.h -DMODULE_NAME=libpthread -include ../include/libc-symbols.h  -DPIC -DSHARED     -o /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/nptl/pthread_equal.os -MD -MP -MF /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/nptl/pthread_equal.os.dt -MT /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/nptl/pthread_equal.os
| In file included from allocatestack.c:30:0,
|                  from pthread_create.c:55:
| allocatestack.c: In function 'stack_list_add':
| ../include/list.h:58:1: error: inlining failed in call to 'list_add': call is unlikely and code size would grow [-Werror=inline]
|  list_add (list_t *newp, list_t *head)
|  ^
| In file included from pthread_create.c:55:0:
| allocatestack.c:159:3: error: called from here [-Werror=inline]
|    list_add (elem, list);
|    ^

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Peter Urbanec]

On 21/02/15 05:03, Richard Purdie wrote:
> On Mon, 2015-02-02 at 02:02 -0800, Khem Raj wrote:
>> I have put together upgrade to gcc 4.9.2 as well as glibc 2.21 (
...
> For info, I've now merged the glibc part of this change now too.

It looks like the new glibc turns all gcc warnings into errors. That does not seem to work too well in all cases:

| mipsel-oe-linux-gcc -mel -mabi=32 -mhard-float --sysroot=/home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/sysroots/inihdp-tcbootstrap pthread_equal.c -c -std=gnu99 -fgnu89-inline  -Os -Wall -Werror -Winline -Wno-error=undef -Wundef -Wwrite-strings -feliminate-unused-debug-types -fmerge-all-constants -frounding-math -g -pipe -Wstrict-prototypes   -fPIC        -I../include -I/home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/nptl  -I/home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux  -I../sysdeps/unix/sysv/linux/mips/mips32/fpu  -I../sysdeps/unix/sysv/linux/mips/mips32  -I../sysdeps/unix/sysv/linux/mips  -I../sysdeps/mips/nptl  -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu  -I../!
 sysdeps/un
ix/inet  -I../sysdeps/unix/sysv  -I../sysdeps/unix/mips/mips32  -I../sysdeps/unix/mips  -I../sysdeps/unix  -I../sysdeps/posix  -I../sysdeps/mips/mips32/fpu  -I../sysdeps/mips/mips32  -I../sysdeps/mips/ieee754  -I../sysdeps/mips/soft-fp  -I../sysdeps/mips/include -I../sysdeps/mips  -I../sysdeps/ieee754/flt-32  -I../sysdeps/ieee754/dbl-64  -I../sysdeps/wordsize-32  -I../sysdeps/mips/fpu  -I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio -I. -nostdinc -isystem /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/sysroots/x86_64-linux/usr/lib/mipsel-oe-linux.gcc-cross-initial-mipsel/gcc/mipsel-oe-linux/4.9.2/include -isystem /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/sysroots/x86_64-linux/usr/lib/mipsel-oe-linux.gcc-cross-initial-mipsel/gcc/mipsel-oe-linux/4.9.2/include-fixed -isystem /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/sysroots/inihdp/usr/include  -D_LIBC_REE!
 NTRANT -in
clude /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/libc-modules.h -DMODULE_NAME=libpthread -include ../include/libc-symbols.h  -DPIC -DSHARED     -o /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/nptl/pthread_equal.os -MD -MP -MF /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/nptl/pthread_equal.os.dt -MT /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/nptl/pthread_equal.os
| In file included from allocatestack.c:30:0,
|                  from pthread_create.c:55:
| allocatestack.c: In function 'stack_list_add':
| ../include/list.h:58:1: error: inlining failed in call to 'list_add': call is unlikely and code size would grow [-Werror=inline]
|  list_add (list_t *newp, list_t *head)
|  ^
| In file included from pthread_create.c:55:0:
| allocatestack.c:159:3: error: called from here [-Werror=inline]
|    list_add (elem, list);
|    ^

Re: [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

> On Feb 20, 2015, at 4:27 PM, Peter Urbanec <openembedded-devel@urbanec.net> wrote:
> 
> On 21/02/15 05:03, Richard Purdie wrote:
>> On Mon, 2015-02-02 at 02:02 -0800, Khem Raj wrote:
>>> I have put together upgrade to gcc 4.9.2 as well as glibc 2.21 (
> ...
>> For info, I've now merged the glibc part of this change now too.
> 
> It looks like the new glibc turns all gcc warnings into errors. That does not seem to work too well in all cases:

you seem to be overriding default selected optimization to use -Os instead of -O2, with 2.21 glibc is now using -Werror by default which is a good thing
but then not all combinations have been tested out so when you override the default opt level then please add -Wno-error as well. May be I should just send a patch to detect this usecase


> 
> | mipsel-oe-linux-gcc -mel -mabi=32 -mhard-float --sysroot=/home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/sysroots/inihdp-tcbootstrap pthread_equal.c -c -std=gnu99 -fgnu89-inline  -Os -Wall -Werror -Winline -Wno-error=undef -Wundef -Wwrite-strings -feliminate-unused-debug-types -fmerge-all-constants -frounding-math -g -pipe -Wstrict-prototypes   -fPIC        -I../include -I/home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/nptl  -I/home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux  -I../sysdeps/unix/sysv/linux/mips/mips32/fpu  -I../sysdeps/unix/sysv/linux/mips/mips32  -I../sysdeps/unix/sysv/linux/mips  -I../sysdeps/mips/nptl  -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu  -I../!
> sysdeps/un
> ix/inet  -I../sysdeps/unix/sysv  -I../sysdeps/unix/mips/mips32  -I../sysdeps/unix/mips  -I../sysdeps/unix  -I../sysdeps/posix  -I../sysdeps/mips/mips32/fpu  -I../sysdeps/mips/mips32  -I../sysdeps/mips/ieee754  -I../sysdeps/mips/soft-fp  -I../sysdeps/mips/include -I../sysdeps/mips  -I../sysdeps/ieee754/flt-32  -I../sysdeps/ieee754/dbl-64  -I../sysdeps/wordsize-32  -I../sysdeps/mips/fpu  -I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio -I. -nostdinc -isystem /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/sysroots/x86_64-linux/usr/lib/mipsel-oe-linux.gcc-cross-initial-mipsel/gcc/mipsel-oe-linux/4.9.2/include -isystem /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/sysroots/x86_64-linux/usr/lib/mipsel-oe-linux.gcc-cross-initial-mipsel/gcc/mipsel-oe-linux/4.9.2/include-fixed -isystem /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/sysroots/inihdp/usr/include  -D_LIBC_REE!
> NTRANT -in
> clude /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/libc-modules.h -DMODULE_NAME=libpthread -include ../include/libc-symbols.h  -DPIC -DSHARED     -o /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/nptl/pthread_equal.os -MD -MP -MF /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/nptl/pthread_equal.os.dt -MT /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/nptl/pthread_equal.os
> | In file included from allocatestack.c:30:0,
> |                  from pthread_create.c:55:
> | allocatestack.c: In function 'stack_list_add':
> | ../include/list.h:58:1: error: inlining failed in call to 'list_add': call is unlikely and code size would grow [-Werror=inline]
> |  list_add (list_t *newp, list_t *head)
> |  ^
> | In file included from pthread_create.c:55:0:
> | allocatestack.c:159:3: error: called from here [-Werror=inline]
> |    list_add (elem, list);
> |    ^
> 

Re: [OE-core] [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

> On Feb 20, 2015, at 4:27 PM, Peter Urbanec <openembedded-devel@urbanec.net> wrote:
> 
> On 21/02/15 05:03, Richard Purdie wrote:
>> On Mon, 2015-02-02 at 02:02 -0800, Khem Raj wrote:
>>> I have put together upgrade to gcc 4.9.2 as well as glibc 2.21 (
> ...
>> For info, I've now merged the glibc part of this change now too.
> 
> It looks like the new glibc turns all gcc warnings into errors. That does not seem to work too well in all cases:

you seem to be overriding default selected optimization to use -Os instead of -O2, with 2.21 glibc is now using -Werror by default which is a good thing
but then not all combinations have been tested out so when you override the default opt level then please add -Wno-error as well. May be I should just send a patch to detect this usecase


> 
> | mipsel-oe-linux-gcc -mel -mabi=32 -mhard-float --sysroot=/home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/sysroots/inihdp-tcbootstrap pthread_equal.c -c -std=gnu99 -fgnu89-inline  -Os -Wall -Werror -Winline -Wno-error=undef -Wundef -Wwrite-strings -feliminate-unused-debug-types -fmerge-all-constants -frounding-math -g -pipe -Wstrict-prototypes   -fPIC        -I../include -I/home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/nptl  -I/home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux  -I../sysdeps/unix/sysv/linux/mips/mips32/fpu  -I../sysdeps/unix/sysv/linux/mips/mips32  -I../sysdeps/unix/sysv/linux/mips  -I../sysdeps/mips/nptl  -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu  -I../!
> sysdeps/un
> ix/inet  -I../sysdeps/unix/sysv  -I../sysdeps/unix/mips/mips32  -I../sysdeps/unix/mips  -I../sysdeps/unix  -I../sysdeps/posix  -I../sysdeps/mips/mips32/fpu  -I../sysdeps/mips/mips32  -I../sysdeps/mips/ieee754  -I../sysdeps/mips/soft-fp  -I../sysdeps/mips/include -I../sysdeps/mips  -I../sysdeps/ieee754/flt-32  -I../sysdeps/ieee754/dbl-64  -I../sysdeps/wordsize-32  -I../sysdeps/mips/fpu  -I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio -I. -nostdinc -isystem /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/sysroots/x86_64-linux/usr/lib/mipsel-oe-linux.gcc-cross-initial-mipsel/gcc/mipsel-oe-linux/4.9.2/include -isystem /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/sysroots/x86_64-linux/usr/lib/mipsel-oe-linux.gcc-cross-initial-mipsel/gcc/mipsel-oe-linux/4.9.2/include-fixed -isystem /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/sysroots/inihdp/usr/include  -D_LIBC_REE!
> NTRANT -in
> clude /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/libc-modules.h -DMODULE_NAME=libpthread -include ../include/libc-symbols.h  -DPIC -DSHARED     -o /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/nptl/pthread_equal.os -MD -MP -MF /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/nptl/pthread_equal.os.dt -MT /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/nptl/pthread_equal.os
> | In file included from allocatestack.c:30:0,
> |                  from pthread_create.c:55:
> | allocatestack.c: In function 'stack_list_add':
> | ../include/list.h:58:1: error: inlining failed in call to 'list_add': call is unlikely and code size would grow [-Werror=inline]
> |  list_add (list_t *newp, list_t *head)
> |  ^
> | In file included from pthread_create.c:55:0:
> | allocatestack.c:159:3: error: called from here [-Werror=inline]
> |    list_add (elem, list);
> |    ^
> 

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

> On Feb 20, 2015, at 4:27 PM, Peter Urbanec <openembedded-devel@urbanec.net> wrote:
> 
> On 21/02/15 05:03, Richard Purdie wrote:
>> On Mon, 2015-02-02 at 02:02 -0800, Khem Raj wrote:
>>> I have put together upgrade to gcc 4.9.2 as well as glibc 2.21 (
> ...
>> For info, I've now merged the glibc part of this change now too.
> 
> It looks like the new glibc turns all gcc warnings into errors. That does not seem to work too well in all cases:

you seem to be overriding default selected optimization to use -Os instead of -O2, with 2.21 glibc is now using -Werror by default which is a good thing
but then not all combinations have been tested out so when you override the default opt level then please add -Wno-error as well. May be I should just send a patch to detect this usecase


> 
> | mipsel-oe-linux-gcc -mel -mabi=32 -mhard-float --sysroot=/home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/sysroots/inihdp-tcbootstrap pthread_equal.c -c -std=gnu99 -fgnu89-inline  -Os -Wall -Werror -Winline -Wno-error=undef -Wundef -Wwrite-strings -feliminate-unused-debug-types -fmerge-all-constants -frounding-math -g -pipe -Wstrict-prototypes   -fPIC        -I../include -I/home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/nptl  -I/home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux  -I../sysdeps/unix/sysv/linux/mips/mips32/fpu  -I../sysdeps/unix/sysv/linux/mips/mips32  -I../sysdeps/unix/sysv/linux/mips  -I../sysdeps/mips/nptl  -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu  -I../!
> sysdeps/un
> ix/inet  -I../sysdeps/unix/sysv  -I../sysdeps/unix/mips/mips32  -I../sysdeps/unix/mips  -I../sysdeps/unix  -I../sysdeps/posix  -I../sysdeps/mips/mips32/fpu  -I../sysdeps/mips/mips32  -I../sysdeps/mips/ieee754  -I../sysdeps/mips/soft-fp  -I../sysdeps/mips/include -I../sysdeps/mips  -I../sysdeps/ieee754/flt-32  -I../sysdeps/ieee754/dbl-64  -I../sysdeps/wordsize-32  -I../sysdeps/mips/fpu  -I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio -I. -nostdinc -isystem /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/sysroots/x86_64-linux/usr/lib/mipsel-oe-linux.gcc-cross-initial-mipsel/gcc/mipsel-oe-linux/4.9.2/include -isystem /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/sysroots/x86_64-linux/usr/lib/mipsel-oe-linux.gcc-cross-initial-mipsel/gcc/mipsel-oe-linux/4.9.2/include-fixed -isystem /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/sysroots/inihdp/usr/include  -D_LIBC_REE!
> NTRANT -in
> clude /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/libc-modules.h -DMODULE_NAME=libpthread -include ../include/libc-symbols.h  -DPIC -DSHARED     -o /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/nptl/pthread_equal.os -MD -MP -MF /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/nptl/pthread_equal.os.dt -MT /home/peteru/Source/T3/build-enviroment-core-24/builds/beyonwiz/inihdp/tmp-glibc/work/mips32el-oe-linux/glibc/glibc-2.21-r0/build-mipsel-oe-linux/nptl/pthread_equal.os
> | In file included from allocatestack.c:30:0,
> |                  from pthread_create.c:55:
> | allocatestack.c: In function 'stack_list_add':
> | ../include/list.h:58:1: error: inlining failed in call to 'list_add': call is unlikely and code size would grow [-Werror=inline]
> |  list_add (list_t *newp, list_t *head)
> |  ^
> | In file included from pthread_create.c:55:0:
> | allocatestack.c:159:3: error: called from here [-Werror=inline]
> |    list_add (elem, list);
> |    ^
> 

Re: [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Richard Purdie]

On Fri, 2015-02-20 at 18:03 +0000, Richard Purdie wrote:
> On Mon, 2015-02-02 at 02:02 -0800, Khem Raj wrote:
> > I have put together upgrade to gcc 4.9.2 as well as glibc 2.21 (
> > upcoming ) on  a contrib branch ( top 2 patches) its has not got much
> > testing besides x86 qemu thus far.
> > 
> > http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-glibc-upgrade
> > 
> > I would like to request some help in testing these out in your
> > respective environments and please report any issues you see so we can
> > start sorting them out at earlier and making its way into OE-Core.
> > 
> > Thanks for your help
> 
> For info, I've now merged the glibc part of this change now too.
> 
> Khem: Thanks for the work on this!

New issue that caught my eye:

https://autobuilder.yoctoproject.org/main/builders/nightly-qa-logrotate/builds/204/steps/Running%20Sanity%20Tests/logs/stdio

segfault in init within libc :/.

Cheers,

Richard

Re: [OE-core] [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Richard Purdie]

On Fri, 2015-02-20 at 18:03 +0000, Richard Purdie wrote:
> On Mon, 2015-02-02 at 02:02 -0800, Khem Raj wrote:
> > I have put together upgrade to gcc 4.9.2 as well as glibc 2.21 (
> > upcoming ) on  a contrib branch ( top 2 patches) its has not got much
> > testing besides x86 qemu thus far.
> > 
> > http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-glibc-upgrade
> > 
> > I would like to request some help in testing these out in your
> > respective environments and please report any issues you see so we can
> > start sorting them out at earlier and making its way into OE-Core.
> > 
> > Thanks for your help
> 
> For info, I've now merged the glibc part of this change now too.
> 
> Khem: Thanks for the work on this!

New issue that caught my eye:

https://autobuilder.yoctoproject.org/main/builders/nightly-qa-logrotate/builds/204/steps/Running%20Sanity%20Tests/logs/stdio

segfault in init within libc :/.

Cheers,

Richard

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Richard Purdie]

On Fri, 2015-02-20 at 18:03 +0000, Richard Purdie wrote:
> On Mon, 2015-02-02 at 02:02 -0800, Khem Raj wrote:
> > I have put together upgrade to gcc 4.9.2 as well as glibc 2.21 (
> > upcoming ) on  a contrib branch ( top 2 patches) its has not got much
> > testing besides x86 qemu thus far.
> > 
> > http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-glibc-upgrade
> > 
> > I would like to request some help in testing these out in your
> > respective environments and please report any issues you see so we can
> > start sorting them out at earlier and making its way into OE-Core.
> > 
> > Thanks for your help
> 
> For info, I've now merged the glibc part of this change now too.
> 
> Khem: Thanks for the work on this!

New issue that caught my eye:

https://autobuilder.yoctoproject.org/main/builders/nightly-qa-logrotate/builds/204/steps/Running%20Sanity%20Tests/logs/stdio

segfault in init within libc :/.

Cheers,

Richard

Re: [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

> On Feb 21, 2015, at 1:22 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> 
> On Fri, 2015-02-20 at 18:03 +0000, Richard Purdie wrote:
>> On Mon, 2015-02-02 at 02:02 -0800, Khem Raj wrote:
>>> I have put together upgrade to gcc 4.9.2 as well as glibc 2.21 (
>>> upcoming ) on  a contrib branch ( top 2 patches) its has not got much
>>> testing besides x86 qemu thus far.
>>> 
>>> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-glibc-upgrade
>>> 
>>> I would like to request some help in testing these out in your
>>> respective environments and please report any issues you see so we can
>>> start sorting them out at earlier and making its way into OE-Core.
>>> 
>>> Thanks for your help
>> 
>> For info, I've now merged the glibc part of this change now too.
>> 
>> Khem: Thanks for the work on this!
> 
> New issue that caught my eye:
> 
> https://autobuilder.yoctoproject.org/main/builders/nightly-qa-logrotate/builds/204/steps/Running%20Sanity%20Tests/logs/stdio
> 
> segfault in init within libc :/.

I have booted core-image-minimal, for all arches and that have worked fine for both systemd and sysvinit and some of non-oe-core graphic images booted well too
but here it seems its using core-image-sato wondering what changed there … can someone try it out and may be see what is it trying to launch during boot that is in addition
to core image minimal.

Re: [OE-core] [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

> On Feb 21, 2015, at 1:22 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> 
> On Fri, 2015-02-20 at 18:03 +0000, Richard Purdie wrote:
>> On Mon, 2015-02-02 at 02:02 -0800, Khem Raj wrote:
>>> I have put together upgrade to gcc 4.9.2 as well as glibc 2.21 (
>>> upcoming ) on  a contrib branch ( top 2 patches) its has not got much
>>> testing besides x86 qemu thus far.
>>> 
>>> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-glibc-upgrade
>>> 
>>> I would like to request some help in testing these out in your
>>> respective environments and please report any issues you see so we can
>>> start sorting them out at earlier and making its way into OE-Core.
>>> 
>>> Thanks for your help
>> 
>> For info, I've now merged the glibc part of this change now too.
>> 
>> Khem: Thanks for the work on this!
> 
> New issue that caught my eye:
> 
> https://autobuilder.yoctoproject.org/main/builders/nightly-qa-logrotate/builds/204/steps/Running%20Sanity%20Tests/logs/stdio
> 
> segfault in init within libc :/.

I have booted core-image-minimal, for all arches and that have worked fine for both systemd and sysvinit and some of non-oe-core graphic images booted well too
but here it seems its using core-image-sato wondering what changed there … can someone try it out and may be see what is it trying to launch during boot that is in addition
to core image minimal.

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

> On Feb 21, 2015, at 1:22 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> 
> On Fri, 2015-02-20 at 18:03 +0000, Richard Purdie wrote:
>> On Mon, 2015-02-02 at 02:02 -0800, Khem Raj wrote:
>>> I have put together upgrade to gcc 4.9.2 as well as glibc 2.21 (
>>> upcoming ) on  a contrib branch ( top 2 patches) its has not got much
>>> testing besides x86 qemu thus far.
>>> 
>>> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-glibc-upgrade
>>> 
>>> I would like to request some help in testing these out in your
>>> respective environments and please report any issues you see so we can
>>> start sorting them out at earlier and making its way into OE-Core.
>>> 
>>> Thanks for your help
>> 
>> For info, I've now merged the glibc part of this change now too.
>> 
>> Khem: Thanks for the work on this!
> 
> New issue that caught my eye:
> 
> https://autobuilder.yoctoproject.org/main/builders/nightly-qa-logrotate/builds/204/steps/Running%20Sanity%20Tests/logs/stdio
> 
> segfault in init within libc :/.

I have booted core-image-minimal, for all arches and that have worked fine for both systemd and sysvinit and some of non-oe-core graphic images booted well too
but here it seems its using core-image-sato wondering what changed there … can someone try it out and may be see what is it trying to launch during boot that is in addition
to core image minimal.

Re: [OE-core] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

> On Feb 23, 2015, at 10:59 PM, Khem Raj <raj.khem@gmail.com> wrote:
> 
>> 
>> On Feb 21, 2015, at 1:22 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
>> 
>> On Fri, 2015-02-20 at 18:03 +0000, Richard Purdie wrote:
>>> On Mon, 2015-02-02 at 02:02 -0800, Khem Raj wrote:
>>>> I have put together upgrade to gcc 4.9.2 as well as glibc 2.21 (
>>>> upcoming ) on  a contrib branch ( top 2 patches) its has not got much
>>>> testing besides x86 qemu thus far.
>>>> 
>>>> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-glibc-upgrade
>>>> 
>>>> I would like to request some help in testing these out in your
>>>> respective environments and please report any issues you see so we can
>>>> start sorting them out at earlier and making its way into OE-Core.
>>>> 
>>>> Thanks for your help
>>> 
>>> For info, I've now merged the glibc part of this change now too.
>>> 
>>> Khem: Thanks for the work on this!
>> 
>> New issue that caught my eye:
>> 
>> https://autobuilder.yoctoproject.org/main/builders/nightly-qa-logrotate/builds/204/steps/Running%20Sanity%20Tests/logs/stdio
>> 
>> segfault in init within libc :/.
> 
> I have booted core-image-minimal, for all arches and that have worked fine for both systemd and sysvinit and some of non-oe-core graphic images booted well too
> but here it seems its using core-image-sato wondering what changed there … can someone try it out and may be see what is it trying to launch during boot that is in addition
> to core image minimal.

My core-image-sato/sysvinit booted without crash too ( host is ubuntu 15.04 x86_64)

Re: [OE-core] [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

> On Feb 23, 2015, at 10:59 PM, Khem Raj <raj.khem@gmail.com> wrote:
> 
>> 
>> On Feb 21, 2015, at 1:22 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
>> 
>> On Fri, 2015-02-20 at 18:03 +0000, Richard Purdie wrote:
>>> On Mon, 2015-02-02 at 02:02 -0800, Khem Raj wrote:
>>>> I have put together upgrade to gcc 4.9.2 as well as glibc 2.21 (
>>>> upcoming ) on  a contrib branch ( top 2 patches) its has not got much
>>>> testing besides x86 qemu thus far.
>>>> 
>>>> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-glibc-upgrade
>>>> 
>>>> I would like to request some help in testing these out in your
>>>> respective environments and please report any issues you see so we can
>>>> start sorting them out at earlier and making its way into OE-Core.
>>>> 
>>>> Thanks for your help
>>> 
>>> For info, I've now merged the glibc part of this change now too.
>>> 
>>> Khem: Thanks for the work on this!
>> 
>> New issue that caught my eye:
>> 
>> https://autobuilder.yoctoproject.org/main/builders/nightly-qa-logrotate/builds/204/steps/Running%20Sanity%20Tests/logs/stdio
>> 
>> segfault in init within libc :/.
> 
> I have booted core-image-minimal, for all arches and that have worked fine for both systemd and sysvinit and some of non-oe-core graphic images booted well too
> but here it seems its using core-image-sato wondering what changed there … can someone try it out and may be see what is it trying to launch during boot that is in addition
> to core image minimal.

My core-image-sato/sysvinit booted without crash too ( host is ubuntu 15.04 x86_64)

Re: [yocto] [RFT] upcoming glibc 2.21 and gcc 4.9 upgrade

[Khem Raj]

> On Feb 23, 2015, at 10:59 PM, Khem Raj <raj.khem@gmail.com> wrote:
> 
>> 
>> On Feb 21, 2015, at 1:22 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
>> 
>> On Fri, 2015-02-20 at 18:03 +0000, Richard Purdie wrote:
>>> On Mon, 2015-02-02 at 02:02 -0800, Khem Raj wrote:
>>>> I have put together upgrade to gcc 4.9.2 as well as glibc 2.21 (
>>>> upcoming ) on  a contrib branch ( top 2 patches) its has not got much
>>>> testing besides x86 qemu thus far.
>>>> 
>>>> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-glibc-upgrade
>>>> 
>>>> I would like to request some help in testing these out in your
>>>> respective environments and please report any issues you see so we can
>>>> start sorting them out at earlier and making its way into OE-Core.
>>>> 
>>>> Thanks for your help
>>> 
>>> For info, I've now merged the glibc part of this change now too.
>>> 
>>> Khem: Thanks for the work on this!
>> 
>> New issue that caught my eye:
>> 
>> https://autobuilder.yoctoproject.org/main/builders/nightly-qa-logrotate/builds/204/steps/Running%20Sanity%20Tests/logs/stdio
>> 
>> segfault in init within libc :/.
> 
> I have booted core-image-minimal, for all arches and that have worked fine for both systemd and sysvinit and some of non-oe-core graphic images booted well too
> but here it seems its using core-image-sato wondering what changed there … can someone try it out and may be see what is it trying to launch during boot that is in addition
> to core image minimal.

My core-image-sato/sysvinit booted without crash too ( host is ubuntu 15.04 x86_64)