configure error for glibc 2.25.2

configure error for glibc 2.25.2

[Andrew Goodbody]

I get the following configure error when trying to rebuild my tree today after doing a sync.

Is this a core issue or something wrong in my tree?

Thanks,
Andrew

| checking installed Linux kernel header files... missing or too old!
| configure: error: GNU libc requires kernel header files from
| Linux 3.2.0 or later to be installed before configuring.
| The kernel header files are found usually in /usr/include/asm and
| /usr/include/linux; make sure these directories use files from
| Linux 3.2.0 or later.  This check uses <linux/version.h>, so
| make sure that file was built correctly when installing the kernel header
| files.  To use kernel headers not from /usr/include/linux, use the
| configure option --with-headers.
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_configure (log file is located at /home/andrew/src/camol3/camol/build/tmp-camol-glibc/work/armv7ahf-neon-camol-linux-gnueabi/glibc-initial/2.25-r0/temp/log.do_configure.30873)
ERROR: Task (/home/andrew/src/camol3/camol/layers/openembedded-core/meta/recipes-core/glibc/glibc-initial_2.25.bb:do_configure) failed with exit code '1'
NOTE: Tasks Summary: Attempted 779 tasks of which 0 didn't need to be rerun and 1 failed.
NOTE: Writing buildhistory

Summary: 1 task failed:
  /home/andrew/src/camol3/camol/layers/openembedded-core/meta/recipes-core/glibc/glibc-initial_2.25.bb:do_configure
Summary: There were 7 WARNING messages shown.
Summary: There was 1 ERROR message shown, returning a non-zero exit code.

Re: configure error for glibc 2.25.2

[Marko Lindqvist]

 Probably unrelated, but glibc people were hoping autoconf-2.70
release before they release glibc-2.25 as post-2.24 glibc configure
has some problem post-2.69 autoconf would resolve. I don't know if
they have managed to work around their issue some other way when
autoconf release has still failed to materialize (it was half-promised
by the end of year 2016)


 - ML


On 24 January 2017 at 16:07, Andrew Goodbody
<andrew.goodbody@cambrionix.com> wrote:
> I get the following configure error when trying to rebuild my tree today after doing a sync.
>
> Is this a core issue or something wrong in my tree?
>
> Thanks,
> Andrew
>
> | checking installed Linux kernel header files... missing or too old!
> | configure: error: GNU libc requires kernel header files from
> | Linux 3.2.0 or later to be installed before configuring.
> | The kernel header files are found usually in /usr/include/asm and
> | /usr/include/linux; make sure these directories use files from
> | Linux 3.2.0 or later.  This check uses <linux/version.h>, so
> | make sure that file was built correctly when installing the kernel header
> | files.  To use kernel headers not from /usr/include/linux, use the
> | configure option --with-headers.
> | WARNING: exit code 1 from a shell command.
> | ERROR: Function failed: do_configure (log file is located at /home/andrew/src/camol3/camol/build/tmp-camol-glibc/work/armv7ahf-neon-camol-linux-gnueabi/glibc-initial/2.25-r0/temp/log.do_configure.30873)
> ERROR: Task (/home/andrew/src/camol3/camol/layers/openembedded-core/meta/recipes-core/glibc/glibc-initial_2.25.bb:do_configure) failed with exit code '1'
> NOTE: Tasks Summary: Attempted 779 tasks of which 0 didn't need to be rerun and 1 failed.
> NOTE: Writing buildhistory
>
> Summary: 1 task failed:
>   /home/andrew/src/camol3/camol/layers/openembedded-core/meta/recipes-core/glibc/glibc-initial_2.25.bb:do_configure
> Summary: There were 7 WARNING messages shown.
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: configure error for glibc 2.25.2

[Andrew Goodbody]

Further to this I see the following message in log.do_prepare_recipe_sysroot.20511

WARNING: Manifest /home/andrew/src/camol3/camol/build/tmp-camol-glibc/sstate-control/manifest-allarch-linux-libc-headers.populate_sysroot not found?

Which is quite correct as that file does not exist, however the following file does exist

/home/andrew/src/camol3/camol/build/tmp-camol-glibc/sstate-control/manifest-armv7at2hf-neon-linux-libc-headers.populate_sysroot

So it looks like linux-libc-headers is not being installed in the recipe sysroot because it is looking for the manifest with the wrong arch.

Anyone know what could be going wrong here?

