This is the mail archive of the
newlib@sources.redhat.com
mailing list for the newlib project.
Re: how to run automake/conf on newlib
- From: Joel Sherrill <joel dot sherrill at OARcorp dot com>
- To: "J. Johnston" <jjohnstn at redhat dot com>
- Cc: newlib at sources dot redhat dot com
- Date: Wed, 08 Jan 2003 12:36:08 -0600
- Subject: Re: how to run automake/conf on newlib
- Organization: OAR Corporation
- References: <3D385576.410BCB39@OARcorp.com> <3D386F07.ADBF17F9@redhat.com> <3E19BBCF.D4A56FA5@OARcorp.com> <3E1A1D12.8010205@redhat.com>
"J. Johnston" wrote:
>
> The instructions are valid. I am able to use autoconf 2.13 in
> the specified directory with no problems. I do not know why your autoconf 2.13
> is failing and mine works fine. Perhaps this is an issue for the autoconf
> maintainers.
Could you please doublecheck your auto* versions against newlib 1.11.0
and report the versions you are using?
I think you have to use a new autoconf and an old automake. I think
I made it work with the combination of autoconf 2.57 and automake
1.4-p5.
> Newlib has never tested using autoconf 2.5x and it is not
> supported.
Hmmm... me thinks you are wrong here. newlib 1.11.0 has
this all over the place:
../a29k/configure.in:AC_PREREQ(2.5)
../arm/configure.in:AC_PREREQ(2.5)
../d10v/configure.in:AC_PREREQ(2.5)
../d30v/configure.in:AC_PREREQ(2.5)
I think the combination is old automake and new autoconf. <sigh> This
is a weird combination. All the other tools I have done this with are
either stuck on old versions or at the bleeding edge. I haven't seen
one straddling the fence like this.
--joel
> -- Jeff J.
>
> Joel Sherrill wrote:
> > Jeff, are these instructions still current with newlib 1.11.0?
> >
> > I am updating the patch that adds the ARM memcpy.S with the
> > advertising license and getting these results when I run autoconf
> > in the libc/machine/arm subdirectory.
> >
> > bash-2.05$ /usr/bin/autoconf --version
> > Autoconf version 2.13
> > bash-2.05$ /usr/bin/autoconf
> > FATAL ERROR: Autoconf version 2.54 or higher is required for this script
> > bash-2.05$ autoconf --version
> > autoconf (GNU Autoconf) 2.57
> > Written by David J. MacKenzie and Akim Demaille.
> >
> > Copyright 2002 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions. There is
> > NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> > PURPOSE.
> > bash-2.05$ autoconf
> > configure:1895: error: possibly undefined macro: AC_PROG_CC_GNU
> > If this token and others are legitimate, please use
> > m4_pattern_allow.
> > See the Autoconf documentation.
> > configure:1902: error: possibly undefined macro: AC_PROG_CC_G
> >
> > On a positive note, newlib 1.11.0 appears to have nearly all of the
> > patches that were in the RTEMS patch. I need to confirm that the
> > signal.h changes we had are no longer needed though.
> >
> > Thanks.
> >
> > --joel
> >
> > "J. Johnston" wrote:
> >
> >>The steps in the machine/xxx dir would be:
> >>
> >> 1. aclocal -I ../../.. /* the -I ../../.. points to the top-level newlib dir */
> >> 2. autoconf
> >> 3. automake --cygnus Makefile
> >>
> >>Step 1 above has a dependency on newlib/acinclude.m4 and configure.in.
> >>Step 2 is dependent on configure.in and aclocal.m4. Step 3 is dependent on
> >>Makefile.am, configure.in, and aclocal.m4. Simply put: if you do any step
> >>because of a change, all steps after it should be done as well.
> >>
> >>You should only have to redo aclocal if the top-level acinclude.m4 changes
> >>or you change macros you are using in your configure.in. You don't have to
> >>guard against the latter case by running aclocal - just be aware of it if autoconf
> >>complains about a missing macro after you make a configure.in change.
> >>
> >>We currently use autoconf 2.13 and automake 1.4.
> >>
> >>-- Jeff J.
> >
> >
--
Joel Sherrill, Ph.D. Director of Research & Development
joel@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985