autogen.sh: check for libtool before automake fails to find it #7530

Changes the error message from: $ ./autogen.sh configure.ac:28: installing 'build-aux/install-sh' configure.ac:28: installing 'build-aux/missing' Makefile.am:8: error: Libtool library used but 'LIBTOOL' is undefined Makefile.am:8: The usual way to define 'LIBTOOL' is to add 'LT_INIT' Makefile.am:8: to 'configure.ac' and run 'aclocal' and 'autoconf' again. Makefile.am:8: If 'LT_INIT' is in 'configure.ac', make sure Makefile.am:8: its definition is in aclocal's search path.

To: $ ./autogen.sh libtool is required, please install it first

All builds failed with:

libtool is required, please install it first

Empty LIBTOOLIZE is valid use case! Even -x doesn't help here.

The test should be rewritten IMO. But it looks to me that some part in the master is missing, something like:

[ -z ${LIBTOOLIZE} ] && LIBTOOLIZE="`which libtoolize 2>/dev/null`"

Then your code makes sense (after -z -> -x).

Empty LIBTOOLIZE is valid use case!

So $LIBTOOLIZE is actually not used in some build? What use case is that?

Right now, you can export LIBTOOLIZE="" and finish the build. With your change, you can't. Looks weird, yes. But it is this way right now.

The variable LIBTOOLIZE is used by autoconf. It can be empty. E.g. try setting it to NONSENSE and run autoreconf:

Can't exec "NONSENSE": No such file or directory at /opt/local/share/autoconf/Autom4te/FileUtils.pm line 345, <GEN7> line 5.
autoreconf: failed to run NONSENSE: No such file or directory
autoreconf: libtoolize is needed because this package uses Libtool

The current code expects the user can have LIBTOOLIZE already set in the environment. If it is empty or not set, it checks for glibtoolize. But it CAN end up with empty LIBTOOLIZE which is valid case.

I'd suggest to add the line I mentioned above and use -x. This should solve all cases.

@paveljanik ok thanks for the insight. I've force-pushed new approach following your advice, which works in my box (ubuntu 15.10 fyi) and passes in travis too.

@knocte Can you please rebase?

@paveljanik sure, done

I think this might be fixed more nicely with an m4_ifdef in configure.ac ?

Edit: I think nevermind that.

What about this? LIBTOOLIZE="which glibtoolize 2>/dev/null" || LIBTOOLIZE="which libtoolize 2>/dev/null" @paveljanik Yeah I like your improvements, but I guess you didn't test it :-P I tried to beautify it myself too, but there's a set -e directive at the start of the file that would make the execution abort if any of the which calls fails. But with the current approach in the pull request now it works.

Edit: I think nevermind that. @theuni why nevermind? I could explore that. But maybe in a subsequent commit/PR?

@theuni why nevermind? I could explore that. But maybe in a subsequent commit/PR?

Probably a chicken-and-egg problem :-)

@knocte Yes, I do not usually test shell scripts (only in own PRs ;-). What about this? You can just add || : at the end of the checks or use:

# Find executable (g)libtoolize or warn user early
if [ -z ${LIBTOOLIZE} ]; then
  LIBTOOLIZE="`which glibtoolize 2>/dev/null`" || LIBTOOLIZE="`which libtoolize 2>/dev/null`" || \
  [ ! -x "$LIBTOOLIZE" ] && (
       echo "(g)libtoolize not found, please install libtool";  exit 1
    )
fi

So did anyone test this or check this out further?

I didn't. @knocte?

Can one of the admins verify this patch?

Closing due to lack of activity