Andrew

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> I get the following configure error when trying to rebuild my tree today after
> doing a sync.
> 
> Is this a core issue or something wrong in my tree?
> 
> Thanks,
> Andrew
> 
> | checking installed Linux kernel header files... missing or too old!
> | configure: error: GNU libc requires kernel header files from
> | Linux 3.2.0 or later to be installed before configuring.
> | The kernel header files are found usually in /usr/include/asm and
> | /usr/include/linux; make sure these directories use files from
> | Linux 3.2.0 or later.  This check uses <linux/version.h>, so
> | make sure that file was built correctly when installing the kernel header
> | files.  To use kernel headers not from /usr/include/linux, use the
> | configure option --with-headers.
> | WARNING: exit code 1 from a shell command.
> | ERROR: Function failed: do_configure (log file is located at
> /home/andrew/src/camol3/camol/build/tmp-camol-glibc/work/armv7ahf-
> neon-camol-linux-gnueabi/glibc-initial/2.25-
> r0/temp/log.do_configure.30873)
> ERROR: Task (/home/andrew/src/camol3/camol/layers/openembedded-
> core/meta/recipes-core/glibc/glibc-initial_2.25.bb:do_configure) failed with
> exit code '1'
> NOTE: Tasks Summary: Attempted 779 tasks of which 0 didn't need to be
> rerun and 1 failed.
> NOTE: Writing buildhistory
> 
> Summary: 1 task failed:
>   /home/andrew/src/camol3/camol/layers/openembedded-
> core/meta/recipes-core/glibc/glibc-initial_2.25.bb:do_configure
> Summary: There were 7 WARNING messages shown.
> Summary: There was 1 ERROR message shown, returning a non-zero exit
> code.
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: configure error for glibc 2.25.2

[Richard Purdie]

On Tue, 2017-01-24 at 15:59 +0000, Andrew Goodbody wrote:
> Further to this I see the following message in
> log.do_prepare_recipe_sysroot.20511
> 
> WARNING: Manifest /home/andrew/src/camol3/camol/build/tmp-camol-
> glibc/sstate-control/manifest-allarch-linux-libc-
> headers.populate_sysroot not found?
> 
> Which is quite correct as that file does not exist, however the
> following file does exist
> 
> /home/andrew/src/camol3/camol/build/tmp-camol-glibc/sstate-
> control/manifest-armv7at2hf-neon-linux-libc-headers.populate_sysroot
> 
> So it looks like linux-libc-headers is not being installed in the
> recipe sysroot because it is looking for the manifest with the wrong
> arch.
> 
> Anyone know what could be going wrong here?

Short answer is yes.

Your configuration is mixing different tune/package architectures and
is confusing recipe specific sysroots (armv7ahf-neon != armv7at2hf-
neon), looks like thumb and non-thumb. 

I believe I have a patch which I'll send shortly as I've been chasing
this in other circumstances.

Cheers,

Richard

Re: configure error for glibc 2.25.2

[Andrew Goodbody]

> From: Richard Purdie [mailto:richard.purdie@linuxfoundation.org]
> On Tue, 2017-01-24 at 15:59 +0000, Andrew Goodbody wrote:
> > Further to this I see the following message in
> > log.do_prepare_recipe_sysroot.20511
> >
> > WARNING: Manifest /home/andrew/src/camol3/camol/build/tmp-camol-
> > glibc/sstate-control/manifest-allarch-linux-libc-
> > headers.populate_sysroot not found?
> >
> > Which is quite correct as that file does not exist, however the
> > following file does exist
> >
> > /home/andrew/src/camol3/camol/build/tmp-camol-glibc/sstate-
> > control/manifest-armv7at2hf-neon-linux-libc-headers.populate_sysroot
> >
> > So it looks like linux-libc-headers is not being installed in the
> > recipe sysroot because it is looking for the manifest with the wrong
> > arch.
> >
> > Anyone know what could be going wrong here?
> 
> Short answer is yes.
> 
> Your configuration is mixing different tune/package architectures and
> is confusing recipe specific sysroots (armv7ahf-neon != armv7at2hf-
> neon), looks like thumb and non-thumb.

Yes that sounds about right. This build started off as a BeagleBone Black clone some years ago. The differing tune architectures I think appeared when I moved from soft-float to hard-float. I guess I should have looked into what was causing that at the time. Everything seemed to work OK, so I did not worry.

> I believe I have a patch which I'll send shortly as I've been chasing
> this in other circumstances.

That would be awesome, thanks.

Andrew

