| Message ID | 20240109103953.1112223-1-neal.frager@amd.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v2,1/1] configure.ac: configurable tooldir install path | expand |
Hi Jeff, Thomas, Thank you both for your assistance with the patch below. I am now dealing with a version conflict between newlib and buildroot. I hope you can help me find the best solution for it. On my machine, I have tested the patch below using autoconf 2.69. However, the goal is for this patch is to ultimately integrate with buildroot. Currently, buildroot hardcodes the autoconf version that it builds and uses to version 2.71. But with autoconf version 2.71, I get the following error from the newlib configure.ac because it requires specifically version 2.69: >>> newlib-bare-metal 4.3.0 Autoreconfiguring configure.ac:34: error: Please use exactly Autoconf 2.69 instead of 2.71. config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is expanded from... configure.ac:34: the top level As you are newlib and buildroot maintainers, could you please help me with guidance about how to resolve this issue? I can easily make a patch to make the autoconf version used by buildroot configurable, but I would like your opinions before I proceed. Thank you again for your support! Best regards, Neal Frager AMD > This patch is required to fix how the newlib headers are installed > when using a sysroot install directory. > The cross compiler expects headers to be in > .../host/usr/arm-none-eabi/sysroot/usr/include/newlib.h > by default newlib installed the headers into > .../host/usr/arm-none-eabi/sysroot/usr/arm-none-eabi/include/newlib.h > ${exec_prefix} provides the .../host/usr/arm-none-eabi/sysroot path > ${target_noncanonical} provides an extra arm-none-eabi/ that must be removed. > With this patch, users can specify the tooldir path that is needed. > Signed-off-by: Neal Frager <neal.frager@amd.com> > Co-developed-by: Chris Wardman <cjwfirmware@vxmdesign.com> > --- > V1->V2: > - migrated patch to configure.ac > - changed option name to --with-tooldir=PATH > --- > configure.ac | 13 ++++++++++++- > 1 file changed, 12 insertions(+), 1 deletion(-) > diff --git a/configure.ac b/configure.ac > index f1bb72100..9a01c1562 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -2599,7 +2599,18 @@ esac > # Some systems (e.g., one of the i386-aix systems the gas testers are > # using) don't handle "\$" correctly, so don't use it here. > -tooldir='${exec_prefix}'/${target_noncanonical} > +AC_ARG_WITH([tooldir], > + [AS_HELP_STRING([--with-tooldir=PATH], > + [use given path to install target tools after build])], > + [case x"$withval" in > + x/*) ;; > + *) > + with_tooldir= > + AC_MSG_WARN([argument to --with-tooldir must be an absolute path]) > + ;; > + esac], > + [with_tooldir='${exec_prefix}'/${target_noncanonical}]) > +tooldir='${with_tooldir}' > build_tooldir=${tooldir} > # Create a .gdbinit file which runs the one in srcdir > -- > 2.25.1
Hi Thomas, > Le 9 janv. 2024 à 15:18, Frager, Neal <neal.frager@amd.com> a écrit : > > Hi Jeff, Thomas, > > Thank you both for your assistance with the patch below. > > I am now dealing with a version conflict between newlib and buildroot. > I hope you can help me find the best solution for it. > > On my machine, I have tested the patch below using autoconf 2.69. > > However, the goal is for this patch is to ultimately integrate with > buildroot. > > Currently, buildroot hardcodes the autoconf version that it builds > and uses to version 2.71. > > But with autoconf version 2.71, I get the following error from the > newlib configure.ac because it requires specifically version 2.69: > >>>> newlib-bare-metal 4.3.0 Autoreconfiguring > configure.ac:34: error: Please use exactly Autoconf 2.69 instead of 2.71. > config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is expanded from... > configure.ac:34: the top level > > As you are newlib and buildroot maintainers, could you > please help me with guidance about how to resolve this > issue? > > I can easily make a patch to make the autoconf version used > by buildroot configurable, but I would like your opinions > before I proceed. > I do have another idea. Once a version of this patch gets applied to newlib, I could make a separate patch for buildroot that patches the output configure file to match the one that gets generated by autoreconf version 2.69. This way, we can use a separate patch for buildroot that creates the correct output configure file without invoking autoreconf as a build step. And eventually, we remove the patch from buildroot when we can update to a newer release version of newlib which no longer requires a patch. What do you think of this solution? Best regards, Neal Frager AMD > Thank you again for your support! > > Best regards, > Neal Frager > AMD > >> This patch is required to fix how the newlib headers are installed >> when using a sysroot install directory. > >> The cross compiler expects headers to be in >> .../host/usr/arm-none-eabi/sysroot/usr/include/newlib.h >> by default newlib installed the headers into >> .../host/usr/arm-none-eabi/sysroot/usr/arm-none-eabi/include/newlib.h > >> ${exec_prefix} provides the .../host/usr/arm-none-eabi/sysroot path >> ${target_noncanonical} provides an extra arm-none-eabi/ that must be removed. > >> With this patch, users can specify the tooldir path that is needed. > >> Signed-off-by: Neal Frager <neal.frager@amd.com> >> Co-developed-by: Chris Wardman <cjwfirmware@vxmdesign.com> >> --- >> V1->V2: >> - migrated patch to configure.ac >> - changed option name to --with-tooldir=PATH >> --- >> configure.ac | 13 ++++++++++++- >> 1 file changed, 12 insertions(+), 1 deletion(-) > >> diff --git a/configure.ac b/configure.ac >> index f1bb72100..9a01c1562 100644 >> --- a/configure.ac >> +++ b/configure.ac >> @@ -2599,7 +2599,18 @@ esac > >> # Some systems (e.g., one of the i386-aix systems the gas testers are >> # using) don't handle "\$" correctly, so don't use it here. >> -tooldir='${exec_prefix}'/${target_noncanonical} >> +AC_ARG_WITH([tooldir], >> + [AS_HELP_STRING([--with-tooldir=PATH], >> + [use given path to install target tools after build])], >> + [case x"$withval" in >> + x/*) ;; >> + *) >> + with_tooldir= >> + AC_MSG_WARN([argument to --with-tooldir must be an absolute path]) >> + ;; >> + esac], >> + [with_tooldir='${exec_prefix}'/${target_noncanonical}]) >> +tooldir='${with_tooldir}' >> build_tooldir=${tooldir} > >> # Create a .gdbinit file which runs the one in srcdir >> -- >> 2.25.1 >
[CC Mike] Maybe we should switch newlib/cygwin to 2.71 as well, eventually? We're in the process of preparing the next Cygwin release which should be due end of this month. After that I don't see any reason that we can't bumb the configury to the latest autotools. Corinna On Jan 9 14:18, Frager, Neal wrote: > Hi Jeff, Thomas, > > Thank you both for your assistance with the patch below. > > I am now dealing with a version conflict between newlib and buildroot. > I hope you can help me find the best solution for it. > > On my machine, I have tested the patch below using autoconf 2.69. > > However, the goal is for this patch is to ultimately integrate with > buildroot. > > Currently, buildroot hardcodes the autoconf version that it builds > and uses to version 2.71. > > But with autoconf version 2.71, I get the following error from the > newlib configure.ac because it requires specifically version 2.69: > > >>> newlib-bare-metal 4.3.0 Autoreconfiguring > configure.ac:34: error: Please use exactly Autoconf 2.69 instead of 2.71. > config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is expanded from... > configure.ac:34: the top level > > As you are newlib and buildroot maintainers, could you > please help me with guidance about how to resolve this > issue? > > I can easily make a patch to make the autoconf version used > by buildroot configurable, but I would like your opinions > before I proceed. > > Thank you again for your support! > > Best regards, > Neal Frager > AMD > > > This patch is required to fix how the newlib headers are installed > > when using a sysroot install directory. > > > The cross compiler expects headers to be in > > .../host/usr/arm-none-eabi/sysroot/usr/include/newlib.h > > by default newlib installed the headers into > > .../host/usr/arm-none-eabi/sysroot/usr/arm-none-eabi/include/newlib.h > > > ${exec_prefix} provides the .../host/usr/arm-none-eabi/sysroot path > > ${target_noncanonical} provides an extra arm-none-eabi/ that must be removed. > > > With this patch, users can specify the tooldir path that is needed. > > > Signed-off-by: Neal Frager <neal.frager@amd.com> > > Co-developed-by: Chris Wardman <cjwfirmware@vxmdesign.com> > > --- > > V1->V2: > > - migrated patch to configure.ac > > - changed option name to --with-tooldir=PATH > > --- > > configure.ac | 13 ++++++++++++- > > 1 file changed, 12 insertions(+), 1 deletion(-) > > > diff --git a/configure.ac b/configure.ac > > index f1bb72100..9a01c1562 100644 > > --- a/configure.ac > > +++ b/configure.ac > > @@ -2599,7 +2599,18 @@ esac > > > # Some systems (e.g., one of the i386-aix systems the gas testers are > > # using) don't handle "\$" correctly, so don't use it here. > > -tooldir='${exec_prefix}'/${target_noncanonical} > > +AC_ARG_WITH([tooldir], > > + [AS_HELP_STRING([--with-tooldir=PATH], > > + [use given path to install target tools after build])], > > + [case x"$withval" in > > + x/*) ;; > > + *) > > + with_tooldir= > > + AC_MSG_WARN([argument to --with-tooldir must be an absolute path]) > > + ;; > > + esac], > > + [with_tooldir='${exec_prefix}'/${target_noncanonical}]) > > +tooldir='${with_tooldir}' > > build_tooldir=${tooldir} > > > # Create a .gdbinit file which runs the one in srcdir > > -- > > 2.25.1
On 10 Jan 2024 10:53, Corinna Vinschen wrote: > Maybe we should switch newlib/cygwin to 2.71 as well, eventually? > > We're in the process of preparing the next Cygwin release which should > be due end of this month. After that I don't see any reason that we > can't bumb the configury to the latest autotools. i'm not a fan of diverging from the rest of the source projects. i want the rest of gcc/binutils/gdb move to autoconf-2.71 & automake-1.16, but i don't have the cycles to drive that. i'm also not sure what their preference is when it comes to release timings. autoconf-2.69: Apr 2012 2.70: Dec 2020 2.71: Jan 2021 automake-1.15: Dec 2014 1.15.1: Jun 2017 1.16: Feb 2018 1.16.5: Oct 2021 personally i think 2 years is enough for the dev population who actually work on these projects, but who knows. gcc is currently on autoconf-2.69. it enforces this: config/override.m4: dnl Ensure exactly this Autoconf version is used m4_ifndef([_GCC_AUTOCONF_VERSION], [m4_define([_GCC_AUTOCONF_VERSION], [2.69])]) dnl Test for the exact version when AC_INIT is expanded. $ autoconf-2.71 ... configure.ac:4: error: Please use exactly Autoconf 2.69 instead of 2.71. ../config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is expanded from... configure.ac:4: the top level autom4te-2.71: error: /usr/bin/m4 failed with exit status: 1 now, override.m4 does have an override, but it's meant for testing purposes, and it doesn't mean anything else in the config/ macro tree has been tested. dnl This allows to update the tree in steps (for testing) dnl by putting dnl m4_define([_GCC_AUTOCONF_VERSION], [X.Y]) dnl in configure.ac before AC_INIT, dnl without rewriting this file. which we can see: $ cd newlib $ sed -i '1im4_define([_GCC_AUTOCONF_VERSION], [2.71])' configure.ac $ autoreconf -f configure.ac:317: warning: The macro `AC_OUTPUT_COMMANDS' is obsolete. configure.ac:317: You should run autoupdate. ./lib/autoconf/status.m4:1025: AC_OUTPUT_COMMANDS is expanded from... ../config/multi.m4:14: AM_ENABLE_MULTILIB is expanded from... configure.ac:317: the top level configure.ac:317: warning: The macro `AC_OUTPUT_COMMANDS' is obsolete. configure.ac:317: You should run autoupdate. ./lib/autoconf/status.m4:1025: AC_OUTPUT_COMMANDS is expanded from... ../config/multi.m4:14: AM_ENABLE_MULTILIB is expanded from... configure.ac:317: the top level configure.ac:317: warning: The macro `AC_OUTPUT_COMMANDS' is obsolete. configure.ac:317: You should run autoupdate. ./lib/autoconf/status.m4:1025: AC_OUTPUT_COMMANDS is expanded from... ../config/multi.m4:14: AM_ENABLE_MULTILIB is expanded from... configure.ac:317: the top level -mike
On Jan 10 10:03, Mike Frysinger wrote: > On 10 Jan 2024 10:53, Corinna Vinschen wrote: > > Maybe we should switch newlib/cygwin to 2.71 as well, eventually? > > > > We're in the process of preparing the next Cygwin release which should > > be due end of this month. After that I don't see any reason that we > > can't bumb the configury to the latest autotools. > > i'm not a fan of diverging from the rest of the source projects. i want > the rest of gcc/binutils/gdb move to autoconf-2.71 & automake-1.16, but > i don't have the cycles to drive that. i'm also not sure what their > preference is when it comes to release timings. > autoconf-2.69: Apr 2012 > 2.70: Dec 2020 > 2.71: Jan 2021 > automake-1.15: Dec 2014 > 1.15.1: Jun 2017 > 1.16: Feb 2018 > 1.16.5: Oct 2021 > personally i think 2 years is enough for the dev population who actually > work on these projects, but who knows. > > gcc is currently on autoconf-2.69. it enforces this: > config/override.m4: > dnl Ensure exactly this Autoconf version is used > m4_ifndef([_GCC_AUTOCONF_VERSION], > [m4_define([_GCC_AUTOCONF_VERSION], [2.69])]) > dnl Test for the exact version when AC_INIT is expanded. Right. We shouldn't switch to 2.71 before gcc/binutils/gdb did. I thought they already switched, sorry for not checking myself. Thanks, Corinna
On 10 Jan 2024 17:21, Corinna Vinschen wrote: > On Jan 10 10:03, Mike Frysinger wrote: > > On 10 Jan 2024 10:53, Corinna Vinschen wrote: > > > Maybe we should switch newlib/cygwin to 2.71 as well, eventually? > > > > > > We're in the process of preparing the next Cygwin release which should > > > be due end of this month. After that I don't see any reason that we > > > can't bumb the configury to the latest autotools. > > > > i'm not a fan of diverging from the rest of the source projects. i want > > the rest of gcc/binutils/gdb move to autoconf-2.71 & automake-1.16, but > > i don't have the cycles to drive that. i'm also not sure what their > > preference is when it comes to release timings. > > autoconf-2.69: Apr 2012 > > 2.70: Dec 2020 > > 2.71: Jan 2021 > > automake-1.15: Dec 2014 > > 1.15.1: Jun 2017 > > 1.16: Feb 2018 > > 1.16.5: Oct 2021 > > personally i think 2 years is enough for the dev population who actually > > work on these projects, but who knows. > > > > gcc is currently on autoconf-2.69. it enforces this: > > config/override.m4: > > dnl Ensure exactly this Autoconf version is used > > m4_ifndef([_GCC_AUTOCONF_VERSION], > > [m4_define([_GCC_AUTOCONF_VERSION], [2.69])]) > > dnl Test for the exact version when AC_INIT is expanded. > > Right. We shouldn't switch to 2.71 before gcc/binutils/gdb did. > I thought they already switched, sorry for not checking myself. if gcc switches, then yeah, we def should switch newlib, and that part i could help with if no one else gets to it first. -mike
diff --git a/configure.ac b/configure.ac index f1bb72100..9a01c1562 100644 --- a/configure.ac +++ b/configure.ac @@ -2599,7 +2599,18 @@ esac # Some systems (e.g., one of the i386-aix systems the gas testers are # using) don't handle "\$" correctly, so don't use it here. -tooldir='${exec_prefix}'/${target_noncanonical} +AC_ARG_WITH([tooldir], + [AS_HELP_STRING([--with-tooldir=PATH], + [use given path to install target tools after build])], + [case x"$withval" in + x/*) ;; + *) + with_tooldir= + AC_MSG_WARN([argument to --with-tooldir must be an absolute path]) + ;; + esac], + [with_tooldir='${exec_prefix}'/${target_noncanonical}]) +tooldir='${with_tooldir}' build_tooldir=${tooldir} # Create a .gdbinit file which runs the one in srcdir
This patch is required to fix how the newlib headers are installed when using a sysroot install directory. The cross compiler expects headers to be in .../host/usr/arm-none-eabi/sysroot/usr/include/newlib.h by default newlib installed the headers into .../host/usr/arm-none-eabi/sysroot/usr/arm-none-eabi/include/newlib.h ${exec_prefix} provides the .../host/usr/arm-none-eabi/sysroot path ${target_noncanonical} provides an extra arm-none-eabi/ that must be removed. With this patch, users can specify the tooldir path that is needed. Signed-off-by: Neal Frager <neal.frager@amd.com> Co-developed-by: Chris Wardman <cjwfirmware@vxmdesign.com> --- V1->V2: - migrated patch to configure.ac - changed option name to --with-tooldir=PATH --- configure.ac | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)