gcc 4.7 + mips64 architecture support

gcc 4.7 + mips64 architecture support

[Khem Raj]

Hello

Now that release is almost out of door. I would like some eyes on the
gcc-4.7 work
and mips64 architecture support that I have done meanwhile

I have made sure that gcc-4.6 still keeps working and I have patches
for gcc-4.5 too
for meta-oe too. I have repeatedly built core-image-sato and
core-image-minimal for uclibc/eglibc
but more coverage would be nicer.

The patches are posted here

http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/misc

I would appreciate any feedback or testing on this

Thanks
-Khem

Re: gcc 4.7 + mips64 architecture support

[Richard Purdie]

On Wed, 2012-04-25 at 16:31 -0700, Khem Raj wrote:
> Hello
> 
> Now that release is almost out of door. I would like some eyes on the
> gcc-4.7 work
> and mips64 architecture support that I have done meanwhile
> 
> I have made sure that gcc-4.6 still keeps working and I have patches
> for gcc-4.5 too
> for meta-oe too. I have repeatedly built core-image-sato and
> core-image-minimal for uclibc/eglibc
> but more coverage would be nicer.
> 
> The patches are posted here
> 
> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/misc
> 
> I would appreciate any feedback or testing on this

I had a look through the patch series. I've posted an altered version of
the class override patch. I've pulled the gcc 4.7 part into master-next,
have get gcc 4.7 as the default and am running it though the
autobuilder. That should see how we stand with our usual regression
tests.

I didn't add in the kmod or mips64 bits yet as I wanted to test one
thing at a time.

Cheers,

Richard

Re: gcc 4.7 + mips64 architecture support

[Richard Purdie]

On Thu, 2012-04-26 at 15:47 +0100, Richard Purdie wrote:
> On Wed, 2012-04-25 at 16:31 -0700, Khem Raj wrote:
> > Hello
> > 
> > Now that release is almost out of door. I would like some eyes on the
> > gcc-4.7 work
> > and mips64 architecture support that I have done meanwhile
> > 
> > I have made sure that gcc-4.6 still keeps working and I have patches
> > for gcc-4.5 too
> > for meta-oe too. I have repeatedly built core-image-sato and
> > core-image-minimal for uclibc/eglibc
> > but more coverage would be nicer.
> > 
> > The patches are posted here
> > 
> > http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/misc
> > 
> > I would appreciate any feedback or testing on this
> 
> I had a look through the patch series. I've posted an altered version of
> the class override patch. I've pulled the gcc 4.7 part into master-next,
> have get gcc 4.7 as the default and am running it though the
> autobuilder. That should see how we stand with our usual regression
> tests.

The builds shows the following failures (I've kept duplication so you
can see the patterns). Not too bad considering:

MACHINE=qemux86, failure in:
gst-ffmpeg:do_configure
http://autobuilder.yoctoproject.org:8010/builders/nightly-world/builds/66/steps/shell_24/logs/stdio

MACHINE=qemuarm, failures in:
clutter-1.8:do_configure
glew:do_compile
qt4-x11-free:do_compile
http://autobuilder.yoctoproject.org:8010/builders/nightly-arm/builds/402/steps/shell_19/logs/stdio

MACHINE=qemuppc, failures in:
clutter-1.8:do_configure
glew:do_compile
qt4-x11-free:do_compile
http://autobuilder.yoctoproject.org:8010/builders/nightly-ppc/builds/359/steps/shell_19/logs/stdio

MACHINE=mpc8315e-rdb, failure in:
mesa-dri:do_compile
http://autobuilder.yoctoproject.org:8010/builders/nightly-ppc/builds/359/steps/shell_35/logs/stdio

MACHINE=qemumips, failures in:
clutter-1.8:do_configure
glew:do_compile
http://autobuilder.yoctoproject.org:8010/builders/nightly-mips/builds/371/steps/shell_19/logs/stdio

MACHINE=beagleboard, failure in:
mesa-dri:do_compile
http://autobuilder.yoctoproject.org:8010/builders/nightly-arm/builds/402/steps/shell_35/logs/stdio

MACHINE=routerstationpro, failure in:
mesa-dri:do_compile
http://autobuilder.yoctoproject.org:8010/builders/nightly-mips/builds/371/steps/shell_35/logs/stdio


Also, adding meta-qt3 and building lsb targets with DISTRO=poky-lsb adds
the failure:
qt-x11-free:do_compile
<plus repeats of the above>
http://autobuilder.yoctoproject.org:8010/builders/nightly-ppc/builds/359/steps/shell_76/logs/stdio

There will be more build failures but probably variations of the above
on lsb builds but those haven't happened yet.

Cheers,

Richard

Re: gcc 4.7 + mips64 architecture support

[Richard Purdie]

On Thu, 2012-04-26 at 20:30 +0100, Richard Purdie wrote:
> On Thu, 2012-04-26 at 15:47 +0100, Richard Purdie wrote:
> > On Wed, 2012-04-25 at 16:31 -0700, Khem Raj wrote:
> > > Hello
> > > 
> > > Now that release is almost out of door. I would like some eyes on the
> > > gcc-4.7 work
> > > and mips64 architecture support that I have done meanwhile
> > > 
> > > I have made sure that gcc-4.6 still keeps working and I have patches
> > > for gcc-4.5 too
> > > for meta-oe too. I have repeatedly built core-image-sato and
> > > core-image-minimal for uclibc/eglibc
> > > but more coverage would be nicer.
> > > 
> > > The patches are posted here
> > > 
> > > http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/misc
> > > 
> > > I would appreciate any feedback or testing on this
> > 
> > I had a look through the patch series. I've posted an altered version of
> > the class override patch. I've pulled the gcc 4.7 part into master-next,
> > have get gcc 4.7 as the default and am running it though the
> > autobuilder. That should see how we stand with our usual regression
> > tests.
> 
> The builds shows the following failures (I've kept duplication so you
> can see the patterns). Not too bad considering:
> 
> MACHINE=qemux86, failure in:
> gst-ffmpeg:do_configure
> http://autobuilder.yoctoproject.org:8010/builders/nightly-world/builds/66/steps/shell_24/logs/stdio
> 
> MACHINE=qemuarm, failures in:
> clutter-1.8:do_configure
> glew:do_compile
> qt4-x11-free:do_compile
> http://autobuilder.yoctoproject.org:8010/builders/nightly-arm/builds/402/steps/shell_19/logs/stdio
> 
> MACHINE=qemuppc, failures in:
> clutter-1.8:do_configure
> glew:do_compile
> qt4-x11-free:do_compile
> http://autobuilder.yoctoproject.org:8010/builders/nightly-ppc/builds/359/steps/shell_19/logs/stdio
> 
> MACHINE=mpc8315e-rdb, failure in:
> mesa-dri:do_compile
> http://autobuilder.yoctoproject.org:8010/builders/nightly-ppc/builds/359/steps/shell_35/logs/stdio
> 
> MACHINE=qemumips, failures in:
> clutter-1.8:do_configure
> glew:do_compile
> http://autobuilder.yoctoproject.org:8010/builders/nightly-mips/builds/371/steps/shell_19/logs/stdio
> 
> MACHINE=beagleboard, failure in:
> mesa-dri:do_compile
> http://autobuilder.yoctoproject.org:8010/builders/nightly-arm/builds/402/steps/shell_35/logs/stdio
> 
> MACHINE=routerstationpro, failure in:
> mesa-dri:do_compile
> http://autobuilder.yoctoproject.org:8010/builders/nightly-mips/builds/371/steps/shell_35/logs/stdio
> 
> 
> Also, adding meta-qt3 and building lsb targets with DISTRO=poky-lsb adds
> the failure:
> qt-x11-free:do_compile
> <plus repeats of the above>
> http://autobuilder.yoctoproject.org:8010/builders/nightly-ppc/builds/359/steps/shell_76/logs/stdio

