Re: libtool 2.2.2 does not work on OSF/1 4.0d

[Ralf Wildenhues]

Hello Bruno,

* Bruno Haible wrote on Sun, Apr 06, 2008 at 09:26:08PM CEST:
> Ralf Wildenhues asked:
> > > And $(SHELL) always expands to /bin/sh.
> >
> > Why is that?
> 
> All my hand-written Makefiles and Makefile.ins have
>   SHELL = /bin/sh
> 
> This is recommended by lots of tutorials how to write Makefiles, e.g. 
> [1][2][3];

> [1] http://www.hsrl.rutgers.edu/ug/make_help.html
> [2] http://www.mtsu.edu/~csdept/FacilitiesAndResources/make.htm
> [3] http://www.gnu.org/software/make/manual/html_node/Choosing-the-Shell.html

Those tutorials all recommend setting SHELL at all, not specifically
setting SHELL to /bin/sh always.

> Also because without it, on some old systems (IRIX 5?) Makefile commands are
> run through the user's login shell, which may be csh or tcsh!

Yep, which is why setting SHELL is recommended.

> Also because on
> OSF/1, SHELL expands to the user's login shell if not explicitly set.

Well, *that* happens with other make implementations as well, for
example BSD make.  Note that what SHELL expands to may be different from
what make uses to spawn jobs.

> > There should be
> >   SHELL = /bin/ksh
> 
> That would be if my Makefiles were to use @address@hidden They don't, because
>   - The autoconf manual says that @SHELL@ is interesting to use if one cares
>     about DJGPP portability, which I don't.

Please, the Autoconf manual, version 2.61 or 2.62, says

|    Not all `make' implementations define this `SHELL' macro.  Tru64
| `make' is an example; this implementation always uses `/bin/sh'.  So
| it's a good idea to always define `SHELL' in your makefiles.  If you
| use Autoconf, do
| 
|      SHELL = @SHELL@
| 
|    Do not force `SHELL = /bin/sh' because that is not correct
| everywhere.  For instance DJGPP lacks `/bin/sh', [...]

There is no statement that this is superfluous but for DJGPP; it's
merely used as an example.  If you think "a good idea to always" is not
worded strongly enough, we can easily change that.

>   - I want to have control over the shell which executes the body of my
>     Makefiles. It's hard enough to handle /bin/sh bugs; I don't also want
>     to have to handle pdksh, zsh, ash, etc. with all their bugs in all my
>     Makefiles.

OK, now we get to the real issue you have with `SHELL = @SHELL@', and
one where I can finally understand the motivation.  However, if you
target portability to a variety of systems, there's no way
  SHELL = /bin/sh

gets you around those other shells: zsh was the only shell on some older
Darwin systems, a slightly modified pdksh is used by some BSD variants,
ash is one of the possible shells Debian users link to /bin/sh.

If configure finds that the shell it's started as is lacking feature,
then it tries to find a better, more posixy, shell, and set $SHELL
accordingly.  If there is anything wrong with the choice algorithm[1],
then maybe it's time to fix the algorithm before we give up and fix the
symptoms only, no?  We can still do the latter when the former turns out
to not be viable; but generally, I would hope you will have *fewer*, not
*more*, issues with using $(SHELL) over /bin/sh.

So, is there any particular issue you have with _AS_DETECT_BETTER_SHELL
or _LT_PROG_ECHO_BACKSLASH?  I would like to have this addressed before
considering modifying the setting of $(LIBTOOL).

Cheers,
Ralf

[1] There was a report a few weeks ago about zsh being selected when it
should not have been.  This should be fixed.