CONFIG_SHELL and `./config.status --recheck'

[Ralf Wildenhues]

The Libtool issue described here may need cooperation from Autoconf.

In libtool.m4's _LT_PROG_ECHO_BACKSLASH, we search for a good
combination of an `echo' program (that does not interpret backslashes)
and a $SHELL that also qualifies for _AS_DETECT_BETTER_SHELL.

This detection has one, or rather two, long-known bugs, but I am not
sure about the proper fix:

Description of the bug:
If `./config.status --recheck' is triggered, for example by automatic
rebuilding rules, config.status executes
  $SHELL configure [OPTIONS] --no-create --no-recursion

This means, `configure' may be executed by something other than /bin/sh.
Thus, our macro, which tests plain `echo' first, may find that it is
decent to use, and thus, may find that /bin/sh is a good-enough shell
for all our purposes.

This frequently happens on Solaris:  The first configure run selects
  SHELL=/path/to/bash
and the second likes plain `echo', because it tests the bash builtin,
and /bin/sh, because CONFIG_SHELL is not set and thus we believe we are
run by /bin/sh.  `make' eventually executes `libtool' which barfs then.

With the first `configure' that is executed by the user, Autoconf
recommends

  bash ./configure CONFIG_SHELL=bash

but this does not help our code: the command line gets parsed only until
after we do the testing (this is the second issue, technically).
$CONFIG_SHELL thus isn't set then.  OTOH,
  CONFIG_SHELL=bash bash ./configure
would work, but doesn't fit the option passing policy.

How should we fix this?

One possibility would be to restart once with /bin/sh, or, if part of
the environment, with CONFIG_SHELL, or, after parsing the command line,
with CONFIG_SHELL, if that is given there.  All of this is very slow
(read: dog-slow), and I'd really like to avoid another restart if at all
possible.

Another possibility would be to test for an external echo program first,
this has a measureable speed impact on libtool execution time, though.

Thanks,
Ralf