FWIW I've posted a mesa fix which should help many of these issue. It
looks like gcc 4.7 has stricter option parsing.

Why mesa didn't always fail to build is something that needs looking
into as a separate issue, the logs are full of errors.

Cheers,

Richard

Re: gcc 4.7 + mips64 architecture support

[Khem Raj]

On Thu, Apr 26, 2012 at 2:06 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Thu, 2012-04-26 at 20:30 +0100, Richard Purdie wrote:
>> On Thu, 2012-04-26 at 15:47 +0100, Richard Purdie wrote:
>> > On Wed, 2012-04-25 at 16:31 -0700, Khem Raj wrote:
>> > > Hello
>> > >
>> > > Now that release is almost out of door. I would like some eyes on the
>> > > gcc-4.7 work
>> > > and mips64 architecture support that I have done meanwhile
>> > >
>> > > I have made sure that gcc-4.6 still keeps working and I have patches
>> > > for gcc-4.5 too
>> > > for meta-oe too. I have repeatedly built core-image-sato and
>> > > core-image-minimal for uclibc/eglibc
>> > > but more coverage would be nicer.
>> > >
>> > > The patches are posted here
>> > >
>> > > http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/misc
>> > >
>> > > I would appreciate any feedback or testing on this
>> >
>> > I had a look through the patch series. I've posted an altered version of
>> > the class override patch. I've pulled the gcc 4.7 part into master-next,
>> > have get gcc 4.7 as the default and am running it though the
>> > autobuilder. That should see how we stand with our usual regression
>> > tests.
>>
>> The builds shows the following failures (I've kept duplication so you
>> can see the patterns). Not too bad considering:
>>
>> MACHINE=qemux86, failure in:
>> gst-ffmpeg:do_configure
>> http://autobuilder.yoctoproject.org:8010/builders/nightly-world/builds/66/steps/shell_24/logs/stdio
>>
>> MACHINE=qemuarm, failures in:
>> clutter-1.8:do_configure
>> glew:do_compile
>> qt4-x11-free:do_compile
>> http://autobuilder.yoctoproject.org:8010/builders/nightly-arm/builds/402/steps/shell_19/logs/stdio
>>
>> MACHINE=qemuppc, failures in:
>> clutter-1.8:do_configure
>> glew:do_compile
>> qt4-x11-free:do_compile
>> http://autobuilder.yoctoproject.org:8010/builders/nightly-ppc/builds/359/steps/shell_19/logs/stdio
>>
>> MACHINE=mpc8315e-rdb, failure in:
>> mesa-dri:do_compile
>> http://autobuilder.yoctoproject.org:8010/builders/nightly-ppc/builds/359/steps/shell_35/logs/stdio
>>
>> MACHINE=qemumips, failures in:
>> clutter-1.8:do_configure
>> glew:do_compile
>> http://autobuilder.yoctoproject.org:8010/builders/nightly-mips/builds/371/steps/shell_19/logs/stdio
>>
>> MACHINE=beagleboard, failure in:
>> mesa-dri:do_compile
>> http://autobuilder.yoctoproject.org:8010/builders/nightly-arm/builds/402/steps/shell_35/logs/stdio
>>
>> MACHINE=routerstationpro, failure in:
>> mesa-dri:do_compile
>> http://autobuilder.yoctoproject.org:8010/builders/nightly-mips/builds/371/steps/shell_35/logs/stdio
>>
>>
>> Also, adding meta-qt3 and building lsb targets with DISTRO=poky-lsb adds
>> the failure:
>> qt-x11-free:do_compile
>> <plus repeats of the above>
>> http://autobuilder.yoctoproject.org:8010/builders/nightly-ppc/builds/359/steps/shell_76/logs/stdio
>

I just looked at this quickly
| powerpc-poky-linux-g++: error: unrecognized command line option '-mmmx'

Its passing x86 options to ppc compiler that is wrong.

I will get to other failures later when I am at home

Re: gcc 4.7 + mips64 architecture support

[Martin Jansa]

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

On Wed, Apr 25, 2012 at 04:31:53PM -0700, Khem Raj wrote:
> Hello
> 
> Now that release is almost out of door. I would like some eyes on the
> gcc-4.7 work
> and mips64 architecture support that I have done meanwhile
> 
> I have made sure that gcc-4.6 still keeps working and I have patches
> for gcc-4.5 too
> for meta-oe too. I have repeatedly built core-image-sato and
> core-image-minimal for uclibc/eglibc
> but more coverage would be nicer.
> 
> The patches are posted here
> 
> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/misc
> 
> I would appreciate any feedback or testing on this

I got some errors while building gcc* recipes (overwriting header 
files in work-shared or something like that) but that's not new, gcc-4.6
was failing the same - restarting build few times and it will succeed
once.

My minimal shr-lite-image compiles now fine and works on om-gta02
(armv4t) sofar without segfaults.. so looks good.

For normal image and feeds I've few more recipes which are failing with gcc-4.7:

meta-openembedded/meta-efl/recipes-efl/webkit/webkit-efl_svn.bb
  | Unknown parameter a interfaceName for tags/attrs
  | make[2]: *** [DerivedSources/WebCore/HTMLNames.cpp] Error 255
  http://norman-schleicher.de/jenkins/job/shr-core-branches-om-gta02-shr-image/ws/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/webkit-efl-1.7.3+svnr105069-r1/
  I'm upgrading this one instead of fixing it, because we had some
  issues in runtime with current version, but new version needs newer
  libsoup-2.4->glib-2.0->gobject-introspection->etc and fails with
  different compilation issues.. so maybe if you know how to easily fix
  it in current, we can, otherwise I'll continue to work on upgrade

  BTW: similar fix as you did for webkit-gtk is in upstream r109509

