[PATCH v2 1/1] configure.ac: configurable tooldir install path

[PATCH v2 1/1] configure.ac: configurable tooldir install path

[Neal Frager]

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

RE: [PATCH v2 1/1] configure.ac: configurable tooldir install path

[Frager, Neal]

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

Re: [PATCH v2 1/1] configure.ac: configurable tooldir install path

[Frager, Neal]

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
> 

Re: [PATCH v2 1/1] configure.ac: configurable tooldir install path

[Corinna Vinschen]

[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

Re: [PATCH v2 1/1] configure.ac: configurable tooldir install path

[Mike Frysinger]

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2 1/1] configure.ac: configurable tooldir install path

[Corinna Vinschen]

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

Re: [PATCH v2 1/1] configure.ac: configurable tooldir install path

[Mike Frysinger]

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]