| Message ID | 20220926071605.123085-2-sumit.garg@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | [1/2] arm-toolchain: update Arm GCC to 11.3 | expand |
On Mon, Sep 26, 2022 at 12:46:05PM +0530, Sumit Garg wrote: > Enable support for 11.3.rel1 binary toolchain release. Also, update CI > to use it. > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org> Well, the good news is this patch series does build and I was about to send out my Tested-by: But, I think, there's quite a mess in the naming/versioning area. See below... > --- > ci/get-binary-toolchains | 18 +++++++++--------- > .../external-arm-toolchain-versions.inc | 7 +++++-- > 2 files changed, 14 insertions(+), 11 deletions(-) > > diff --git a/ci/get-binary-toolchains b/ci/get-binary-toolchains > index bfdd8c57..ed334bf3 100755 > --- a/ci/get-binary-toolchains > +++ b/ci/get-binary-toolchains > @@ -2,7 +2,7 @@ > set -u > > HOST_ARCH=$(uname -m) > -VER="11.2-2022.02" > +VER="11.3.rel1" Here, it says 11.3.rel1 (note lower case) > DOWNLOAD_DIR=$1 > TOOLCHAIN_DIR=$2 <skip> > -# Extract the YYYY.MM version > +# Extract the YYYY.MM or release version > def eat_get_main_version(d): > version = eat_get_version(d) > bb.debug(2, 'Trying for parse version info from: %s' % version) > if version != 'UNKNOWN': > - if version.split()[4] == '(GNU': > + if version.split()[4] == '(Arm': > + # gcc version 11.3.1 20220712 (Arm GNU Toolchain 11.3.Rel1) > + return version.split()[7].split(')')[0] Here, it ends up picking up the uppercase version and external-arm-toolchain package ends up getting "11.3.Rel1" version, which doesn't sort well with the package feed already containing previous versions like 2018.11, 2019.12 and 2022.02 Moreover, gcc now builds a package versioned as "arm-11.3-r2022.08", so it's all over the place. Not sure where ARM_GCC_SUB_VERSION comes into play, certainly not in the package version. Should we try to standardize/unify these versioning mess here? I'd be happy to stick to 2022.08 notation, if possible... > + elif version.split()[4] == '(GNU': > # gcc version 9.2.1 20191025 (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) > # gcc version 8.2.1 20180802 (GNU Toolchain for the A-profile Architecture 8.2-2018.11 (arm-rel-8.26)) > return version.split()[10].split('-')[1] > -- > 2.17.1 >
Hi Denys, Apologies for the delayed response as I was on leave for the last few days. On Wed, 28 Sept 2022 at 05:05, Denys Dmytriyenko <denis@denix.org> wrote: > > On Mon, Sep 26, 2022 at 12:46:05PM +0530, Sumit Garg wrote: > > Enable support for 11.3.rel1 binary toolchain release. Also, update CI > > to use it. > > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org> > > Well, the good news is this patch series does build and I was about to send > out my Tested-by: Thanks for testing it. > > But, I think, there's quite a mess in the naming/versioning area. See below... > Yeah I understand your concerns below but this has been caused by renaming of toolchain releases from Arm here [1], so we need to adapt accordingly: 11.2-2022.02 -> 11.3.Rel1 [1] https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads > > > --- > > ci/get-binary-toolchains | 18 +++++++++--------- > > .../external-arm-toolchain-versions.inc | 7 +++++-- > > 2 files changed, 14 insertions(+), 11 deletions(-) > > > > diff --git a/ci/get-binary-toolchains b/ci/get-binary-toolchains > > index bfdd8c57..ed334bf3 100755 > > --- a/ci/get-binary-toolchains > > +++ b/ci/get-binary-toolchains > > @@ -2,7 +2,7 @@ > > set -u > > > > HOST_ARCH=$(uname -m) > > -VER="11.2-2022.02" > > +VER="11.3.rel1" > > Here, it says 11.3.rel1 (note lower case) > It comes from the toolchain download path being: https://developer.arm.com/-/media/Files/downloads/gnu/11.3.rel1/binrel/arm-gnu-toolchain-11.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz > > > DOWNLOAD_DIR=$1 > > TOOLCHAIN_DIR=$2 > > <skip> > > > -# Extract the YYYY.MM version > > +# Extract the YYYY.MM or release version > > def eat_get_main_version(d): > > version = eat_get_version(d) > > bb.debug(2, 'Trying for parse version info from: %s' % version) > > if version != 'UNKNOWN': > > - if version.split()[4] == '(GNU': > > + if version.split()[4] == '(Arm': > > + # gcc version 11.3.1 20220712 (Arm GNU Toolchain 11.3.Rel1) > > + return version.split()[7].split(')')[0] > > Here, it ends up picking up the uppercase version and external-arm-toolchain > package ends up getting "11.3.Rel1" version, which doesn't sort well with the > package feed already containing previous versions like 2018.11, 2019.12 and > 2022.02 > As I mentioned above, we need to adapt to the Arm toolchain release naming convention. > Moreover, gcc now builds a package versioned as "arm-11.3-r2022.08", so it's > all over the place. How about following additional changes to bring consistency? diff --git a/meta-arm-toolchain/recipes-devtools/gcc/gcc-arm-11.3.inc b/meta-arm-toolchain/recipes-devtools/gcc/gcc-arm-11.3.inc index 8eba959..15a87d8 100644 --- a/meta-arm-toolchain/recipes-devtools/gcc/gcc-arm-11.3.inc +++ b/meta-arm-toolchain/recipes-devtools/gcc/gcc-arm-11.3.inc @@ -10,9 +10,7 @@ CVE_VERSION = "11.3" BINV = "11.3.1" -MMYY = "22.08" -RELEASE = "20${MMYY}" -PR = "r${RELEASE}" +PR = "Rel1" > Not sure where ARM_GCC_SUB_VERSION comes into play, > certainly not in the package version. It's currently only used in toolchain source download path which uses lowercase: BASEURI ?= "https://developer.arm.com/-/media/Files/downloads/gnu/${ARM_GCC_VERSION}.${ARM_GCC_SUB_VERSION}/srcrel/arm-gnu-toolchain-src-snapshot-${ARM_GCC_VERSION}.${ARM_GCC_SUB_VERSION}.tar.xz" > > Should we try to standardize/unify these versioning mess here? I'd be happy to > stick to 2022.08 notation, if possible... > The 2022.08 isn't embedded within the toolchain build version: "gcc version 11.3.1 20220712 (Arm GNU Toolchain 11.3.Rel1)". So I am not sure if there is any alternative location within the pre-built toolchain to provide "2022.08" info. -Sumit > > > + elif version.split()[4] == '(GNU': > > # gcc version 9.2.1 20191025 (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) > > # gcc version 8.2.1 20180802 (GNU Toolchain for the A-profile Architecture 8.2-2018.11 (arm-rel-8.26)) > > return version.split()[10].split('-')[1] > > -- > > 2.17.1 > > > > -- > Regards, > Denys Dmytriyenko <denis@denix.org> > PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964 > Fingerprint: 25FC E4A5 8A72 2F69 1186 6D76 4209 0272 9A92 C964
On Mon, Oct 03, 2022 at 04:08:52PM +0530, Sumit Garg wrote: > Hi Denys, > > Apologies for the delayed response as I was on leave for the last few days. > > On Wed, 28 Sept 2022 at 05:05, Denys Dmytriyenko <denis@denix.org> wrote: > > > > On Mon, Sep 26, 2022 at 12:46:05PM +0530, Sumit Garg wrote: > > > Enable support for 11.3.rel1 binary toolchain release. Also, update CI > > > to use it. > > > > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org> > > > > Well, the good news is this patch series does build and I was about to send > > out my Tested-by: > > Thanks for testing it. > > > > > But, I think, there's quite a mess in the naming/versioning area. See below... > > > > Yeah I understand your concerns below but this has been caused by > renaming of toolchain releases from Arm here [1], so we need to adapt > accordingly: > > 11.2-2022.02 -> 11.3.Rel1 > > [1] https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads > > > > > > --- > > > ci/get-binary-toolchains | 18 +++++++++--------- > > > .../external-arm-toolchain-versions.inc | 7 +++++-- > > > 2 files changed, 14 insertions(+), 11 deletions(-) > > > > > > diff --git a/ci/get-binary-toolchains b/ci/get-binary-toolchains > > > index bfdd8c57..ed334bf3 100755 > > > --- a/ci/get-binary-toolchains > > > +++ b/ci/get-binary-toolchains > > > @@ -2,7 +2,7 @@ > > > set -u > > > > > > HOST_ARCH=$(uname -m) > > > -VER="11.2-2022.02" > > > +VER="11.3.rel1" > > > > Here, it says 11.3.rel1 (note lower case) > > > > It comes from the toolchain download path being: > > https://developer.arm.com/-/media/Files/downloads/gnu/11.3.rel1/binrel/arm-gnu-toolchain-11.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz > > > > > > DOWNLOAD_DIR=$1 > > > TOOLCHAIN_DIR=$2 > > > > <skip> > > > > > -# Extract the YYYY.MM version > > > +# Extract the YYYY.MM or release version > > > def eat_get_main_version(d): > > > version = eat_get_version(d) > > > bb.debug(2, 'Trying for parse version info from: %s' % version) > > > if version != 'UNKNOWN': > > > - if version.split()[4] == '(GNU': > > > + if version.split()[4] == '(Arm': > > > + # gcc version 11.3.1 20220712 (Arm GNU Toolchain 11.3.Rel1) > > > + return version.split()[7].split(')')[0] > > > > Here, it ends up picking up the uppercase version and external-arm-toolchain > > package ends up getting "11.3.Rel1" version, which doesn't sort well with the > > package feed already containing previous versions like 2018.11, 2019.12 and > > 2022.02 > > > > As I mentioned above, we need to adapt to the Arm toolchain release > naming convention. > > > Moreover, gcc now builds a package versioned as "arm-11.3-r2022.08", so it's > > all over the place. > > How about following additional changes to bring consistency? > > diff --git a/meta-arm-toolchain/recipes-devtools/gcc/gcc-arm-11.3.inc > b/meta-arm-toolchain/recipes-devtools/gcc/gcc-arm-11.3.inc > index 8eba959..15a87d8 100644 > --- a/meta-arm-toolchain/recipes-devtools/gcc/gcc-arm-11.3.inc > +++ b/meta-arm-toolchain/recipes-devtools/gcc/gcc-arm-11.3.inc > @@ -10,9 +10,7 @@ CVE_VERSION = "11.3" > > BINV = "11.3.1" > > -MMYY = "22.08" > -RELEASE = "20${MMYY}" > -PR = "r${RELEASE}" > +PR = "Rel1" I'm going to pull in the patches as they currently are. Let's do whatever fix-ups you two agree on with a follow-on patch. Thanks, Jon > > > Not sure where ARM_GCC_SUB_VERSION comes into play, > > certainly not in the package version. > > It's currently only used in toolchain source download path which uses lowercase: > > BASEURI ?= "https://developer.arm.com/-/media/Files/downloads/gnu/${ARM_GCC_VERSION}.${ARM_GCC_SUB_VERSION}/srcrel/arm-gnu-toolchain-src-snapshot-${ARM_GCC_VERSION}.${ARM_GCC_SUB_VERSION}.tar.xz" > > > > > Should we try to standardize/unify these versioning mess here? I'd be happy to > > stick to 2022.08 notation, if possible... > > > > The 2022.08 isn't embedded within the toolchain build version: "gcc > version 11.3.1 20220712 (Arm GNU Toolchain 11.3.Rel1)". So I am not > sure if there is any alternative location within the pre-built > toolchain to provide "2022.08" info. > > -Sumit > > > > > > + elif version.split()[4] == '(GNU': > > > # gcc version 9.2.1 20191025 (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) > > > # gcc version 8.2.1 20180802 (GNU Toolchain for the A-profile Architecture 8.2-2018.11 (arm-rel-8.26)) > > > return version.split()[10].split('-')[1] > > > -- > > > 2.17.1 > > > > > > > -- > > Regards, > > Denys Dmytriyenko <denis@denix.org> > > PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964 > > Fingerprint: 25FC E4A5 8A72 2F69 1186 6D76 4209 0272 9A92 C964 >
On Tue, Oct 04, 2022 at 09:14:46AM -0400, Jon Mason wrote: > On Mon, Oct 03, 2022 at 04:08:52PM +0530, Sumit Garg wrote: > > Hi Denys, > > > > Apologies for the delayed response as I was on leave for the last few days. > > > > On Wed, 28 Sept 2022 at 05:05, Denys Dmytriyenko <denis@denix.org> wrote: > > > > > > On Mon, Sep 26, 2022 at 12:46:05PM +0530, Sumit Garg wrote: > > > > Enable support for 11.3.rel1 binary toolchain release. Also, update CI > > > > to use it. > > > > > > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org> > > > > > > Well, the good news is this patch series does build and I was about to send > > > out my Tested-by: > > > > Thanks for testing it. > > > > > > > > But, I think, there's quite a mess in the naming/versioning area. See below... > > > > > > > Yeah I understand your concerns below but this has been caused by > > renaming of toolchain releases from Arm here [1], so we need to adapt > > accordingly: > > > > 11.2-2022.02 -> 11.3.Rel1 > > > > [1] https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads > > > > > > > > > --- > > > > ci/get-binary-toolchains | 18 +++++++++--------- > > > > .../external-arm-toolchain-versions.inc | 7 +++++-- > > > > 2 files changed, 14 insertions(+), 11 deletions(-) > > > > > > > > diff --git a/ci/get-binary-toolchains b/ci/get-binary-toolchains > > > > index bfdd8c57..ed334bf3 100755 > > > > --- a/ci/get-binary-toolchains > > > > +++ b/ci/get-binary-toolchains > > > > @@ -2,7 +2,7 @@ > > > > set -u > > > > > > > > HOST_ARCH=$(uname -m) > > > > -VER="11.2-2022.02" > > > > +VER="11.3.rel1" > > > > > > Here, it says 11.3.rel1 (note lower case) > > > > > > > It comes from the toolchain download path being: > > > > https://developer.arm.com/-/media/Files/downloads/gnu/11.3.rel1/binrel/arm-gnu-toolchain-11.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz > > > > > > > > > DOWNLOAD_DIR=$1 > > > > TOOLCHAIN_DIR=$2 > > > > > > <skip> > > > > > > > -# Extract the YYYY.MM version > > > > +# Extract the YYYY.MM or release version > > > > def eat_get_main_version(d): > > > > version = eat_get_version(d) > > > > bb.debug(2, 'Trying for parse version info from: %s' % version) > > > > if version != 'UNKNOWN': > > > > - if version.split()[4] == '(GNU': > > > > + if version.split()[4] == '(Arm': > > > > + # gcc version 11.3.1 20220712 (Arm GNU Toolchain 11.3.Rel1) > > > > + return version.split()[7].split(')')[0] > > > > > > Here, it ends up picking up the uppercase version and external-arm-toolchain > > > package ends up getting "11.3.Rel1" version, which doesn't sort well with the > > > package feed already containing previous versions like 2018.11, 2019.12 and > > > 2022.02 > > > > > > > As I mentioned above, we need to adapt to the Arm toolchain release > > naming convention. > > > > > Moreover, gcc now builds a package versioned as "arm-11.3-r2022.08", so it's > > > all over the place. > > > > How about following additional changes to bring consistency? > > > > diff --git a/meta-arm-toolchain/recipes-devtools/gcc/gcc-arm-11.3.inc > > b/meta-arm-toolchain/recipes-devtools/gcc/gcc-arm-11.3.inc > > index 8eba959..15a87d8 100644 > > --- a/meta-arm-toolchain/recipes-devtools/gcc/gcc-arm-11.3.inc > > +++ b/meta-arm-toolchain/recipes-devtools/gcc/gcc-arm-11.3.inc > > @@ -10,9 +10,7 @@ CVE_VERSION = "11.3" > > > > BINV = "11.3.1" > > > > -MMYY = "22.08" > > -RELEASE = "20${MMYY}" > > -PR = "r${RELEASE}" > > +PR = "Rel1" > > I'm going to pull in the patches as they currently are. Let's do > whatever fix-ups you two agree on with a follow-on patch. Ok, sounds good. I was testing Sumit's proposed changes above - I'll reply with the update soon. > Thanks, > Jon > > > > > > Not sure where ARM_GCC_SUB_VERSION comes into play, > > > certainly not in the package version. > > > > It's currently only used in toolchain source download path which uses lowercase: > > > > BASEURI ?= "https://developer.arm.com/-/media/Files/downloads/gnu/${ARM_GCC_VERSION}.${ARM_GCC_SUB_VERSION}/srcrel/arm-gnu-toolchain-src-snapshot-${ARM_GCC_VERSION}.${ARM_GCC_SUB_VERSION}.tar.xz" > > > > > > > > Should we try to standardize/unify these versioning mess here? I'd be happy to > > > stick to 2022.08 notation, if possible... > > > > > > > The 2022.08 isn't embedded within the toolchain build version: "gcc > > version 11.3.1 20220712 (Arm GNU Toolchain 11.3.Rel1)". So I am not > > sure if there is any alternative location within the pre-built > > toolchain to provide "2022.08" info. > > > > -Sumit > > > > > > > > > + elif version.split()[4] == '(GNU': > > > > # gcc version 9.2.1 20191025 (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) > > > > # gcc version 8.2.1 20180802 (GNU Toolchain for the A-profile Architecture 8.2-2018.11 (arm-rel-8.26)) > > > > return version.split()[10].split('-')[1] > > > > -- > > > > 2.17.1
diff --git a/ci/get-binary-toolchains b/ci/get-binary-toolchains index bfdd8c57..ed334bf3 100755 --- a/ci/get-binary-toolchains +++ b/ci/get-binary-toolchains @@ -2,7 +2,7 @@ set -u HOST_ARCH=$(uname -m) -VER="11.2-2022.02" +VER="11.3.rel1" DOWNLOAD_DIR=$1 TOOLCHAIN_DIR=$2 @@ -15,32 +15,32 @@ if [ $HOST_ARCH = "aarch64" ]; then #AArch64 Linux hosted cross compilers #AArch32 target with hard float (arm-none-linux-gnueabihf) - wget -P $DOWNLOAD_DIR -nc https://developer.arm.com/-/media/Files/downloads/gnu/$VER/binrel/gcc-arm-$VER-$HOST_ARCH-arm-none-linux-gnueabihf.tar.xz + wget -P $DOWNLOAD_DIR -nc https://developer.arm.com/-/media/Files/downloads/gnu/$VER/binrel/arm-gnu-toolchain-$VER-$HOST_ARCH-arm-none-linux-gnueabihf.tar.xz elif [ $HOST_ARCH = "x86_64" ]; then #x86_64 Linux hosted cross compilers #AArch32 target with hard float (arm-linux-none-gnueabihf) - wget -P $DOWNLOAD_DIR -nc https://developer.arm.com/-/media/Files/downloads/gnu/$VER/binrel/gcc-arm-$VER-$HOST_ARCH-arm-none-linux-gnueabihf.tar.xz + wget -P $DOWNLOAD_DIR -nc https://developer.arm.com/-/media/Files/downloads/gnu/$VER/binrel/arm-gnu-toolchain-$VER-$HOST_ARCH-arm-none-linux-gnueabihf.tar.xz #AArch64 GNU/Linux target (aarch64-none-linux-gnu) - wget -P $DOWNLOAD_DIR -nc https://developer.arm.com/-/media/Files/downloads/gnu/$VER/binrel/gcc-arm-$VER-$HOST_ARCH-aarch64-none-linux-gnu.tar.xz + wget -P $DOWNLOAD_DIR -nc https://developer.arm.com/-/media/Files/downloads/gnu/$VER/binrel/arm-gnu-toolchain-$VER-$HOST_ARCH-aarch64-none-linux-gnu.tar.xz #AArch64 GNU/Linux target (aarch64_be-none-linux-gnu) - wget -P $DOWNLOAD_DIR -nc https://developer.arm.com/-/media/Files/downloads/gnu/$VER/binrel/gcc-arm-$VER-$HOST_ARCH-aarch64_be-none-linux-gnu.tar.xz + wget -P $DOWNLOAD_DIR -nc https://developer.arm.com/-/media/Files/downloads/gnu/$VER/binrel/arm-gnu-toolchain-$VER-$HOST_ARCH-aarch64_be-none-linux-gnu.tar.xz else echo "ERROR - Unknown build arch of $HOST_ARCH" exit 1 fi for i in arm aarch64 aarch64_be; do - if [ ! -d $TOOLCHAIN_DIR/gcc-arm-$VER-$HOST_ARCH-$i-none-linux-gnu*/ ]; then - if [ ! -f $DOWNLOAD_DIR/gcc-arm-$VER-$HOST_ARCH-$i-none-linux-gnu*.tar.xz ]; then + if [ ! -d $TOOLCHAIN_DIR/arm-gnu-toolchain-$VER-$HOST_ARCH-$i-none-linux-gnu*/ ]; then + if [ ! -f $DOWNLOAD_DIR/arm-gnu-toolchain-$VER-$HOST_ARCH-$i-none-linux-gnu*.tar.xz ]; then continue fi - tar -C $TOOLCHAIN_DIR -axvf $DOWNLOAD_DIR/gcc-arm-$VER-$HOST_ARCH-$i-none-linux-gnu*.tar.xz + tar -C $TOOLCHAIN_DIR -axvf $DOWNLOAD_DIR/arm-gnu-toolchain-$VER-$HOST_ARCH-$i-none-linux-gnu*.tar.xz fi # Setup a link for the toolchain to use local to the building machine (e.g., not in a shared location) - ln -s $TOOLCHAIN_DIR/gcc-arm-$VER-$HOST_ARCH-$i-none-linux-gnu* $TOOLCHAIN_LINK_DIR/$i + ln -s $TOOLCHAIN_DIR/arm-gnu-toolchain-$VER-$HOST_ARCH-$i-none-linux-gnu* $TOOLCHAIN_LINK_DIR/$i done diff --git a/meta-arm-toolchain/conf/distro/include/external-arm-toolchain-versions.inc b/meta-arm-toolchain/conf/distro/include/external-arm-toolchain-versions.inc index 244de26a..92fb038c 100644 --- a/meta-arm-toolchain/conf/distro/include/external-arm-toolchain-versions.inc +++ b/meta-arm-toolchain/conf/distro/include/external-arm-toolchain-versions.inc @@ -23,12 +23,15 @@ def eat_get_version(d): last_line = stderr.splitlines()[-1] return last_line -# Extract the YYYY.MM version +# Extract the YYYY.MM or release version def eat_get_main_version(d): version = eat_get_version(d) bb.debug(2, 'Trying for parse version info from: %s' % version) if version != 'UNKNOWN': - if version.split()[4] == '(GNU': + if version.split()[4] == '(Arm': + # gcc version 11.3.1 20220712 (Arm GNU Toolchain 11.3.Rel1) + return version.split()[7].split(')')[0] + elif version.split()[4] == '(GNU': # gcc version 9.2.1 20191025 (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) # gcc version 8.2.1 20180802 (GNU Toolchain for the A-profile Architecture 8.2-2018.11 (arm-rel-8.26)) return version.split()[10].split('-')[1]
Enable support for 11.3.rel1 binary toolchain release. Also, update CI to use it. Signed-off-by: Sumit Garg <sumit.garg@linaro.org> --- ci/get-binary-toolchains | 18 +++++++++--------- .../external-arm-toolchain-versions.inc | 7 +++++-- 2 files changed, 14 insertions(+), 11 deletions(-)