meta-oe/recipes-extended/mml-widget/gtkmathview_0.8.0.bb
  ../../../src/frontend/common/TemplateBuilder.hh:54:42: error: redeclaration of 'SmartPtr<typename ElementBuilder::type> elem'
  ../../../src/frontend/common/TemplateBuilder.hh:50:49: error: 'SmartPtr<typename ElementBuilder::type> elem' previously declared here
  http://norman-schleicher.de/jenkins/job/shr-core-branches-om-gta02-shr-image/ws/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/gtkmathview-0.8.0-r1/

meta-smartphone/meta-shr/recipes-shr/3rdparty/numptyphysics_svn.bb
  fixed in shr branch

meta-mozilla/recipes-mozilla/firefox/firefox_10.0.2.bb
  | /var/lib/jenkins/jobs/shr-core-branches/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/firefox-10.0.2-r1/mozilla-release/ipc/chromium/src/base/file_util.cc:228:35: error: 'ftruncate' was not declared in this scope
  probably easy to fix, adding Otavio to CC (maybe he has upgrade or fix
  ready)

Cheers,

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: gcc 4.7 + mips64 architecture support

[Khem Raj]

On Sun, Apr 29, 2012 at 2:12 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Wed, Apr 25, 2012 at 04:31:53PM -0700, Khem Raj wrote:
>> Hello
>>
>> Now that release is almost out of door. I would like some eyes on the
>> gcc-4.7 work
>> and mips64 architecture support that I have done meanwhile
>>
>> I have made sure that gcc-4.6 still keeps working and I have patches
>> for gcc-4.5 too
>> for meta-oe too. I have repeatedly built core-image-sato and
>> core-image-minimal for uclibc/eglibc
>> but more coverage would be nicer.
>>
>> The patches are posted here
>>
>> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/misc
>>
>> I would appreciate any feedback or testing on this
>
> I got some errors while building gcc* recipes (overwriting header
> files in work-shared or something like that) but that's not new, gcc-4.6
> was failing the same - restarting build few times and it will succeed
> once.

hmm more details on this one would be better. May be its a bug in gcc
build system

>
> My minimal shr-lite-image compiles now fine and works on om-gta02
> (armv4t) sofar without segfaults.. so looks good.

nice

>
> For normal image and feeds I've few more recipes which are failing with gcc-4.7:
>
> meta-openembedded/meta-efl/recipes-efl/webkit/webkit-efl_svn.bb
>  | Unknown parameter a interfaceName for tags/attrs
>  | make[2]: *** [DerivedSources/WebCore/HTMLNames.cpp] Error 255
>  http://norman-schleicher.de/jenkins/job/shr-core-branches-om-gta02-shr-image/ws/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/webkit-efl-1.7.3+svnr105069-r1/
>  I'm upgrading this one instead of fixing it, because we had some
>  issues in runtime with current version, but new version needs newer
>  libsoup-2.4->glib-2.0->gobject-introspection->etc and fails with
>  different compilation issues.. so maybe if you know how to easily fix
>  it in current, we can, otherwise I'll continue to work on upgrade

I can surely provide you a fix once I look at sources. But seems  you
have more than one problems that may not be fixed. So upgrading has a
slight chance of fixing both of your issues and introducing many more
:) but lets try upgrade route and if then
we need 4.7 patch ping me.

>
>  BTW: similar fix as you did for webkit-gtk is in upstream r109509
>

Nice as long as the things are fixed I am happy.


> meta-oe/recipes-extended/mml-widget/gtkmathview_0.8.0.bb
>  ../../../src/frontend/common/TemplateBuilder.hh:54:42: error: redeclaration of 'SmartPtr<typename ElementBuilder::type> elem'
>  ../../../src/frontend/common/TemplateBuilder.hh:50:49: error: 'SmartPtr<typename ElementBuilder::type> elem' previously declared here
>  http://norman-schleicher.de/jenkins/job/shr-core-branches-om-gta02-shr-image/ws/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/gtkmathview-0.8.0-r1/
>
> meta-smartphone/meta-shr/recipes-shr/3rdparty/numptyphysics_svn.bb
>  fixed in shr branch

good


>
> meta-mozilla/recipes-mozilla/firefox/firefox_10.0.2.bb
>  | /var/lib/jenkins/jobs/shr-core-branches/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/firefox-10.0.2-r1/mozilla-release/ipc/chromium/src/base/file_util.cc:228:35: error: 'ftruncate' was not declared in this scope
>  probably easy to fix, adding Otavio to CC (maybe he has upgrade or fix
>  ready)
>

just #include <unistd.h> in ipc/chromium/src/base/file_util.cc should fix it

> Cheers,
>
> --
> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

Re: gcc 4.7 + mips64 architecture support

[Khem Raj]

On Thu, Apr 26, 2012 at 2:06 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Thu, 2012-04-26 at 20:30 +0100, Richard Purdie wrote:
>> On Thu, 2012-04-26 at 15:47 +0100, Richard Purdie wrote:
>> > On Wed, 2012-04-25 at 16:31 -0700, Khem Raj wrote:
>> > > Hello
>> > >
>> > > Now that release is almost out of door. I would like some eyes on the
>> > > gcc-4.7 work
>> > > and mips64 architecture support that I have done meanwhile
>> > >
>> > > I have made sure that gcc-4.6 still keeps working and I have patches
>> > > for gcc-4.5 too
>> > > for meta-oe too. I have repeatedly built core-image-sato and
>> > > core-image-minimal for uclibc/eglibc
>> > > but more coverage would be nicer.
>> > >
>> > > The patches are posted here
>> > >
>> > > http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/misc
>> > >
>> > > I would appreciate any feedback or testing on this
>> >
>> > I had a look through the patch series. I've posted an altered version of
>> > the class override patch. I've pulled the gcc 4.7 part into master-next,
>> > have get gcc 4.7 as the default and am running it though the
>> > autobuilder. That should see how we stand with our usual regression
>> > tests.
>>
>> The builds shows the following failures (I've kept duplication so you
>> can see the patterns). Not too bad considering:
>>
>> MACHINE=qemux86, failure in:
>> gst-ffmpeg:do_configure
>> http://autobuilder.yoctoproject.org:8010/builders/nightly-world/builds/66/steps/shell_24/logs/stdio
>>
>> MACHINE=qemuarm, failures in:
>> clutter-1.8:do_configure
>> glew:do_compile
>> qt4-x11-free:do_compile
>> http://autobuilder.yoctoproject.org:8010/builders/nightly-arm/builds/402/steps/shell_19/logs/stdio
>>
>> MACHINE=qemuppc, failures in:
>> clutter-1.8:do_configure
>> glew:do_compile
>> qt4-x11-free:do_compile
>> http://autobuilder.yoctoproject.org:8010/builders/nightly-ppc/builds/359/steps/shell_19/logs/stdio
>>
>> MACHINE=mpc8315e-rdb, failure in:
>> mesa-dri:do_compile
>> http://autobuilder.yoctoproject.org:8010/builders/nightly-ppc/builds/359/steps/shell_35/logs/stdio
>>
>> MACHINE=qemumips, failures in:
>> clutter-1.8:do_configure
>> glew:do_compile
>> http://autobuilder.yoctoproject.org:8010/builders/nightly-mips/builds/371/steps/shell_19/logs/stdio
>>
>> MACHINE=beagleboard, failure in:
>> mesa-dri:do_compile
>> http://autobuilder.yoctoproject.org:8010/builders/nightly-arm/builds/402/steps/shell_35/logs/stdio
>>
>> MACHINE=routerstationpro, failure in:
>> mesa-dri:do_compile
>> http://autobuilder.yoctoproject.org:8010/builders/nightly-mips/builds/371/steps/shell_35/logs/stdio
>>
>>
>> Also, adding meta-qt3 and building lsb targets with DISTRO=poky-lsb adds
>> the failure:
>> qt-x11-free:do_compile
>> <plus repeats of the above>
>> http://autobuilder.yoctoproject.org:8010/builders/nightly-ppc/builds/359/steps/shell_76/logs/stdio
>
> FWIW I've posted a mesa fix which should help many of these issue. It
> looks like gcc 4.7 has stricter option parsing.
>
> Why mesa didn't always fail to build is something that needs looking
> into as a separate issue, the logs are full of errors.

