autogen.sh is incomplete

Question

autogen.sh is incomplete

bhaible opened this issue 5 months ago · comments

I'm trying to build the master branch off a git repository checkout.

I have the relevant tools installed (all built from source):

$ autoconf --version
autoconf (GNU Autoconf) 2.72
$ automake --version
automake (GNU automake) 1.16.5
$ libtoolize --version
libtoolize (GNU libtool) 2.4.7

autogen.sh fails:

$ ./autogen.sh 
configure.ac:39: error: possibly undefined macro: AC_ENABLE_SHARED
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
autoreconf: error: /darch/x86_64-linux-gnu/gnu/bin/autoconf failed with exit status: 1

Bruno Haible · Answer 1 · Fri Jan 26 2024 20:48:36 GMT+0800 (China Standard Time)

The reason is that libtool.m4 is not in the build tree. It needs to be fetched first. And, with it, an ltmain.sh from the same libtool version needs to be installed. The following proposed patch achieves it:

0001-Install-libtool.m4-and-ltmain.sh-in-the-build-tree-b.patch.gz

Ivan Maidanski · Answer 2 · Fri Jan 26 2024 22:00:54 GMT+0800 (China Standard Time)

autogen.sh works, please see e.g. https://app.travis-ci.com/github/ivmai/bdwgc/jobs/616798920

This duplicates report #75

Let me know if you still think the patch should be applied.

Bruno Haible · Answer 3 · Fri Jan 26 2024 22:26:59 GMT+0800 (China Standard Time)

autogen.sh works

It does not work for me, since autoreconf -i fails to install libtool.m4 and ltmain.sh:

$ autoreconf -i -v
autoreconf: export WARNINGS=
autoreconf: Entering directory '.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal -I m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: subdirectory libatomic_ops not present
autoreconf: configure.ac: not using Libtool
autoreconf: configure.ac: not using Intltool
autoreconf: configure.ac: not using Gtkdoc
autoreconf: running: /darch/x86_64-linux-gnu/gnu/bin/autoconf
configure.ac:39: error: possibly undefined macro: AC_ENABLE_SHARED
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
autoreconf: error: /darch/x86_64-linux-gnu/gnu/bin/autoconf failed with exit status: 1

autoreconf invokes libtoolize only if both Autoconf and Libtool have been installed with the same --prefix value (or if m4/libtool.m4 is already present — but after a fresh git clone, it is not present). But that is not necessarily the case. Autoconf being Free Software, it is normal that users install it with a --prefix different from /usr, and have libtoolize still visible in /usr/bin.

Let me know if you still think the patch should be applied.

Yes, the patch is necessary for those people who have autoreconf and libtoolize available from different directories of $PATH.

Ivan Maidanski · Answer 4 · Sat Jan 27 2024 01:14:26 GMT+0800 (China Standard Time)

I see, I'll process your patch.

Ivan Maidanski · Answer 5 · Sat Jan 27 2024 01:15:25 GMT+0800 (China Standard Time)

BTW. Do you observe the same issue in https://github.com/ivmai/libatomic_ops project?

Bruno Haible · Answer 6 · Sat Jan 27 2024 05:09:33 GMT+0800 (China Standard Time)

Do you observe the same issue in https://github.com/ivmai/libatomic_ops project?

Yes, it's the same issue:

$ ./autogen.sh 
configure.ac:27: installing './compile'
configure.ac:18: installing './config.guess'
configure.ac:18: installing './config.sub'
configure.ac:21: installing './install-sh'
configure.ac:21: installing './missing'
src/Makefile.am:14: error: Libtool library used but 'LIBTOOL' is undefined
src/Makefile.am:14:   The usual way to define 'LIBTOOL' is to add 'LT_INIT'
src/Makefile.am:14:   to 'configure.ac' and run 'aclocal' and 'autoconf' again.
src/Makefile.am:14:   If 'LT_INIT' is in 'configure.ac', make sure
src/Makefile.am:14:   its definition is in aclocal's search path.
src/Makefile.am: installing './depcomp'
parallel-tests: installing './test-driver'
autoreconf: error: automake failed with exit status: 1

