Library fails to build if "autoreconf -i" is run before ./configure

Question

I'm working with a tool that is supposed to simplify the build process of Unix-based apps. One of the things it does automatically is run "autoreconf -i" before doing "./configure". However, when it tries to build the expat library on OSX (Lion), the build fails:

$ tar xfz expat-2.0.1.tar.gz; cd expat-2.0.1
$ autoreconf -i
glibtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `conftools'.
glibtoolize: copying file `conftools/ltmain.sh'
glibtoolize: You should add the contents of the following files to `aclocal.m4':
glibtoolize:   `/usr/bin/../share/aclocal/libtool.m4'
glibtoolize:   `/usr/bin/../share/aclocal/ltoptions.m4'
glibtoolize:   `/usr/bin/../share/aclocal/ltversion.m4'
glibtoolize:   `/usr/bin/../share/aclocal/ltsugar.m4'
glibtoolize:   `/usr/bin/../share/aclocal/lt~obsolete.m4'
glibtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and
glibtoolize: rerunning glibtoolize, to keep the correct libtool macros in-tree.
glibtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
$ ./configure
(Lots of output here)
configure: creating ./config.status
config.status: creating Makefile
config.status: WARNING:  Makefile.in seems to ignore the --datarootdir setting
config.status: creating expat_config.h    
$ make
bin/sh ./libtool --silent --mode=compile gcc -std=gnu99 -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions  -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c
./libtool: line 473: CDPATH: command not found
./libtool: line 1297: func_opt_split: command not found
libtool: Version mismatch error.  This is libtool 2.2.10, but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.10
libtool: and run autoconf again.

On the other hand, if I don't do autoreconf first, it build just fiine:

$ cd ..; rm -r expat-2.0.1; tar xfz expat-2.0.1.tar.gz; cd expat-2.0.1
$ ./configure
(Lots of output here)
configure: creating ./config.status
config.status: creating Makefile
config.status: creating expat_config.h    
$ make
/bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions  -DHAVE_EXPAT_CONFIG_H -o lib/xmlparse.lo -c lib/xmlparse.c
/bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions  -DHAVE_EXPAT_CONFIG_H -o lib/xmltok.lo -c lib/xmltok.c
/bin/sh ./libtool --silent --mode=compile gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions  -DHAVE_EXPAT_CONFIG_H -o lib/xmlrole.lo -c lib/xmlrole.c
/bin/sh ./libtool --silent --mode=link gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions  -DHAVE_EXPAT_CONFIG_H -no-undefined -version-info 6:2:5 -rpath /usr/local/lib  -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo
gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions  -DHAVE_EXPAT_CONFIG_H -o xmlwf/xmlwf.o -c xmlwf/xmlwf.c
gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions  -DHAVE_EXPAT_CONFIG_H -o xmlwf/xmlfile.o -c xmlwf/xmlfile.c
gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions  -DHAVE_EXPAT_CONFIG_H -o xmlwf/codepage.o -c xmlwf/codepage.c
gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions  -DHAVE_EXPAT_CONFIG_H -o xmlwf/unixfilemap.o -c xmlwf/unixfilemap.c
/bin/sh ./libtool --silent --mode=link gcc -I./lib -I. -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions  -DHAVE_EXPAT_CONFIG_H  -o xmlwf/xmlwf xmlwf/xmlwf.o xmlwf/xmlfile.o xmlwf/codepage.o xmlwf/unixfilemap.o libexpat.la

What is "autoreconf -i" doing, and why is it causing the build to fail?

Answer 1

I think the problem is here:

libtool: Version mismatch error.  This is libtool 2.2.10, but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.10
libtool: and run autoconf again.

In my experience with OS X Leopard and Snow Leopard (I have not tried Lion yet), the autotools actually installed with OS X are not recent enough to actually reconfigure anything for the system. So I usually grab the latest autotools from a GNU mirror and make a local version of them if I need to reconfigure.

"autoreconf -i" copies files from the installed GNU autotools to AC_CONFIG_AUX_DIR, an in this case is probably ltmain.sh.

Answer 2

A user should never run autoreconf. As ldav1s points out (+1), the autotools installed on your box do not match the tools used to generate the tarball. There are many packages in the wild that recommend (or even require) the user to run autoconf in some form to build the package; those packages are broken. A properly built package should build on a machine that does not have any of the autotools installed, and unless you are a package maintainer you should probably just uninstall them. IMO, they should not be included in default installations.

If you use a package that requires the autotools to build, please report that as a bug to the package maintainer. If a version control system (eg git, hg, svn ) is being used as the distribution mechanism, then you will either need to run the autotools to build the package or the package will have to include autotools generated files in the repository. This is why version control systems should not be used as a distribution tool for packages that use the autotools.