Do you some layer slapped on top of OE-Core which might be screwing
things up since I built using OE-Core standalone I do not remember
seeing these issues.

Re: gcc 4.7 + mips64 architecture support

[Martin Jansa]

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

On Sun, Apr 29, 2012 at 11:12:30AM +0200, Martin Jansa wrote:
> On Wed, Apr 25, 2012 at 04:31:53PM -0700, Khem Raj wrote:
> > Hello
> > 
> > Now that release is almost out of door. I would like some eyes on the
> > gcc-4.7 work
> > and mips64 architecture support that I have done meanwhile
> > 
> > I have made sure that gcc-4.6 still keeps working and I have patches
> > for gcc-4.5 too
> > for meta-oe too. I have repeatedly built core-image-sato and
> > core-image-minimal for uclibc/eglibc
> > but more coverage would be nicer.
> > 
> > The patches are posted here
> > 
> > http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/misc
> > 
> > I would appreciate any feedback or testing on this
> 
> I got some errors while building gcc* recipes (overwriting header 
> files in work-shared or something like that) but that's not new, gcc-4.6
> was failing the same - restarting build few times and it will succeed
> once.
> 
> My minimal shr-lite-image compiles now fine and works on om-gta02
> (armv4t) sofar without segfaults.. so looks good.
> 
> For normal image and feeds I've few more recipes which are failing with gcc-4.7:
> 
> meta-openembedded/meta-efl/recipes-efl/webkit/webkit-efl_svn.bb
>   | Unknown parameter a interfaceName for tags/attrs
>   | make[2]: *** [DerivedSources/WebCore/HTMLNames.cpp] Error 255
>   http://norman-schleicher.de/jenkins/job/shr-core-branches-om-gta02-shr-image/ws/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/webkit-efl-1.7.3+svnr105069-r1/
>   I'm upgrading this one instead of fixing it, because we had some
>   issues in runtime with current version, but new version needs newer
>   libsoup-2.4->glib-2.0->gobject-introspection->etc and fails with
>   different compilation issues.. so maybe if you know how to easily fix
>   it in current, we can, otherwise I'll continue to work on upgrade
> 
>   BTW: similar fix as you did for webkit-gtk is in upstream r109509

fixed, patch for meta-efl sent to oe-devel
> 
> meta-oe/recipes-extended/mml-widget/gtkmathview_0.8.0.bb
>   ../../../src/frontend/common/TemplateBuilder.hh:54:42: error: redeclaration of 'SmartPtr<typename ElementBuilder::type> elem'
>   ../../../src/frontend/common/TemplateBuilder.hh:50:49: error: 'SmartPtr<typename ElementBuilder::type> elem' previously declared here
>   http://norman-schleicher.de/jenkins/job/shr-core-branches-om-gta02-shr-image/ws/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/gtkmathview-0.8.0-r1/

fixed, patch for meta-efl sent to oe-devel

> meta-smartphone/meta-shr/recipes-shr/3rdparty/numptyphysics_svn.bb
>   fixed in shr branch
> 
> meta-mozilla/recipes-mozilla/firefox/firefox_10.0.2.bb
>   | /var/lib/jenkins/jobs/shr-core-branches/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/firefox-10.0.2-r1/mozilla-release/ipc/chromium/src/base/file_util.cc:228:35: error: 'ftruncate' was not declared in this scope
>   probably easy to fix, adding Otavio to CC (maybe he has upgrade or fix
>   ready)
> 
> Cheers,