> Cheers,
> 
> Richard

Re: configure error for glibc 2.25.2

[Richard Purdie]

On Tue, 2017-01-24 at 17:14 +0000, Andrew Goodbody wrote:
> > 
> > From: Richard Purdie [mailto:richard.purdie@linuxfoundation.org]
> > On Tue, 2017-01-24 at 15:59 +0000, Andrew Goodbody wrote:
> > > 
> > > Further to this I see the following message in
> > > log.do_prepare_recipe_sysroot.20511
> > > 
> > > WARNING: Manifest /home/andrew/src/camol3/camol/build/tmp-camol-
> > > glibc/sstate-control/manifest-allarch-linux-libc-
> > > headers.populate_sysroot not found?
> > > 
> > > Which is quite correct as that file does not exist, however the
> > > following file does exist
> > > 
> > > /home/andrew/src/camol3/camol/build/tmp-camol-glibc/sstate-
> > > control/manifest-armv7at2hf-neon-linux-libc-
> > > headers.populate_sysroot
> > > 
> > > So it looks like linux-libc-headers is not being installed in the
> > > recipe sysroot because it is looking for the manifest with the
> > > wrong
> > > arch.
> > > 
> > > Anyone know what could be going wrong here?
> > Short answer is yes.
> > 
> > Your configuration is mixing different tune/package architectures
> > and
> > is confusing recipe specific sysroots (armv7ahf-neon != armv7at2hf-
> > neon), looks like thumb and non-thumb.
> Yes that sounds about right. This build started off as a BeagleBone
> Black clone some years ago. The differing tune architectures I think
> appeared when I moved from soft-float to hard-float. I guess I should
> have looked into what was causing that at the time. Everything seemed
> to work OK, so I did not worry.
> 
> > 
> > I believe I have a patch which I'll send shortly as I've been
> > chasing
> > this in other circumstances.
> That would be awesome, thanks.

I'm running out of time to write this up and post properly but the
patch I think should work is this:

http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip-rss&id=414a75521f5d5dfb50385abab052f87dbc88f1c1

("staging: Remove hardcoded PACKAGE_ARCHS from the class" in case I rebase it)

I will get this cleaned up and sent soon.

Cheers,

Richard

Re: configure error for glibc 2.25.2

[Andrew Goodbody]

> From: Richard Purdie [mailto:richard.purdie@linuxfoundation.org]
> On Tue, 2017-01-24 at 17:14 +0000, Andrew Goodbody wrote:
> > >
> > > From: Richard Purdie [mailto:richard.purdie@linuxfoundation.org]
> > > On Tue, 2017-01-24 at 15:59 +0000, Andrew Goodbody wrote:
> > > >
> > > > Further to this I see the following message in
> > > > log.do_prepare_recipe_sysroot.20511
> > > >
> > > > WARNING: Manifest /home/andrew/src/camol3/camol/build/tmp-
> camol-
> > > > glibc/sstate-control/manifest-allarch-linux-libc-
> > > > headers.populate_sysroot not found?
> > > >
> > > > Which is quite correct as that file does not exist, however the
> > > > following file does exist
> > > >
> > > > /home/andrew/src/camol3/camol/build/tmp-camol-glibc/sstate-
> > > > control/manifest-armv7at2hf-neon-linux-libc-
> > > > headers.populate_sysroot
> > > >
> > > > So it looks like linux-libc-headers is not being installed in the
> > > > recipe sysroot because it is looking for the manifest with the
> > > > wrong
> > > > arch.
> > > >
> > > > Anyone know what could be going wrong here?
> > > Short answer is yes.
> > >
> > > Your configuration is mixing different tune/package architectures
> > > and
> > > is confusing recipe specific sysroots (armv7ahf-neon != armv7at2hf-
> > > neon), looks like thumb and non-thumb.
> > Yes that sounds about right. This build started off as a BeagleBone
> > Black clone some years ago. The differing tune architectures I think
> > appeared when I moved from soft-float to hard-float. I guess I should
> > have looked into what was causing that at the time. Everything seemed
> > to work OK, so I did not worry.
> >
> > >
> > > I believe I have a patch which I'll send shortly as I've been
> > > chasing
> > > this in other circumstances.
> > That would be awesome, thanks.
> 
> I'm running out of time to write this up and post properly but the
> patch I think should work is this:
> 
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip-
> rss&id=414a75521f5d5dfb50385abab052f87dbc88f1c1
> 
> ("staging: Remove hardcoded PACKAGE_ARCHS from the class" in case I
> rebase it)
> 
> I will get this cleaned up and sent soon.

