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

[Bruno Haible]

Hello Ralf,

Thank you for your detailed answer.

> Please, the Autoconf manual, version 2.61 or 2.62, says
> 
> |    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.

Yes I think the wording is not enough, because DJGPP is not a mainstream
porting target any more. I would reword it like this:

  Do not force `SHELL = /bin/sh' because that is not correct everywhere.  
  /bin/sh is not POSIX compliant on many systems: FreeBSD 4, NetBSD 3, AIX 3,
  Solaris 10, Tru64. On these systems, Autoconf tries to locate a `bash' or
  `ksh' program and sets SHELL to it, if found.  Additionally, DJGPP lacks
  `/bin/sh' ...

> >   - I want to have control over the shell which executes the body of 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.

Weird... but that explains why I had so many portability problems in
gettext's Makefiles in the past.

Will the set of portability problems be smaller or larger if I used autoconf's
value of @address@hidden For example, will autoconf also choose bash if it is 
one
of the more broken bash versions?

> 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?
> [1] There was a report a few weeks ago about zsh being selected when it
> should not have been.  This should be fixed.

You are honest here. The point you mention is exactly why I want to have
control over the shell that most of my Makefiles use. Otherwise I get to
depend on the choice algorithm, and potentially have to face
  1. bugs in the choice algorithm,
  2. bugs in bash or ksh versions that people have installed in their PATH
     but which no sane vendor would dare to distribute in large scale.

> 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).

I think my own choice is irrelevant here. There are many Makefile.in out
there which use "SHELL = /bin/sh", simply because this is the traditional
way, and because when autoconf introduced @SHELL@ it was not mentioned in
its NEWS file. And in this situation, we *know* that libtool breaks because
it uses the ${var%pattern} syntax.

Bruno