I've found one more, which seems to happen only on x86(-64)
/OE/shr-core/meta-openembedded/meta-oe/recipes-multimedia/libav/libav_0.7.4.bb
/OE/shr-core/tmp-eglibc/work/x86_64-oe-linux/libav/libav-0.7.4-r4.0/git/libavcodec/x86/h264_qpel_mmx.c: Assembler messages:
/OE/shr-core/tmp-eglibc/work/x86_64-oe-linux/libav/libav-0.7.4-r4.0/git/libavcodec/x86/h264_qpel_mmx.c:1294: Error: operand type mismatch for `cmp'
/OE/shr-core/tmp-eglibc/work/x86_64-oe-linux/libav/libav-0.7.4-r4.0/git/libavcodec/x86/h264_qpel_mmx.c:1294: Error: operand type mismatch for `cmp'
/OE/shr-core/tmp-eglibc/work/x86_64-oe-linux/libav/libav-0.7.4-r4.0/git/libavcodec/x86/h264_qpel_mmx.c:1298: Error: operand type mismatch for `cmp'
/OE/shr-core/tmp-eglibc/work/x86_64-oe-linux/libav/libav-0.7.4-r4.0/git/libavcodec/x86/h264_qpel_mmx.c:1298: Error: operand type mismatch for `cmp'
/OE/shr-core/tmp-eglibc/work/x86_64-oe-linux/libav/libav-0.7.4-r4.0/git/libavcodec/x86/h264_qpel_mmx.c:964: Error: operand type mismatch for `cmp'
/OE/shr-core/tmp-eglibc/work/x86_64-oe-linux/libav/libav-0.7.4-r4.0/git/libavcodec/x86/h264_qpel_mmx.c:964: Error: operand type mismatch for `cmp'
/OE/shr-core/tmp-eglibc/work/x86_64-oe-linux/libav/libav-0.7.4-r4.0/git/libavcodec/x86/h264_qpel_mmx.c:964: Error: operand type mismatch for `cmp'

Cheers,

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: gcc 4.7 + mips64 architecture support

[Martin Jansa]

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

On Sun, Apr 29, 2012 at 08:36:05AM -0700, Khem Raj wrote:
> On Sun, Apr 29, 2012 at 2:12 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > On Wed, Apr 25, 2012 at 04:31:53PM -0700, Khem Raj wrote:
> >> Hello
> >>
> >> Now that release is almost out of door. I would like some eyes on the
> >> gcc-4.7 work
> >> and mips64 architecture support that I have done meanwhile
> >>
> >> I have made sure that gcc-4.6 still keeps working and I have patches
> >> for gcc-4.5 too
> >> for meta-oe too. I have repeatedly built core-image-sato and
> >> core-image-minimal for uclibc/eglibc
> >> but more coverage would be nicer.
> >>
> >> The patches are posted here
> >>
> >> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/misc
> >>
> >> I would appreciate any feedback or testing on this
> >
> > I got some errors while building gcc* recipes (overwriting header
> > files in work-shared or something like that) but that's not new, gcc-4.6
> > was failing the same - restarting build few times and it will succeed
> > once.
> 
> hmm more details on this one would be better. May be its a bug in gcc
> build system

I'll include log of our discussion on #yocto from yesterday:

20:56 < JaMa> khem: those gcc build issues are always about different constant or invalid file (expected } or something) so as I said before I believe it's some sort of race condition with parallel build in gcc or with parallel build of all those *gcc* recipes, but hard to reproduce because with second run it's usually gone
20:57 < khem> hmmm
20:57 < khem> JaMa: so the build fails saying what ?
20:57 < khem> first time
20:58 < JaMa> thanks to RP's fix I can at least rebuilt just the one which was failing instead of all *gcc* again
20:58 < JaMa> undeclared constant or expected } or something, I think each time the error is a bit different
20:58 < khem> JaMa: I have changed gcc-4.7 to avoid some overlappings which should help too
20:59 < khem> oh I see
20:59 < khem> that means a .h file is not generated yet and is being referenced or included
20:59 < khem> and you said its looking in srcdir ?
21:00 < JaMa> last time we talked about it, I've blamed do_headerfix because it was running in parallel with do_compile in some other *gcc* recipe
...
21:32 < JaMa> khem: I've found couple of old build logs with gcc failing http://build.shr-project.org/tests/jama/gcc-upgrade-issue/

Cheers,

> 
> >
> > My minimal shr-lite-image compiles now fine and works on om-gta02
> > (armv4t) sofar without segfaults.. so looks good.
> 
> nice
> 
> >
> > For normal image and feeds I've few more recipes which are failing with gcc-4.7:
> >
> > meta-openembedded/meta-efl/recipes-efl/webkit/webkit-efl_svn.bb
> >  | Unknown parameter a interfaceName for tags/attrs
> >  | make[2]: *** [DerivedSources/WebCore/HTMLNames.cpp] Error 255
> >  http://norman-schleicher.de/jenkins/job/shr-core-branches-om-gta02-shr-image/ws/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/webkit-efl-1.7.3+svnr105069-r1/
> >  I'm upgrading this one instead of fixing it, because we had some
> >  issues in runtime with current version, but new version needs newer
> >  libsoup-2.4->glib-2.0->gobject-introspection->etc and fails with
> >  different compilation issues.. so maybe if you know how to easily fix
> >  it in current, we can, otherwise I'll continue to work on upgrade
> 
> I can surely provide you a fix once I look at sources. But seems  you
> have more than one problems that may not be fixed. So upgrading has a
> slight chance of fixing both of your issues and introducing many more
> :) but lets try upgrade route and if then
> we need 4.7 patch ping me.
> 
> >
> >  BTW: similar fix as you did for webkit-gtk is in upstream r109509
> >
> 
> Nice as long as the things are fixed I am happy.
> 
> 
> > meta-oe/recipes-extended/mml-widget/gtkmathview_0.8.0.bb
> >  ../../../src/frontend/common/TemplateBuilder.hh:54:42: error: redeclaration of 'SmartPtr<typename ElementBuilder::type> elem'
> >  ../../../src/frontend/common/TemplateBuilder.hh:50:49: error: 'SmartPtr<typename ElementBuilder::type> elem' previously declared here
> >  http://norman-schleicher.de/jenkins/job/shr-core-branches-om-gta02-shr-image/ws/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/gtkmathview-0.8.0-r1/
> >
> > meta-smartphone/meta-shr/recipes-shr/3rdparty/numptyphysics_svn.bb
> >  fixed in shr branch
> 
> good
> 
> 
> >
> > meta-mozilla/recipes-mozilla/firefox/firefox_10.0.2.bb
> >  | /var/lib/jenkins/jobs/shr-core-branches/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/firefox-10.0.2-r1/mozilla-release/ipc/chromium/src/base/file_util.cc:228:35: error: 'ftruncate' was not declared in this scope
> >  probably easy to fix, adding Otavio to CC (maybe he has upgrade or fix
> >  ready)
> >
> 
> just #include <unistd.h> in ipc/chromium/src/base/file_util.cc should fix it
> 
> > Cheers,
> >
> > --
> > Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com
> >
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> >
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: gcc 4.7 + mips64 architecture support

[Khem Raj]

On Mon, Apr 30, 2012 at 3:43 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> I've found one more, which seems to happen only on x86(-64)
> /OE/shr-core/meta-openembedded/meta-oe/recipes-multimedia/libav/libav_0.7.4.bb
> /OE/shr-core/tmp-eglibc/work/x86_64-oe-linux/libav/libav-0.7.4-r4.0/git/libavcodec/x86/h264_qpel_mmx.c: Assembler messages:
> /OE/shr-core/tmp-eglibc/work/x86_64-oe-linux/libav/libav-0.7.4-r4.0/git/libavcodec/x86/h264_qpel_mmx.c:1294: Error: operand type mismatch for `cmp'
> /OE/shr-core/tmp-eglibc/work/x86_64-oe-linux/libav/libav-0.7.4-r4.0/git/libavcodec/x86/h264_qpel_mmx.c:1294: Error: operand type mismatch for `cmp'
> /OE/shr-core/tmp-eglibc/work/x86_64-oe-linux/libav/libav-0.7.4-r4.0/git/libavcodec/x86/h264_qpel_mmx.c:1298: Error: operand type mismatch for `cmp'
> /OE/shr-core/tmp-eglibc/work/x86_64-oe-linux/libav/libav-0.7.4-r4.0/git/libavcodec/x86/h264_qpel_mmx.c:1298: Error: operand type mismatch for `cmp'
> /OE/shr-core/tmp-eglibc/work/x86_64-oe-linux/libav/libav-0.7.4-r4.0/git/libavcodec/x86/h264_qpel_mmx.c:964: Error: operand type mismatch for `cmp'
> /OE/shr-core/tmp-eglibc/work/x86_64-oe-linux/libav/libav-0.7.4-r4.0/git/libavcodec/x86/h264_qpel_mmx.c:964: Error: operand type mismatch for `cmp'
> /OE/shr-core/tmp-eglibc/work/x86_64-oe-linux/libav/libav-0.7.4-r4.0/git/libavcodec/x86/h264_qpel_mmx.c:964: Error: operand type mismatch for `cmp'