Thanks but unfortunately that did not work for me.

I did a cleanall on glibc before trying to build it, but the result was the same.

Andrew

Re: configure error for glibc 2.25.2

[Richard Purdie]

On Tue, 2017-01-24 at 18:08 +0000, Andrew Goodbody wrote:
> > 
> > From: Richard Purdie [mailto:richard.purdie@linuxfoundation.org]
> > I'm running out of time to write this up and post properly but the
> > patch I think should work is this:
> > 
> > http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie
> > /wip-
> > rss&id=414a75521f5d5dfb50385abab052f87dbc88f1c1
> > 
> > ("staging: Remove hardcoded PACKAGE_ARCHS from the class" in case I
> > rebase it)
> > 
> > I will get this cleaned up and sent soon.
> Thanks but unfortunately that did not work for me.
> 
> I did a cleanall on glibc before trying to build it, but the result
> was the same.

Try a "bitbake glibc-initial -c clean"?

Cheers,

Richard

Re: configure error for glibc 2.25.2

[Andrew Goodbody]

> From: Richard Purdie [mailto:richard.purdie@linuxfoundation.org]
> On Tue, 2017-01-24 at 18:08 +0000, Andrew Goodbody wrote:
> > >
> > > From: Richard Purdie [mailto:richard.purdie@linuxfoundation.org]
> > > I'm running out of time to write this up and post properly but the
> > > patch I think should work is this:
> > >
> > > http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie
> > > /wip-
> > > rss&id=414a75521f5d5dfb50385abab052f87dbc88f1c1
> > >
> > > ("staging: Remove hardcoded PACKAGE_ARCHS from the class" in case I
> > > rebase it)
> > >
> > > I will get this cleaned up and sent soon.
> > Thanks but unfortunately that did not work for me.
> >
> > I did a cleanall on glibc before trying to build it, but the result
> > was the same.
> 
> Try a "bitbake glibc-initial -c clean"?

Sorry, it was glibc-initial that I ran the cleanall on, so just clean makes no difference.

Andrew

Re: configure error for glibc 2.25.2

[Richard Purdie]

On Wed, 2017-01-25 at 09:56 +0000, Andrew Goodbody wrote:
> > 
> > From: Richard Purdie [mailto:richard.purdie@linuxfoundation.org]
> > On Tue, 2017-01-24 at 18:08 +0000, Andrew Goodbody wrote:
> > > 
> > > Thanks but unfortunately that did not work for me.
> > > 
> > > I did a cleanall on glibc before trying to build it, but the
> > > result
> > > was the same.
> > Try a "bitbake glibc-initial -c clean"?
> Sorry, it was glibc-initial that I ran the cleanall on, so just clean
> makes no difference.

Ok, what does bitbake -e show as the value of PACKAGE_EXTRA_ARCHS?

You could try putting something like:

bb.warn(d.expand("${SSTATE_MANIFESTS}/manifest-%s-*.populate_sysroot" % pkgarch))

into that 'for pkgarch in pkgarchs' loop and see what its looking for.
There is some detail I'm missing with the problem right now... :/

Cheers,

Richard

Re: configure error for glibc 2.25.2

[Andrew Goodbody]

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

