Updating top-level autoconf to 2.59

Maciej W. Rozycki macro@linux-mips.org
Fri Feb 9 17:40:00 GMT 2007

On Fri, 9 Feb 2007, Daniel Jacobowitz wrote:

> On Fri, Feb 09, 2007 at 04:13:43PM +0000, Maciej W. Rozycki wrote:
> >  I see, though frankly I wouldn't consider switching from 2.59 to 2.61 too 
> > much of a project.  And certainly much less than doing the 2.13 to 2.59 
> > conversion at the top level.  Of course in 2.61 there may be different 
> > bugs than in 2.59, but I gather the new version is not meant to imply any 
> > kind of revolution.  Even if there were some subtle problems somewhere, 
> > they should get sorted out as things go by stage 3.
> > 
> >  Or is it because of the new structure of install directories?
> There's simply too many directories.  We'd want to upgrade all of src
> and gcc at once.

 Sure -- I use a script like this for regenerating all the scripts:

for name in `find . -name 'configure.[ai][cn]' -exec dirname "{}" \;`; do
	(cd $name && autoconf)
	if [ $STATUS -ne 0 ]; then
		exit $STATUS

I have similar scripts for running `libtoolize', `aclocal', `autoheader' 
and `automake' if interested.  They should make the tree consistent, 
though configuring and running `make' may be necessary afterwards and 
before committing the changes for some timestamps to be updated (most 
notably for results of `autoheader').

 BTW, do we still want to carry local copies of severely obsolete libtool 
scripts?  I have had success with libtool 1.5.22 and GCC 4.1.1 after a 
moderate amount of work (mostly shuffling bits around; libjava/ was the 
most involving part) -- if there is interest in upgrading (which might 
help some people with less common configurations) I could port them to the 
trunk sooner rather than later.

> And yes, there are some troublesome changes - like, if you don't adjust
> your makefiles, you get warnings about ignoring datarootdir.

 Indeed, though they are not fatal.  Perhaps Makefile.in files in the 
affected directories (Makefile.am are OK as sufficiently new automake will 
deal with that) could get updated beforehand?  It should not hurt at all.


More information about the Newlib mailing list