port the below commit from OE-Core/master

commit 1161c40a26146629613bd6a17b263175a492b751
Author: Khem Raj <raj.khem@gmail.com>
Date:   Fri Mar 30 12:07:39 2012 -0700

    gst-ffmpeg: Fix build with gcc 4.7

    A cmp instruction with two constants is invalid, therefore 'g' constraint
    is not correct but must be "rm" instead.

    Signed-off-by: Khem Raj <raj.khem@gmail.com>
    Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Re: gcc 4.7 + mips64 architecture support

[Martin Jansa]

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

On Mon, Apr 30, 2012 at 07:15:11AM -0700, Khem Raj wrote:
> On Mon, Apr 30, 2012 at 3:43 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > I've found one more, which seems to happen only on x86(-64)
> > /OE/shr-core/meta-openembedded/meta-oe/recipes-multimedia/libav/libav_0.7.4.bb
> > /OE/shr-core/tmp-eglibc/work/x86_64-oe-linux/libav/libav-0.7.4-r4.0/git/libavcodec/x86/h264_qpel_mmx.c: Assembler messages:
> > /OE/shr-core/tmp-eglibc/work/x86_64-oe-linux/libav/libav-0.7.4-r4.0/git/libavcodec/x86/h264_qpel_mmx.c:1294: Error: operand type mismatch for `cmp'
> > /OE/shr-core/tmp-eglibc/work/x86_64-oe-linux/libav/libav-0.7.4-r4.0/git/libavcodec/x86/h264_qpel_mmx.c:1294: Error: operand type mismatch for `cmp'
> > /OE/shr-core/tmp-eglibc/work/x86_64-oe-linux/libav/libav-0.7.4-r4.0/git/libavcodec/x86/h264_qpel_mmx.c:1298: Error: operand type mismatch for `cmp'
> > /OE/shr-core/tmp-eglibc/work/x86_64-oe-linux/libav/libav-0.7.4-r4.0/git/libavcodec/x86/h264_qpel_mmx.c:1298: Error: operand type mismatch for `cmp'
> > /OE/shr-core/tmp-eglibc/work/x86_64-oe-linux/libav/libav-0.7.4-r4.0/git/libavcodec/x86/h264_qpel_mmx.c:964: Error: operand type mismatch for `cmp'
> > /OE/shr-core/tmp-eglibc/work/x86_64-oe-linux/libav/libav-0.7.4-r4.0/git/libavcodec/x86/h264_qpel_mmx.c:964: Error: operand type mismatch for `cmp'
> > /OE/shr-core/tmp-eglibc/work/x86_64-oe-linux/libav/libav-0.7.4-r4.0/git/libavcodec/x86/h264_qpel_mmx.c:964: Error: operand type mismatch for `cmp'
> 
> port the below commit from OE-Core/master
> 
> commit 1161c40a26146629613bd6a17b263175a492b751
> Author: Khem Raj <raj.khem@gmail.com>
> Date:   Fri Mar 30 12:07:39 2012 -0700
> 
>     gst-ffmpeg: Fix build with gcc 4.7
> 
>     A cmp instruction with two constants is invalid, therefore 'g' constraint
>     is not correct but must be "rm" instead.
> 
>     Signed-off-by: Khem Raj <raj.khem@gmail.com>
>     Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Thanks, works, done in meta-oe-contrib/jansa/test

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: gcc 4.7 + mips64 architecture support

[Richard Purdie]

On Sun, 2012-04-29 at 10:23 -0700, Khem Raj wrote:
> On Thu, Apr 26, 2012 at 2:06 PM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > On Thu, 2012-04-26 at 20:30 +0100, Richard Purdie wrote:
> >> On Thu, 2012-04-26 at 15:47 +0100, Richard Purdie wrote:
> >> > On Wed, 2012-04-25 at 16:31 -0700, Khem Raj wrote:
> >> > > Hello
> >> > >
> >> > > Now that release is almost out of door. I would like some eyes on the
> >> > > gcc-4.7 work
> >> > > and mips64 architecture support that I have done meanwhile
> >> > >
> >> > > I have made sure that gcc-4.6 still keeps working and I have patches
> >> > > for gcc-4.5 too
> >> > > for meta-oe too. I have repeatedly built core-image-sato and
> >> > > core-image-minimal for uclibc/eglibc
> >> > > but more coverage would be nicer.
> >> > >
> >> > > The patches are posted here
> >> > >
> >> > > http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/misc
> >> > >
> >> > > I would appreciate any feedback or testing on this
> >> >
> >> > I had a look through the patch series. I've posted an altered version of
> >> > the class override patch. I've pulled the gcc 4.7 part into master-next,
> >> > have get gcc 4.7 as the default and am running it though the
> >> > autobuilder. That should see how we stand with our usual regression
> >> > tests.
> >>
> >> The builds shows the following failures (I've kept duplication so you
> >> can see the patterns). Not too bad considering:
> >>
> >> MACHINE=qemux86, failure in:
> >> gst-ffmpeg:do_configure
> >> http://autobuilder.yoctoproject.org:8010/builders/nightly-world/builds/66/steps/shell_24/logs/stdio
> >>
> >> MACHINE=qemuarm, failures in:
> >> clutter-1.8:do_configure
> >> glew:do_compile
> >> qt4-x11-free:do_compile
> >> http://autobuilder.yoctoproject.org:8010/builders/nightly-arm/builds/402/steps/shell_19/logs/stdio
> >>
> >> MACHINE=qemuppc, failures in:
> >> clutter-1.8:do_configure
> >> glew:do_compile
> >> qt4-x11-free:do_compile
> >> http://autobuilder.yoctoproject.org:8010/builders/nightly-ppc/builds/359/steps/shell_19/logs/stdio
> >>
> >> MACHINE=mpc8315e-rdb, failure in:
> >> mesa-dri:do_compile
> >> http://autobuilder.yoctoproject.org:8010/builders/nightly-ppc/builds/359/steps/shell_35/logs/stdio
> >>
> >> MACHINE=qemumips, failures in:
> >> clutter-1.8:do_configure
> >> glew:do_compile
> >> http://autobuilder.yoctoproject.org:8010/builders/nightly-mips/builds/371/steps/shell_19/logs/stdio
> >>
> >> MACHINE=beagleboard, failure in:
> >> mesa-dri:do_compile
> >> http://autobuilder.yoctoproject.org:8010/builders/nightly-arm/builds/402/steps/shell_35/logs/stdio
> >>
> >> MACHINE=routerstationpro, failure in:
> >> mesa-dri:do_compile
> >> http://autobuilder.yoctoproject.org:8010/builders/nightly-mips/builds/371/steps/shell_35/logs/stdio
> >>
> >>
> >> Also, adding meta-qt3 and building lsb targets with DISTRO=poky-lsb adds
> >> the failure:
> >> qt-x11-free:do_compile
> >> <plus repeats of the above>
> >> http://autobuilder.yoctoproject.org:8010/builders/nightly-ppc/builds/359/steps/shell_76/logs/stdio
> >
> > FWIW I've posted a mesa fix which should help many of these issue. It
> > looks like gcc 4.7 has stricter option parsing.
> >
> > Why mesa didn't always fail to build is something that needs looking
> > into as a separate issue, the logs are full of errors.
> 
> Do you some layer slapped on top of OE-Core which might be screwing
> things up since I built using OE-Core standalone I do not remember
> seeing these issues.

These mostly turned out to be due to issues with the mesa x32 patch in
OE-Core and would only show up on an x86_64 host. I added a fix for
this.

FWIW, gcc 4.7 and eglibc 2.15 are now the default in master. Test builds
were looking good until the autobuilder ran out of disk space on the
shared drive for sstate :(.

Only known unresolved failure so far is "DISTRO=poky-tiny bitbake
eglibc" which fails due to its cut down eglibc options.

Cheers,

Richard

Re: gcc 4.7 + mips64 architecture support

[Khem Raj]

On Mon, Apr 30, 2012 at 7:41 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Sun, 2012-04-29 at 10:23 -0700, Khem Raj wrote:
>> On Thu, Apr 26, 2012 at 2:06 PM, Richard Purdie
>> <richard.purdie@linuxfoundation.org> wrote:
>> > On Thu, 2012-04-26 at 20:30 +0100, Richard Purdie wrote:
>> >> On Thu, 2012-04-26 at 15:47 +0100, Richard Purdie wrote:
>> >> > On Wed, 2012-04-25 at 16:31 -0700, Khem Raj wrote:
>> >> > > Hello
>> >> > >
>> >> > > Now that release is almost out of door. I would like some eyes on the
>> >> > > gcc-4.7 work
>> >> > > and mips64 architecture support that I have done meanwhile
>> >> > >
>> >> > > I have made sure that gcc-4.6 still keeps working and I have patches
>> >> > > for gcc-4.5 too
>> >> > > for meta-oe too. I have repeatedly built core-image-sato and
>> >> > > core-image-minimal for uclibc/eglibc
>> >> > > but more coverage would be nicer.
>> >> > >
>> >> > > The patches are posted here
>> >> > >
>> >> > > http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/misc
>> >> > >
>> >> > > I would appreciate any feedback or testing on this
>> >> >
>> >> > I had a look through the patch series. I've posted an altered version of
>> >> > the class override patch. I've pulled the gcc 4.7 part into master-next,
>> >> > have get gcc 4.7 as the default and am running it though the
>> >> > autobuilder. That should see how we stand with our usual regression
>> >> > tests.
>> >>
>> >> The builds shows the following failures (I've kept duplication so you
>> >> can see the patterns). Not too bad considering:
>> >>
>> >> MACHINE=qemux86, failure in:
>> >> gst-ffmpeg:do_configure
>> >> http://autobuilder.yoctoproject.org:8010/builders/nightly-world/builds/66/steps/shell_24/logs/stdio
>> >>
>> >> MACHINE=qemuarm, failures in:
>> >> clutter-1.8:do_configure
>> >> glew:do_compile
>> >> qt4-x11-free:do_compile
>> >> http://autobuilder.yoctoproject.org:8010/builders/nightly-arm/builds/402/steps/shell_19/logs/stdio
>> >>
>> >> MACHINE=qemuppc, failures in:
>> >> clutter-1.8:do_configure
>> >> glew:do_compile
>> >> qt4-x11-free:do_compile
>> >> http://autobuilder.yoctoproject.org:8010/builders/nightly-ppc/builds/359/steps/shell_19/logs/stdio
>> >>
>> >> MACHINE=mpc8315e-rdb, failure in:
>> >> mesa-dri:do_compile
>> >> http://autobuilder.yoctoproject.org:8010/builders/nightly-ppc/builds/359/steps/shell_35/logs/stdio
>> >>
>> >> MACHINE=qemumips, failures in:
>> >> clutter-1.8:do_configure
>> >> glew:do_compile
>> >> http://autobuilder.yoctoproject.org:8010/builders/nightly-mips/builds/371/steps/shell_19/logs/stdio
>> >>
>> >> MACHINE=beagleboard, failure in:
>> >> mesa-dri:do_compile
>> >> http://autobuilder.yoctoproject.org:8010/builders/nightly-arm/builds/402/steps/shell_35/logs/stdio
>> >>
>> >> MACHINE=routerstationpro, failure in:
>> >> mesa-dri:do_compile
>> >> http://autobuilder.yoctoproject.org:8010/builders/nightly-mips/builds/371/steps/shell_35/logs/stdio
>> >>
>> >>
>> >> Also, adding meta-qt3 and building lsb targets with DISTRO=poky-lsb adds
>> >> the failure:
>> >> qt-x11-free:do_compile
>> >> <plus repeats of the above>
>> >> http://autobuilder.yoctoproject.org:8010/builders/nightly-ppc/builds/359/steps/shell_76/logs/stdio
>> >
>> > FWIW I've posted a mesa fix which should help many of these issue. It
>> > looks like gcc 4.7 has stricter option parsing.
>> >
>> > Why mesa didn't always fail to build is something that needs looking
>> > into as a separate issue, the logs are full of errors.
>>
>> Do you some layer slapped on top of OE-Core which might be screwing
>> things up since I built using OE-Core standalone I do not remember
>> seeing these issues.
>
> These mostly turned out to be due to issues with the mesa x32 patch in
> OE-Core and would only show up on an x86_64 host. I added a fix for
> this.
>
> FWIW, gcc 4.7 and eglibc 2.15 are now the default in master.

yay

 Test builds
> were looking good until the autobuilder ran out of disk space on the
> shared drive for sstate :(.

hopefully nothing new shows up

>
> Only known unresolved failure so far is "DISTRO=poky-tiny bitbake
> eglibc" which fails due to its cut down eglibc options.
>

hmmm. Whats the error ?

> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: gcc 4.7 + mips64 architecture support

[Richard Purdie]

On Mon, 2012-04-30 at 07:47 -0700, Khem Raj wrote:
> On Mon, Apr 30, 2012 at 7:41 AM, Richard Purdie
> > FWIW, gcc 4.7 and eglibc 2.15 are now the default in master.
> 
> yay
> 
>  Test builds
> > were looking good until the autobuilder ran out of disk space on the
> > shared drive for sstate :(.
> 
> hopefully nothing new shows up
> 
> >
> > Only known unresolved failure so far is "DISTRO=poky-tiny bitbake
> > eglibc" which fails due to its cut down eglibc options.
> >
> 
> hmmm. Whats the error ?

http://autobuilder.yoctoproject.org:8010/builders/nightly-tiny/builds/42/steps/shell_24/logs/stdio

Cheers,

Richard

Re: gcc 4.7 + mips64 architecture support

[Khem Raj]

On Mon, Apr 30, 2012 at 7:53 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>> hmmm. Whats the error ?
>
> http://autobuilder.yoctoproject.org:8010/builders/nightly-tiny/builds/42/steps/shell_24/logs/stdio

that should not happen. Its seems to be issue in eglibc option group
handling somehow its asking for regexp which should be isolated in
option groups

Did this work fine with 4.6 ?

Re: gcc 4.7 + mips64 architecture support

[Mark Hatle]

On 4/30/12 9:59 AM, Khem Raj wrote:
> On Mon, Apr 30, 2012 at 7:53 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org>  wrote:
>>> hmmm. Whats the error ?
>>
>> http://autobuilder.yoctoproject.org:8010/builders/nightly-tiny/builds/42/steps/shell_24/logs/stdio
>
> that should not happen. Its seems to be issue in eglibc option group
> handling somehow its asking for regexp which should be isolated in
> option groups
>
> Did this work fine with 4.6 ?

If this is reproducable outside of the build system.. (I suspect it is), we 
should mention this on the eglibc mailing list and see if they have any 
suggestions.  I wouldn't be surprised if a bug has crept into the configuration 
settings of eglibc.

--Mark

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

Re: gcc 4.7 + mips64 architecture support

[Richard Purdie]

On Mon, 2012-04-30 at 07:59 -0700, Khem Raj wrote:
> On Mon, Apr 30, 2012 at 7:53 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> >> hmmm. Whats the error ?
> >
> > http://autobuilder.yoctoproject.org:8010/builders/nightly-tiny/builds/42/steps/shell_24/logs/stdio
> 
> that should not happen. Its seems to be issue in eglibc option group
> handling somehow its asking for regexp which should be isolated in
> option groups
> 
> Did this work fine with 4.6 ?

Yes, it worked fine with 4.7 too. Only when we changed eglibc 2.13 ->
2.15 did it show up.

Cheers,

Richard

Re: gcc 4.7 + mips64 architecture support

[Khem Raj]

On Mon, Apr 30, 2012 at 8:39 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Mon, 2012-04-30 at 07:59 -0700, Khem Raj wrote:
>> On Mon, Apr 30, 2012 at 7:53 AM, Richard Purdie
>> <richard.purdie@linuxfoundation.org> wrote:
>> >> hmmm. Whats the error ?
>> >
>> > http://autobuilder.yoctoproject.org:8010/builders/nightly-tiny/builds/42/steps/shell_24/logs/stdio
>>
>> that should not happen. Its seems to be issue in eglibc option group
>> handling somehow its asking for regexp which should be isolated in
>> option groups
>>
>> Did this work fine with 4.6 ?
>
> Yes, it worked fine with 4.7 too. Only when we changed eglibc 2.13 ->
> 2.15 did it show up.

ah definitely a eglibc config issue here. I will take a look at it.

Re: gcc 4.7 + mips64 architecture support

[Martin Jansa]

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

On Sun, Apr 29, 2012 at 11:12:30AM +0200, Martin Jansa wrote:
> On Wed, Apr 25, 2012 at 04:31:53PM -0700, Khem Raj wrote:
> > Hello
> > 
> > Now that release is almost out of door. I would like some eyes on the
> > gcc-4.7 work
> > and mips64 architecture support that I have done meanwhile
> > 
> > I have made sure that gcc-4.6 still keeps working and I have patches
> > for gcc-4.5 too
> > for meta-oe too. I have repeatedly built core-image-sato and
> > core-image-minimal for uclibc/eglibc
> > but more coverage would be nicer.
> > 
> > The patches are posted here
> > 
> > http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/misc
> > 
> > I would appreciate any feedback or testing on this
> 
> I got some errors while building gcc* recipes (overwriting header 
> files in work-shared or something like that) but that's not new, gcc-4.6
> was failing the same - restarting build few times and it will succeed
> once.
> 
> My minimal shr-lite-image compiles now fine and works on om-gta02
> (armv4t) sofar without segfaults.. so looks good.
> 
> For normal image and feeds I've few more recipes which are failing with gcc-4.7:
> 
> meta-openembedded/meta-efl/recipes-efl/webkit/webkit-efl_svn.bb
>   | Unknown parameter a interfaceName for tags/attrs
>   | make[2]: *** [DerivedSources/WebCore/HTMLNames.cpp] Error 255
>   http://norman-schleicher.de/jenkins/job/shr-core-branches-om-gta02-shr-image/ws/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/webkit-efl-1.7.3+svnr105069-r1/
>   I'm upgrading this one instead of fixing it, because we had some
>   issues in runtime with current version, but new version needs newer
>   libsoup-2.4->glib-2.0->gobject-introspection->etc and fails with
>   different compilation issues.. so maybe if you know how to easily fix
>   it in current, we can, otherwise I'll continue to work on upgrade
> 
>   BTW: similar fix as you did for webkit-gtk is in upstream r109509
> 
> meta-oe/recipes-extended/mml-widget/gtkmathview_0.8.0.bb
>   ../../../src/frontend/common/TemplateBuilder.hh:54:42: error: redeclaration of 'SmartPtr<typename ElementBuilder::type> elem'
>   ../../../src/frontend/common/TemplateBuilder.hh:50:49: error: 'SmartPtr<typename ElementBuilder::type> elem' previously declared here
>   http://norman-schleicher.de/jenkins/job/shr-core-branches-om-gta02-shr-image/ws/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/gtkmathview-0.8.0-r1/
> 
> meta-smartphone/meta-shr/recipes-shr/3rdparty/numptyphysics_svn.bb
>   fixed in shr branch
> 
> meta-mozilla/recipes-mozilla/firefox/firefox_10.0.2.bb
>   | /var/lib/jenkins/jobs/shr-core-branches/workspace/shr-core/tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/firefox-10.0.2-r1/mozilla-release/ipc/chromium/src/base/file_util.cc:228:35: error: 'ftruncate' was not declared in this scope
>   probably easy to fix, adding Otavio to CC (maybe he has upgrade or fix
>   ready)

there were 4 more issues, but fixed and pull request sent on github from
https://github.com/shr-project/meta-mozilla/commits/fixes

Cheers,

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]