This patch (for the libatomic_ops project) fixes it:
0001-Install-libtool.m4-and-ltmain.sh-in-the-build-tree-b.patch.gz

Ivan Maidanski · Answer 7 · Sat Jan 27 2024 16:13:13 GMT+0800 (China Standard Time)

This patch (for the libatomic_ops project) fixes it:
0001-Install-libtool.m4-and-ltmain.sh-in-the-build-tree-b.patch.gz

Thank you. Committed as ivmai/libatomic_ops@c9ebc16

Ivan Maidanski · Answer 8 · Sat Jan 27 2024 16:15:36 GMT+0800 (China Standard Time)

Hmm. The patch introduces a build failure - https://app.travis-ci.com/github/ivmai/libatomic_ops/jobs/616931164
libtoolize: command not found
Could you please suggest a fix?

Ivan Maidanski · Answer 9 · Sat Jan 27 2024 16:18:06 GMT+0800 (China Standard Time)

Also, I got such error on cygwin:

libtoolize:   error: Files
libtoolize: putting auxiliary files in '..'.
libtoolize:   error: '../config.guess' exists: use '--force' to overwrite
libtoolize:   error: '../config.sub' exists: use '--force' to overwrite

Ivan Maidanski · Answer 10 · Sun Jan 28 2024 03:20:39 GMT+0800 (China Standard Time)

Hmm. The patch introduces a build failure - https://app.travis-ci.com/github/ivmai/libatomic_ops/jobs/616931164 libtoolize: command not found Could you please suggest a fix?

I will change libtoolize invocation code to:

if which libtoolize > /dev/null 2>&1; then
  libtoolize -i -c
else
  echo "libtoolize is not found, ignoring!"
fi

Commit ivmai/libatomic_ops@7d27217

Ivan Maidanski · Answer 11 · Sun Jan 28 2024 03:23:06 GMT+0800 (China Standard Time)

I got such error on cygwin:
libtoolize: error: Files

I can't google anything useful about this error message. Let me ignore it.

Ivan Maidanski · Answer 12 · Sun Jan 28 2024 03:28:47 GMT+0800 (China Standard Time)

I got such error on cygwin:
...
libtoolize: error: '../config.guess' exists: use '--force' to overwrite

It seems I got it because I had old config.guess, I can't reproduce it any more after I did git clean -f -x -d.
I don't want to add "--force" option.

Bruno Haible · Answer 13 · Sun Jan 28 2024 04:53:08 GMT+0800 (China Standard Time)

The patch introduces a build failure libtoolize: command not found

I wonder about the situation when this occurs:

If it is while building a git checkout, which does not have m4/libtool.m4, then there is no reasonable fix, because libtoolize is necessary in order to pull in m4/libtool.m4 and ltmain.sh.
If, on the other hand, it is while building a tarball, then why is autogen.sh being invoked at all? Tarballs can be configured with ./configure right away.

Is it because the build system / CI is meant to be usable on both git checkouts and tarballs? Or why?

Bruno Haible · Answer 14 · Sun Jan 28 2024 04:56:31 GMT+0800 (China Standard Time)

I will change libtoolize invocation code to:
if which libtoolize > /dev/null 2>&1; then

The program which is not portable. The portable way to test whether a program exists is:

if (type libtoolize) > /dev/null 2>&1; then

Ivan Maidanski · Answer 15 · Sun Jan 28 2024 05:13:39 GMT+0800 (China Standard Time)

The patch introduces a build failure libtoolize: command not found

I wonder about the situation when this occurs:

Is it because the build system / CI is meant to be usable on both git checkouts and tarballs? Or why?

I don't know.
Build with libtoolize (fail): https://app.travis-ci.com/github/ivmai/libatomic_ops/jobs/616931164
Build w/o libtoolize invocation: https://app.travis-ci.com/github/ivmai/libatomic_ops/jobs/616934587
Both builds are using git checkout

Ivan Maidanski · Answer 16 · Sun Jan 28 2024 05:32:55 GMT+0800 (China Standard Time)

The program which is not portable. The portable way to test whether a program exists is:
if (type libtoolize) > /dev/null 2>&1; then

Okay. Committed as ivmai/libatomic_ops@7faabbf