Best way to update gnu-config?
I am working on meta-aarch64 layer to add 64-bit ARM support.
For that I have to update gnu-config to newer version. Currently I am using gnu-config_git.bbappend to move to 20120814 one. OE-Core is using tarball prepared by Yocto Project so update is not so easy for outside developer.
Attached are files which I am using (including updated uclibc patch). Please reply with information how I can get it fully merged.
LIC_FILES_CHKSUM = "file://config.guess;endline=39;md5=b79a4663475f4d724846463277817e0d"
SRCREV = "062587eaa891396c936555ae51f7e77eeb71a5fe" PV = "20120814+git${SRCPV}"
PR = "r0"
SRC_URI = "git://git.sv.gnu.org/config.git;protocol=git \
file://config-guess-uclibc.patch \
file://gnu-configize.in"DEFAULT_PREFERENCE = "1"FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:"
Upstream-Status: Pending
Patch courtesy gentoo-portage/sys-devel/gnuconfig/files/automake-1.8.5-config-guess-uclibc.patch.
updated to 20050516 by Marcin 'Hrw' Juszkiewicz (by hand) updated to 20080123 by Nitin A Kamble (by hand) updated to 20111001 by Saul Wold (by hand) updated to 20120818 by Marcin 'Hrw' Juszkiewicz (by hand)
--- config.guess | 67 +++++++++++++++++++++++++++++++++++------------------------ 1 file changed, 40 insertions(+), 27 deletions(-)
config.guess +40 -27
@@ -138,6 +138,19 @@ UNAME_RELEASE=`(uname -r) 2>/dev/null` | UNAME_SYSTEM=`(uname -s) 2>/dev/null` || UNAME_SYSTEM=unknown UNAME_VERSION=`(uname -v) 2>/dev/null` || UNAME_VERSION=unknown +# Detect uclibc systems. + +LIBC="gnu" +if [ -f /usr/include/bits/uClibc_config.h ] +then + LIBC=uclibc + if [ -n `grep "#define __UCLIBC_CONFIG_VERSION__" /usr/include/bits/uClibc_config.h` ] + then + UCLIBC_SUBVER=`sed -n "/#define __UCLIBC_CONFIG_VERSION__ /s///p" /usr/include/bits/uClibc_config.h` + LIBC=$LIBC$UCLIBC_SUBVER + fi +fi + # Note: order is significant - the case branches are not exclusive. case "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" in
@@ -886,15 +899,15 @@ EOF EV68*) UNAME_MACHINE=alphaev68 ;; esac objdump --private-headers /bin/sh | grep -q ld.so.1 - if test "$?" = 0 ; then LIBC="libc1" ; else LIBC="" ; fi - echo ${UNAME_MACHINE}-unknown-linux-gnu${LIBC} + if test "$?" = 0 ; then LIBC="gnulibc1" ; else LIBC="" ; fi + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; arm*:Linux:*:*) eval $set_cc_for_build if echo __ARM_EABI__ | $CC_FOR_BUILD -E - 2>/dev/null \ | grep -q __ARM_EABI__ then - echo ${UNAME_MACHINE}-unknown-linux-gnu + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} else if echo __ARM_PCS_VFP | $CC_FOR_BUILD -E - 2>/dev/null \ | grep -q __ARM_PCS_VFP
@@ -906,19 +919,19 @@ EOF fi exit ;; avr32*:Linux:*:*) - echo ${UNAME_MACHINE}-unknown-linux-gnu + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; cris:Linux:*:*) - echo ${UNAME_MACHINE}-axis-linux-gnu + echo ${UNAME_MACHINE}-axis-linux-${LIBC} exit ;; crisv32:Linux:*:*) - echo ${UNAME_MACHINE}-axis-linux-gnu + echo ${UNAME_MACHINE}-axis-linux-${LIBC} exit ;; frv:Linux:*:*) - echo ${UNAME_MACHINE}-unknown-linux-gnu + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; hexagon:Linux:*:*) - echo ${UNAME_MACHINE}-unknown-linux-gnu + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; i*86:Linux:*:*) LIBC=gnu
@@ -932,13 +945,13 @@ EOF echo "${UNAME_MACHINE}-pc-linux-${LIBC}" exit ;; ia64:Linux:*:*) - echo ${UNAME_MACHINE}-unknown-linux-gnu + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; m32r*:Linux:*:*) - echo ${UNAME_MACHINE}-unknown-linux-gnu + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; m68*:Linux:*:*) - echo ${UNAME_MACHINE}-unknown-linux-gnu + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; mips:Linux:*:* | mips64:Linux:*:*) eval $set_cc_for_build
@@ -957,54 +970,54 @@ EOF #endif EOF eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep '^CPU'` - test x"${CPU}" != x && { echo "${CPU}-unknown-linux-gnu"; exit; } + test x"${CPU}" != x && { echo "${CPU}-unknown-linux-${LIBC}"; exit; } ;; or32:Linux:*:*) - echo ${UNAME_MACHINE}-unknown-linux-gnu + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; padre:Linux:*:*) - echo sparc-unknown-linux-gnu + echo sparc-unknown-linux-${LIBC} exit ;; parisc64:Linux:*:* | hppa64:Linux:*:*) - echo hppa64-unknown-linux-gnu + echo hppa64-unknown-linux-${LIBC} exit ;; parisc:Linux:*:* | hppa:Linux:*:*) # Look for CPU level case `grep '^cpu[^a-z]*:' /proc/cpuinfo 2>/dev/null | cut -d' ' -f2` in - PA7*) echo hppa1.1-unknown-linux-gnu ;; - PA8*) echo hppa2.0-unknown-linux-gnu ;; - *) echo hppa-unknown-linux-gnu ;; + PA7*) echo hppa1.1-unknown-linux-${LIBC} ;; + PA8*) echo hppa2.0-unknown-linux-${LIBC} ;; + *) echo hppa-unknown-linux-${LIBC} ;; esac exit ;; ppc64:Linux:*:*) - echo powerpc64-unknown-linux-gnu + echo powerpc64-unknown-linux-${LIBC} exit ;; ppc:Linux:*:*) - echo powerpc-unknown-linux-gnu + echo powerpc-unknown-linux-${LIBC} exit ;; s390:Linux:*:* | s390x:Linux:*:*) echo ${UNAME_MACHINE}-ibm-linux exit ;; sh64*:Linux:*:*) - echo ${UNAME_MACHINE}-unknown-linux-gnu + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; sh*:Linux:*:*) - echo ${UNAME_MACHINE}-unknown-linux-gnu + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; sparc:Linux:*:* | sparc64:Linux:*:*) - echo ${UNAME_MACHINE}-unknown-linux-gnu + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; tile*:Linux:*:*) - echo ${UNAME_MACHINE}-unknown-linux-gnu + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; vax:Linux:*:*) - echo ${UNAME_MACHINE}-dec-linux-gnu + echo ${UNAME_MACHINE}-dec-linux-${LIBC} exit ;; x86_64:Linux:*:*) - echo ${UNAME_MACHINE}-unknown-linux-gnu + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; xtensa*:Linux:*:*) - echo ${UNAME_MACHINE}-unknown-linux-gnu + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; i*86:DYNIX/ptx:4*:*) # ptx 4.0 does uname -s correctly, with DYNIX/ptx in there.
PATCH 1/2 ncurses: Update gnu-config files to version used by OE-Core
--- meta/recipes-core/ncurses/ncurses.inc | 5 +++++ 1 file changed, 5 insertions(+)
meta/recipes-core/ncurses/ncurses.inc +5 -0
@@ -59,6 +59,11 @@ ncurses_configure() { cd .. } +# Update gnu-config files to version used by OE-Core +do_configure_prepend() { + install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.{guess,sub} ${S} +} + # Override the function from the autotools class; ncurses requires a # patched autoconf213 to generate the configure script. This autoconf # is not available so that the shipped script will be used.
Signature · 1 line
1.7.10.4
PATCH 2/2 db: Update gnu-config files to version used by OE-Core
--- meta/recipes-support/db/db_5.3.15.bb | 5 +++++ 1 file changed, 5 insertions(+)
meta/recipes-support/db/db_5.3.15.bb +5 -0
@@ -71,6 +71,11 @@ MUTEX_arm = "${ARM_MUTEX}" MUTEX_armeb = "${ARM_MUTEX}" EXTRA_OECONF += "${MUTEX}" +# Update gnu-config files to version used by OE-Core +do_configure_prepend() { + install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.{guess,sub} ${S} +} + # Cancel the site stuff - it's set for db3 and destroys the # configure. CONFIG_SITE = ""
Signature · 1 line
1.7.10.4
Re: [PATCH 2/2] db: Update gnu-config files to version used by OE-Core
meta/recipes-support/db/db_5.3.15.bb MUTEX_arm = "${ARM_MUTEX}" · line 77
Quoted 4 lines · Marcin Juszkiewicz
meta/recipes-support/db/db_5.3.15.bb +4
-0+# Update gnu-config files to version used by OE-Core +do_configure_prepend() { + install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.{guess,sub} ${S} +}
Why can't the autotools class do this for every package?
(IIRC, Debian recommends this too)
Ross
Re: [PATCH 2/2] db: Update gnu-config files to version used by OE-Core
W dniu 18.09.2012 13:20, Burton, Ross pisze:
Quoted 8 lines
meta/recipes-support/db/db_5.3.15.bb MUTEX_arm = "${ARM_MUTEX}" · line 77
Quoted 4 lines · Marcin Juszkiewicz
meta/recipes-support/db/db_5.3.15.bb +4
-0+# Update gnu-config files to version used by OE-Core +do_configure_prepend() { + install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.{guess,sub} ${S} +}Why can't the autotools class do this for every package?
It does it in own do_configure by calling 'autoreconf'. But some packages have their version of this function.
Re: [PATCH 1/2] ncurses: Update gnu-config files to version used by OE-Core
In reply to Marcin JuszkiewiczOp 18 sep. 2012, om 11:00 heeft Marcin Juszkiewicz <[email protected]> het volgende geschreven:
Quoted 10 lines
Signed-off-by Marcin Juszkiewicz <[email protected]>---
meta/recipes-core/ncurses/ncurses.inc | 5 +++++1 file changed, 5 insertions(+)meta/recipes-core/ncurses/ncurses.inc +0
-0
meta/recipes-core/ncurses/ncurses.inc ncurses_configure() { · line 66
Quoted 8 lines
meta/recipes-core/ncurses/ncurses.inc +5
-0@@ -59,6 +59,11 @@ ncurses_configure() { cd .. } +# Update gnu-config files to version used by OE-Core +do_configure_prepend() { + install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.{guess,sub} ${S} +} +
Apart from the missing PR bumps, isn't autotools.bbclass supposed to handle this?
Re: [PATCH 1/2] ncurses: Update gnu-config files to version used by OE-Core
W dniu 18.09.2012 12:40, Koen Kooi pisze:
Quoted 3 lines
meta/recipes-core/ncurses/ncurses.inc ncurses_configure() {
Quoted 3 lines
meta/recipes-core/ncurses/ncurses.inc +3
-0+# Update gnu-config files to version used by OE-Core +do_configure_prepend() { + install -m 0755
${STAGING_DATADIR_NATIVE}/gnu-config/config.{guess,sub} ${S}
Quoted 3 lines
Quoted 1 line
+}
Apart from the missing PR bumps
For normal OE builds situation does not change too much so that's why I skipped PR bump. For 64-bit ARM it does not build without it so no PR as well.
Quoted 1 line
isn't autotools.bbclass supposed to handle this?
autotools.bbclass does it in own do_configure. But both db and ncurses uses own do_configure without calling autoreconf.
PATCH 1/4 autotools.bbclass: update gnu-config files always
When recipe inherits autotools it gets do_configure defined. One of things which are done is autoreconf so gnu-config files are updated to latest OE version.
But some recipes use own do_configure due to hard edited configure scripts or other reasons. We can edit those recipes one by one or can trick them and provide update gnu-config files without using autoreconf.
There are still some recipes left but that's usually due to other directories than ${S} being used for configure scripts.
--- meta/classes/autotools.bbclass | 4 ++++ 1 file changed, 4 insertions(+)
meta/classes/autotools.bbclass +4 -0
@@ -99,6 +99,10 @@ autotools_preconfigure() { mkdir ${B} fi fi + + # not all recipes which use autotools use it's do_configure + install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.guess ${S} + install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.sub ${S} } autotools_postconfigure(){
Signature · 1 line
1.7.10.4
Re: [PATCH 1/4] autotools.bbclass: update gnu-config files always
Quoted 22 lines · Marcin Juszkiewicz
When recipe inherits autotools it gets
do_configuredefined. One of things which are done is autoreconf so gnu-config files are updated to latest OE version.But some recipes use own
do_configuredue to hard edited configure scripts or other reasons. We can edit those recipes one by one or can trick them and provide update gnu-config files without using autoreconf.There are still some recipes left but that's usually due to other directories than ${S} being used for configure scripts.
Signed-off-by Marcin Juszkiewicz <[email protected]>--- meta/classes/autotools.bbclass | 4 ++++ 1 file changed, 4 insertions(+)meta/classes/autotools.bbclass +0
-0
meta/classes/autotools.bbclass autotools_preconfigure() { · line 106
Quoted 8 lines
meta/classes/autotools.bbclass +4
-0@@ -99,6 +99,10 @@ autotools_preconfigure() { mkdir ${B} fi fi + + # not all recipes which use autotools use it's do_configure + install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.guess ${S} + install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.sub ${S} }
This won't obey the autoconf macro which redirects such files into a subdirectory, right? It shouldn't always go to ${S}, afaik. Quite a few projects will use t his macro to move all those files into a subdir like 'config' to clean up the root of the source tree. To really do this properly, I think you'd have to:
1) descend into autoconf subdirs, so subdir configure runs also use the updated gnu config files
2) extract the config subdir from autoconf and install them there, for each of those dirs
Signature · 1 line
Christopher Larson
PATCH 1/1 autotools.bbclass: update gnu-config files always
When recipe inherits autotools it gets do_configure defined. One of things which are done is autoreconf so gnu-config files are updated to latest OE version.
But some recipes use own do_configure due to hard edited configure scripts or other reasons. We can edit those recipes one by one or can trick them and provide update gnu-config files without using autoreconf.
--- meta/classes/autotools.bbclass | 6 ++++++ 1 file changed, 6 insertions(+)
meta/classes/autotools.bbclass +6 -0
@@ -99,6 +99,12 @@ autotools_preconfigure() { mkdir ${B} fi fi + + # not all recipes which use autotools use it's do_configure + ( for ac in `find ${S} -name configure.in -o -name configure.ac`; do + install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.guess `dirname $ac` + install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.sub `dirname $ac` + done ) } autotools_postconfigure(){
Signature · 1 line
1.7.10.4
Re: [PATCH] autotools.bbclass: update gnu-config files always
Quoted 21 lines · Marcin Juszkiewicz
When recipe inherits autotools it gets
do_configuredefined. One of things which are done is autoreconf so gnu-config files are updated to latest OE version.But some recipes use own
do_configuredue to hard edited configure scripts or other reasons. We can edit those recipes one by one or can trick them and provide update gnu-config files without using autoreconf.Signed-off-by Marcin Juszkiewicz <[email protected]>--- meta/classes/autotools.bbclass | 6 ++++++ 1 file changed, 6 insertions(+)meta/classes/autotools.bbclass +0
-0@@ -99,6 +99,12 @@ autotools_preconfigure() { mkdir ${B} fi
meta/classes/autotools.bbclass autotools_preconfigure() { · line 110
Quoted 10 lines
meta/classes/autotools.bbclass +6
-0fi + + # not all recipes which use autotools use it's do_configure + ( for ac in `find ${S} -name configure.in -o -name configure.ac`; do + install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.guess `dirname $ac` + install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.sub `dirname $ac` + done ) } autotools_postconfigure(){
I'm not sure we want to go down this route. How about we mandate that everything call autotools_do_configure but allow various sections of it to be optional depending on some variables.
We could then trigger the above behaviour for recipes which disable reautoconf?
Ideally, we should be able to reautoconf everything and we shouldn't have exceptions at all.
The aim here is to make things more deterministic and make it clear which code paths are being used where and why.
Cheers,
Richard
Re: [PATCH] autotools.bbclass: update gnu-config files always
W dniu 10.10.2012 00:34, Richard Purdie pisze:
Quoted 11 lines · Marcin Juszkiewicz
meta/classes/autotools.bbclass autotools_preconfigure() { · line 107
Quoted 6 lines
meta/classes/autotools.bbclass +5
-0+ # not all recipes which use autotools use it's do_configure + ( for ac in `find ${S} -name configure.in -o -name configure.ac`; do + install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.guess `dirname $ac` + install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.sub `dirname $ac` + done )I'm not sure we want to go down this route. How about we mandate that everything call
autotools_do_configurebut allow various sections of it to be optional depending on some variables.
How would we support ncurses then? It runs configure in different ways due to ENABLE_WIDEC variable (some play with EXTRA_OECONF maybe).
Or slang which has ${S}/autoconf/configure.ac when autotools.bbclass checks only for ${S}/configure.{in,ac} when it decides to run autoreconf?
db one is easier as there we can add some variable like SKIP_AUTORECONF and it should work. Similar with xinetd.
Quoted 2 lines
We could then trigger the above behaviour for recipes which disable reautoconf?
That's an option. But we need also something for situations like slang/ncurses.
Quoted 2 lines
Ideally, we should be able to reautoconf everything and we shouldn't have exceptions at all.
And no reset for PARALLEL_MAKE as well. But we learnt during those OE years that there is no such thing as ideal situation.
Quoted 2 lines
The aim here is to make things more deterministic and make it clear which code paths are being used where and why.
Agree.
Quoted 9 lines · Marcin Juszkiewicz
I am working on meta-aarch64 layer to add 64-bit ARM support.
For that I have to update gnu-config to newer version. Currently I am using gnu-config_git.bbappend to move to 20120814 one. OE-Core is using tarball prepared by Yocto Project so update is not so easy for outside developer.
Attached are files which I am using (including updated uclibc patch). Please reply with information how I can get it fully merged.
The trouble was that upstream was in cvs. It was the only reason we still had a dependency on cvs and we decided we wanted to kill it which isn't something I regret.
Can you share a tarball of the updated (unpatched) upstream version and we'll put it into place alongside the other tarball on the server. Michael (cc'd) should be able to do this. Once that is done you should be able to send a patch as usual to update to the new version.
I appreciate this is a pain but a dependency on cvs is worse IMO ;-).
Cheers,
Richard
W dniu 18.09.2012 11:08, Richard Purdie pisze:
Quoted 3 lines
The trouble was that upstream was in cvs. It was the only reason we still had a dependency on cvs and we decided we wanted to kill it which isn't something I regret.
There is git mirror hosted on gnu.org servers which can be used instead of cvs. OE-Core already has git-native.
Quoted 2 lines
Can you share a tarball of the updated (unpatched) upstream version and we'll put it into place alongside the other tarball on the server.
http://people.linaro.org/~hrw/aarch64/gnu-config-20120814.tar.bz2
11:29 hrw@puchatek$ sha256sum gnu-config-20120814.tar.bz2 44f99a8e76f3e8e4fec0bb5ad4762f8e44366168554ce66cb85afbe2ed3efd8b gnu-config-20120814.tar.bz2
Quoted 2 lines
Michael (cc'd) should be able to do this. Once that is done you should be able to send a patch as usual to update to the new version.
Ok.
Quoted 8 lines · Marcin Juszkiewicz
W dniu 18.09.2012 11:08, Richard Purdie pisze:
Quoted 3 lines
The trouble was that upstream was in cvs. It was the only reason we still had a dependency on cvs and we decided we wanted to kill it which isn't something I regret.
There is git mirror hosted on gnu.org servers which can be used instead of cvs. OE-Core already has git-native.
I remember the problem now, this was a circular dependency nightmare (git-native depends on gnu-config-native and vice versa).
Quoted 5 lines
Quoted 2 lines
Can you share a tarball of the updated (unpatched) upstream version and we'll put it into place alongside the other tarball on the server.
http://people.linaro.org/~hrw/aarch64/gnu-config-20120814.tar.bz2
Quoted 8 lines
11:29 hrw@puchatek$ sha256sum gnu-config-20120814.tar.bz2
44f99a8e76f3e8e4fec0bb5ad4762f8e44366168554ce66cb85afbe2ed3efd8bgnu-config-20120814.tar.bz2Quoted 2 lines
Michael (cc'd) should be able to do this. Once that is done you should be able to send a patch as usual to update to the new version.
Ok.
Thanks, Michael should be able to take care of this later today (he's US based).
Cheers,
Richard
W dniu 18.09.2012 11:36, Richard Purdie pisze:
Quoted 22 lines · Marcin Juszkiewicz
Quoted 8 lines
W dniu 18.09.2012 11:08, Richard Purdie pisze:
Quoted 3 lines
The trouble was that upstream was in cvs. It was the only reason we still had a dependency on cvs and we decided we wanted to kill it which isn't something I regret.
There is git mirror hosted on gnu.org servers which can be used instead of cvs. OE-Core already has git-native.
I remember the problem now, this was a circular dependency nightmare (git-native depends on gnu-config-native and vice versa).
Quoted 9 lines
Quoted 2 lines
Can you share a tarball of the updated (unpatched) upstream version and we'll put it into place alongside the other tarball on the server.
http://people.linaro.org/~hrw/aarch64/gnu-config-20120814.tar.bz2
11:29 hrw@puchatek$ sha256sum gnu-config-20120814.tar.bz2
44f99a8e76f3e8e4fec0bb5ad4762f8e44366168554ce66cb85afbe2ed3efd8bgnu-config-20120814.tar.bz2
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
Michael (cc'd) should be able to do this. Once that is done you should be able to send a patch as usual to update to the new version.
Ok.
Thanks, Michael should be able to take care of this later today (he's US based).
Michael: any update on it?
Quoted 28 lines · Marcin Juszkiewicz
W dniu 18.09.2012 11:36, Richard Purdie pisze:
Quoted 27 lines · Marcin Juszkiewicz
Quoted 9 lines
W dniu 18.09.2012 11:08, Richard Purdie pisze:
Quoted 4 lines
The trouble was that upstream was in cvs. It was the only reason we still had a dependency on cvs and we decided we wanted to kill it which
isn't something I regret.There is git mirror hosted on gnu.org servers which can be used instead of cvs. OE-Core already has git-native.
I remember the problem now, this was a circular dependency nightmare (git-native depends on gnu-config-native and vice versa).
Quoted 13 lines
Quoted 3 lines
Can you share a tarball of the updated (unpatched) upstream version and
we'll put it into place alongside the other tarball on the server.http://people.linaro.org/~hrw/aarch64/gnu-config-20120814.tar.bz2
11:29 hrw@puchatek$ sha256sum gnu-config-20120814.tar.bz2
44f99a8e76f3e8e4fec0bb5ad4762f8e44366168554ce66cb85afbe2ed3efd8bgnu-config-20120814.tar.bz2Quoted 2 lines
Michael (cc'd) should be able to do this. Once that is done you should be able to send a patch as usual to update to the new version.
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
Ok.
Thanks, Michael should be able to take care of this later today (he's US based).
Michael: any update on it?
I'm sorry this is a case of bad e-mail filtering.
I've added this tarball at
http://downloads.yoctoproject.org/releases/gnu-config/ is that correct?
Michael Halstead
Yocto Project / Sys Admin
W dniu 03.10.2012 18:24, Michael Halstead pisze:
Quoted 6 lines · Marcin Juszkiewicz
Quoted 5 lines
W dniu 18.09.2012 11:36, Richard Purdie pisze:
Quoted 2 lines
Thanks, Michael should be able to take care of this later today (he's US based).
Quoted 6 lines
Quoted 2 lines
Michael: any update on it?
I'm sorry this is a case of bad e-mail filtering.
I've added this tarball at
http://downloads.yoctoproject.org/releases/gnu-config/ is that correct?
Thanks a lot - that was it.
PATCH 1/1 gnu-config: update to 2012.08.14 to get support for AArch64 architecture
In reply to Richard Purdie---
.../gnu-config/config-guess-uclibc.patch | 47 +++++++++++---------
...u-config_20111111.bb => gnu-config_20120814.bb} | 10 ++---
2 files changed, 31 insertions(+), 26 deletions(-)
rename meta/recipes-devtools/gnu-config/{gnu-config_20111111.bb => gnu-config_20120814.bb} (80%)meta/recipes-devtools/gnu-config/gnu-config/config-guess-uclibc.patch +26 -21
@@ -5,13 +5,18 @@ Patch courtesy gentoo-portage/sys-devel/gnuconfig/files/automake-1.8.5-config-gu updated to 20050516 by Marcin 'Hrw' Juszkiewicz (by hand) updated to 20080123 by Nitin A Kamble (by hand) updated to 20111001 by Saul Wold (by hand) +updated to 20120818 by Marcin 'Hrw' Juszkiewicz (by hand) + Signed-off-by: Saul Wold <[email protected]> +Signed-off-by: Marcin Juszkiewicz <[email protected]> + +--- + config.guess | 67 +++++++++++++++++++++++++++++++++++------------------------ + 1 file changed, 40 insertions(+), 27 deletions(-) -Index: git/config.guess -=================================================================== ---- git.orig/config.guess 2011-10-20 15:15:25.000000000 -0700 -+++ git/config.guess 2011-10-20 16:56:43.810830229 -0700 -@@ -140,6 +140,19 @@ +--- git.orig/config.guess ++++ git/config.guess +@@ -138,6 +138,19 @@ UNAME_RELEASE=`(uname -r) 2>/dev/null` | UNAME_SYSTEM=`(uname -s) 2>/dev/null` || UNAME_SYSTEM=unknown UNAME_VERSION=`(uname -v) 2>/dev/null` || UNAME_VERSION=unknown
@@ -31,7 +36,7 @@ Index: git/config.guess # Note: order is significant - the case branches are not exclusive. case "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" in -@@ -871,15 +884,15 @@ +@@ -886,15 +899,15 @@ EOF EV68*) UNAME_MACHINE=alphaev68 ;; esac objdump --private-headers /bin/sh | grep -q ld.so.1
@@ -50,7 +55,7 @@ Index: git/config.guess else if echo __ARM_PCS_VFP | $CC_FOR_BUILD -E - 2>/dev/null \ | grep -q __ARM_PCS_VFP -@@ -891,19 +904,19 @@ +@@ -906,19 +919,19 @@ EOF fi exit ;; avr32*:Linux:*:*)
@@ -58,24 +63,24 @@ Index: git/config.guess + echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; cris:Linux:*:*) -- echo cris-axis-linux-gnu -+ echo cris-axis-linux-${LIBC} +- echo ${UNAME_MACHINE}-axis-linux-gnu ++ echo ${UNAME_MACHINE}-axis-linux-${LIBC} exit ;; crisv32:Linux:*:*) -- echo crisv32-axis-linux-gnu -+ echo crisv32-axis-linux-${LIBC} +- echo ${UNAME_MACHINE}-axis-linux-gnu ++ echo ${UNAME_MACHINE}-axis-linux-${LIBC} exit ;; frv:Linux:*:*) -- echo frv-unknown-linux-gnu -+ echo frv-unknown-linux-${LIBC} +- echo ${UNAME_MACHINE}-unknown-linux-gnu ++ echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; hexagon:Linux:*:*) -- echo hexagon-unknown-linux-gnu -+ echo hexagon-unknown-linux-${LIBC} +- echo ${UNAME_MACHINE}-unknown-linux-gnu ++ echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; i*86:Linux:*:*) LIBC=gnu -@@ -917,13 +930,13 @@ +@@ -932,13 +945,13 @@ EOF echo "${UNAME_MACHINE}-pc-linux-${LIBC}" exit ;; ia64:Linux:*:*)
@@ -92,7 +97,7 @@ Index: git/config.guess exit ;; mips:Linux:*:* | mips64:Linux:*:*) eval $set_cc_for_build -@@ -942,54 +955,54 @@ +@@ -957,54 +970,54 @@ EOF #endif EOF eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep '^CPU'`
@@ -100,8 +105,8 @@ Index: git/config.guess + test x"${CPU}" != x && { echo "${CPU}-unknown-linux-${LIBC}"; exit; } ;; or32:Linux:*:*) -- echo or32-unknown-linux-gnu -+ echo or32-unknown-linux-${LIBC} +- echo ${UNAME_MACHINE}-unknown-linux-gnu ++ echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; padre:Linux:*:*) - echo sparc-unknown-linux-gnu
@@ -154,8 +159,8 @@ Index: git/config.guess + echo ${UNAME_MACHINE}-dec-linux-${LIBC} exit ;; x86_64:Linux:*:*) -- echo x86_64-unknown-linux-gnu -+ echo x86_64-unknown-linux-${LIBC} +- echo ${UNAME_MACHINE}-unknown-linux-gnu ++ echo ${UNAME_MACHINE}-unknown-linux-${LIBC} exit ;; xtensa*:Linux:*:*) - echo ${UNAME_MACHINE}-unknown-linux-gnu
meta/recipes-devtools/gnu-config/gnu-config_20120814.bb renamed from meta/recipes-devtools/gnu-config/gnu-config_20111111.bb +5 -5
@@ -2,20 +2,20 @@ SUMMARY = "gnu-configize" DESCRIPTION = "Tool that installs the GNU config.guess / config.sub into a directory tree" SECTION = "devel" LICENSE = "GPLv2" -LIC_FILES_CHKSUM = "file://config.guess;endline=39;md5=a3669d051b3a8408d69751e53b2e1cc1" +LIC_FILES_CHKSUM = "file://config.guess;endline=39;md5=b79a4663475f4d724846463277817e0d" DEPENDS_virtclass-native = "perl-native-runtime" INHIBIT_DEFAULT_DEPS = "1" -PR = "r1" +PR = "r0" -SRC_URI = "http://downloads.yoctoproject.org/releases/gnu-config/gnu-config-yocto-${PV}.tgz \ +SRC_URI = "http://downloads.yoctoproject.org/releases/gnu-config/gnu-config-${PV}.tar.bz2 \ file://config-guess-uclibc.patch \ file://gnu-configize.in" -SRC_URI[md5sum] = "30be385c919a25cd9522205ef49e5328" -SRC_URI[sha256sum] = "0750afa8d8ee988b6ead1c2d02b565597f809e2e3ad14886ed7803d3bbc8b0cd" +SRC_URI[md5sum] = "bcfca5a2bb39edad4aae5a65efc84094" +SRC_URI[sha256sum] = "44f99a8e76f3e8e4fec0bb5ad4762f8e44366168554ce66cb85afbe2ed3efd8b" do_compile() { :
Signature · 1 line
1.7.10.4