> From: Richard Purdie [mailto:richard.purdie@linuxfoundation.org]
> On Wed, 2017-01-25 at 09:56 +0000, Andrew Goodbody wrote:
> > >
> > > From: Richard Purdie [mailto:richard.purdie@linuxfoundation.org]
> > > On Tue, 2017-01-24 at 18:08 +0000, Andrew Goodbody wrote:
> > > >
> > > > Thanks but unfortunately that did not work for me.
> > > >
> > > > I did a cleanall on glibc before trying to build it, but the
> > > > result
> > > > was the same.
> > > Try a "bitbake glibc-initial -c clean"?
> > Sorry, it was glibc-initial that I ran the cleanall on, so just clean
> > makes no difference.
> 
> Ok, what does bitbake -e show as the value of PACKAGE_EXTRA_ARCHS?
> 
> You could try putting something like:
> 
> bb.warn(d.expand("${SSTATE_MANIFESTS}/manifest-%s-
> *.populate_sysroot" % pkgarch))
> 
> into that 'for pkgarch in pkgarchs' loop and see what its looking for.
> There is some detail I'm missing with the problem right now... :/

And the detail is that that bit of code is not called in this situation. I think it is only used when no dependencies are declared. The attached patch fixes it for me.

Andrew

[-- Attachment #2: tunearch.patch --]
[-- Type: application/octet-stream, Size: 1592 bytes --]

diff --git a/meta/classes/staging.bbclass b/meta/classes/staging.bbclass
index fc387ea..bf233d6 100644
--- a/meta/classes/staging.bbclass
+++ b/meta/classes/staging.bbclass
@@ -304,7 +304,9 @@ def staging_populate_sysroot_dir(targetsysroot, nativesysroot, native, d):
         pkgarchs = ['${BUILD_ARCH}', '${BUILD_ARCH}_*']
         targetdir = nativesysroot
     else:
-        pkgarchs = ['${MACHINE_ARCH}', '${TUNE_PKGARCH}', 'allarch']
+        pkgarchs = ['${MACHINE_ARCH}']
+        pkgarchs = pkgarchs + list(reversed(d.getVar("PACKAGE_EXTRA_ARCHS").split()))
+        pkgarchs.append('allarch')
         targetdir = targetsysroot
 
     bb.utils.mkdirhier(targetdir)
@@ -530,7 +532,11 @@ python extend_recipe_sysroot() {
         else:
             manifest = d2.expand("${SSTATE_MANIFESTS}/manifest-${MACHINE_ARCH}-%s.populate_sysroot" % c)
             if not os.path.exists(manifest):
-                manifest = d2.expand("${SSTATE_MANIFESTS}/manifest-${TUNE_PKGARCH}-%s.populate_sysroot" % c)
+                #manifest = d2.expand("${SSTATE_MANIFESTS}/manifest-${TUNE_PKGARCH}-%s.populate_sysroot" % c)
+                for tunearch in list(reversed(d.getVar("PACKAGE_EXTRA_ARCHS").split())):
+                    manifest = d2.expand("${SSTATE_MANIFESTS}/manifest-%s-%s.populate_sysroot" % (tunearch, c))
+                    if os.path.exists(manifest):
+                        break
             if not os.path.exists(manifest):
                 manifest = d2.expand("${SSTATE_MANIFESTS}/manifest-allarch-%s.populate_sysroot" % c)
         if not os.path.exists(manifest):

Re: configure error for glibc 2.25.2

[Richard Purdie]

On Wed, 2017-01-25 at 11:00 +0000, Andrew Goodbody wrote:
> > 
> > From: Richard Purdie [mailto:richard.purdie@linuxfoundation.org]
> > On Wed, 2017-01-25 at 09:56 +0000, Andrew Goodbody wrote:
> > > 
> > > > 
> > > > 
> > > > From: Richard Purdie [mailto:richard.purdie@linuxfoundation.org
> > > > ]
> > > > On Tue, 2017-01-24 at 18:08 +0000, Andrew Goodbody wrote:
> > > > > 
> > > > > 
> > > > > Thanks but unfortunately that did not work for me.
> > > > > 
> > > > > I did a cleanall on glibc before trying to build it, but the
> > > > > result
> > > > > was the same.
> > > > Try a "bitbake glibc-initial -c clean"?
> > > Sorry, it was glibc-initial that I ran the cleanall on, so just
> > > clean
> > > makes no difference.
> > Ok, what does bitbake -e show as the value of PACKAGE_EXTRA_ARCHS?
> > 
> > You could try putting something like:
> > 
> > bb.warn(d.expand("${SSTATE_MANIFESTS}/manifest-%s-
> > *.populate_sysroot" % pkgarch))
> > 
> > into that 'for pkgarch in pkgarchs' loop and see what its looking
> > for.
> > There is some detail I'm missing with the problem right now... :/
> And the detail is that that bit of code is not called in this
> situation. I think it is only used when no dependencies are declared.
> The attached patch fixes it for me.

Sorry, yes, you're totally right. I hadn't remembered there were two
places we were making this assumption! That does look like the right
fix although I might rework that code slightly.

Thanks!

Cheers,

Richard

Re: configure error for glibc 2.25.2

[Andrew Goodbody]

> From: Richard Purdie [mailto:richard.purdie@linuxfoundation.org]
> Sorry, yes, you're totally right. I hadn't remembered there were two
> places we were making this assumption! That does look like the right
> fix although I might rework that code slightly.

Feel free. I'm off to fix all the other fallout in my recipes from recipe specific sysroots.

Andrew