| Submitter | Ross Burton |
|---|---|
| Date | Feb. 26, 2013, 12:36 p.m. |
| Message ID | <1361882216-8152-1-git-send-email-ross.burton@intel.com> |
| Download | mbox | patch |
| Permalink | /patch/45119/ |
| State | New |
| Headers | show |
Comments
On Tue, Feb 26, 2013 at 9:36 AM, Ross Burton <ross.burton@intel.com> wrote: > Signed-off-by: Ross Burton <ross.burton@intel.com> > --- > meta/recipes-graphics/xorg-lib/xkeyboard-config_2.8.bb | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.8.bb b/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.8.bb > index 8ca2f6a..ee3e20c 100644 > --- a/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.8.bb > +++ b/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.8.bb > @@ -19,6 +19,8 @@ SRC_URI[sha256sum] = "4e1cf5468d488aaf320ddfd439e03cbda0b213550fd734026d23138e4b > SECTION = "x11/libs" > DEPENDS = "intltool-native xkbcomp-native glib-2.0 virtual/gettext" > > +PACKAGE_ARCH = "all" > + > PR = "r0" > > EXTRA_OECONF = "--with-xkb-rules-symlink=xorg --disable-runtime-deps" Please inherit allarch
On 26 February 2013 14:32, Otavio Salvador <otavio@ossystems.com.br> wrote:
> Please inherit allarch
That doesn't play nicely with autotools:
| checking build system type... x86_64-pc-linux-gnu
| checking host system type... Invalid configuration
`allarch-poky-linux': machine `allarch-poky' not recognized
| configure: error: /bin/bash ./config.sub allarch-poky-linux failed
Considering a lot of allarch is designed to remove dependencies that
this package uses and thus will need to be restored, directly setting
PACKAGE_ARCH is the cleaner solution.
Ross
On Tue, Feb 26, 2013 at 2:42 PM, Burton, Ross <ross.burton@intel.com> wrote: > On 26 February 2013 14:32, Otavio Salvador <otavio@ossystems.com.br> wrote: >> Please inherit allarch > > That doesn't play nicely with autotools: > > | checking build system type... x86_64-pc-linux-gnu > | checking host system type... Invalid configuration > `allarch-poky-linux': machine `allarch-poky' not recognized > | configure: error: /bin/bash ./config.sub allarch-poky-linux failed > > Considering a lot of allarch is designed to remove dependencies that > this package uses and thus will need to be restored, directly setting > PACKAGE_ARCH is the cleaner solution. If it changes the build depending in target and host, in the end it is not architecture independant code.
On 26 February 2013 17:47, Otavio Salvador <otavio@ossystems.com.br> wrote: > If it changes the build depending in target and host, in the end it is > not architecture independant code. I think this is just autotools being nosy and failing when it doesn't know what "alllinux" is. The files don't change as they are literally just installed. Ross
On Tue, Feb 26, 2013 at 2:55 PM, Burton, Ross <ross.burton@intel.com> wrote: > On 26 February 2013 17:47, Otavio Salvador <otavio@ossystems.com.br> wrote: >> If it changes the build depending in target and host, in the end it is >> not architecture independant code. > > I think this is just autotools being nosy and failing when it doesn't > know what "alllinux" is. The files don't change as they are literally > just installed. allarch does more than PACKAGE_ARCH so I think it'd be good to use it. Maybe it'd not be hard to disable this call in configure.ac? I don't have a strong opinion about it but using PACKAGE_ARCH only seems like a workaround for me.
On Tue, 2013-02-26 at 17:55 +0000, Burton, Ross wrote: > On 26 February 2013 17:47, Otavio Salvador <otavio@ossystems.com.br> wrote: > > If it changes the build depending in target and host, in the end it is > > not architecture independant code. > > I think this is just autotools being nosy and failing when it doesn't > know what "alllinux" is. The files don't change as they are literally > just installed. Check exactly what is in configure.ac. You should be able to use allarch and if you can't, it means the configure script is referencing the compiler, even if it shouldn't be using it. Its designed such that these accesses fail verbosely. It should be a simple fix if the recipe really is just configuration. Using the allarch class is infinitely preferable as it gets the sstate bits right. Cheers, Richard
On 26 February 2013 19:43, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > Check exactly what is in configure.ac. You should be able to use allarch > and if you can't, it means the configure script is referencing the > compiler, even if it shouldn't be using it. Its designed such that these > accesses fail verbosely. It should be a simple fix if the recipe really > is just configuration. | configure:2707: checking host system type | configure:2716: error: /bin/bash ./config.sub allarch-poky-linux failed The configure.ac ends up running AC_CANONICAL_HOST because it uses different manpage sections for Solaris and everything else. I think they should be using AC_CANONICAL_SYSTEM, but that calls AC_CANONICAL_HOST anyway so that wouldn't achieve anything. So, extend my patch, or intrusively patch out the documentation build code in xkeyboard-config. Ross
On Tue, Feb 26, 2013 at 5:44 PM, Burton, Ross <ross.burton@intel.com> wrote: > On 26 February 2013 19:43, Richard Purdie > <richard.purdie@linuxfoundation.org> wrote: >> Check exactly what is in configure.ac. You should be able to use allarch >> and if you can't, it means the configure script is referencing the >> compiler, even if it shouldn't be using it. Its designed such that these >> accesses fail verbosely. It should be a simple fix if the recipe really >> is just configuration. > > | configure:2707: checking host system type > | configure:2716: error: /bin/bash ./config.sub allarch-poky-linux failed > > The configure.ac ends up running AC_CANONICAL_HOST because it uses > different manpage sections for Solaris and everything else. > > I think they should be using AC_CANONICAL_SYSTEM, but that calls > AC_CANONICAL_HOST anyway so that wouldn't achieve anything. > > So, extend my patch, or intrusively patch out the documentation build > code in xkeyboard-config. I'd say to drop the AC_CANONICAL_HOST call and make it fake Linux as a fixed value.
On Tue, Feb 26, 2013 at 12:36:56PM +0000, Ross Burton wrote: > Signed-off-by: Ross Burton <ross.burton@intel.com> > --- > meta/recipes-graphics/xorg-lib/xkeyboard-config_2.8.bb | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.8.bb b/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.8.bb > index 8ca2f6a..ee3e20c 100644 > --- a/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.8.bb > +++ b/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.8.bb > @@ -19,6 +19,8 @@ SRC_URI[sha256sum] = "4e1cf5468d488aaf320ddfd439e03cbda0b213550fd734026d23138e4b > SECTION = "x11/libs" > DEPENDS = "intltool-native xkbcomp-native glib-2.0 virtual/gettext" > > +PACKAGE_ARCH = "all" Why not inherit allarch? > + > PR = "r0" > > EXTRA_OECONF = "--with-xkb-rules-symlink=xorg --disable-runtime-deps" > -- > 1.7.10.4 > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
On 26 February 2013 20:52, Otavio Salvador <otavio@ossystems.com.br> wrote: > I'd say to drop the AC_CANONICAL_HOST call and make it fake Linux as a > fixed value. Did that in xorg-macros as that's where the definition is, but intltool's configure fragment links a program to set DATADIRNAME (although that appears to be deprecated), so it's trying to find a C compiler now. How do I *properly* set allarch so sstate "works" but still allow a compiler to run so it can identify distribution-specific values (that have nothing to do with the architecture)? Ross
On Wed, 2013-02-27 at 14:47 +0000, Burton, Ross wrote: > On 26 February 2013 20:52, Otavio Salvador <otavio@ossystems.com.br> wrote: > > I'd say to drop the AC_CANONICAL_HOST call and make it fake Linux as a > > fixed value. > > Did that in xorg-macros as that's where the definition is, but > intltool's configure fragment links a program to set DATADIRNAME > (although that appears to be deprecated), so it's trying to find a C > compiler now. > > How do I *properly* set allarch so sstate "works" but still allow a > compiler to run so it can identify distribution-specific values (that > have nothing to do with the architecture)? Inherit the class, then set the compiler options to point to the native compiler? I'm very nervous about doing that mind and would prefer to "fix" the macros if we can. Cheers, Richard
Patch
diff --git a/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.8.bb b/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.8.bb index 8ca2f6a..ee3e20c 100644 --- a/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.8.bb +++ b/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.8.bb @@ -19,6 +19,8 @@ SRC_URI[sha256sum] = "4e1cf5468d488aaf320ddfd439e03cbda0b213550fd734026d23138e4b SECTION = "x11/libs" DEPENDS = "intltool-native xkbcomp-native glib-2.0 virtual/gettext" +PACKAGE_ARCH = "all" + PR = "r0" EXTRA_OECONF = "--with-xkb-rules-symlink=xorg --disable-runtime-deps"
Signed-off-by: Ross Burton <ross.burton@intel.com> --- meta/recipes-graphics/xorg-lib/xkeyboard-config_2.8.bb | 2 ++ 1 file changed, 2 insertions(+)