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

[Ralf Wildenhues]

[ autoconf-patches readers: this is
  <http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/6155/focus=6166> ]

Hello Bruno,

* Bruno Haible wrote on Wed, Apr 09, 2008 at 12:14:37PM CEST:
> Thank you for your detailed answer.

and thanks to you for a thoughtful reply.

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

Hmm, we'd need to check whether configure really tries to locate a
better shell on all of these system.  Eric suggested a patch here:
<http://thread.gmane.org/gmane.comp.sysutils.autoconf.patches/5511>

> > [...] 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

The hope is that they will be smaller.

> For example, will autoconf also choose bash if it is one
> of the more broken bash versions?

Good question.  The answer is probably yes; the morale is that we should
identify which versions are broken and which features we should avoid:
then we can modify the search for a better shell to avoid these issues,
or, since bash is easily identified by its version, these versions.

One way to achieve this in an extensible manner would be for Autoconf to
provide documented interfaces to the macros _AS_DETECT_REQUIRED and
_AS_DETECT_SUGGESTED.  That way, for example, Libtool could use

  AS_DETECT_SUGGESTED(
    [[# prefer a shell that has a builtin that prints long strings without
      # escape expansion (such as working 'printf %s\n', or BSD echo).
      ...
    ]])

and gettext and other package could add requirements or preferences as
needed.

I'm not sure though whether that will provide more problems in the long
run, due to different packages choosing different shells, and instead
listing all requirements in Autoconf explicitly isn't better.  I simply
don't know.

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

Yep.

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

Good point:  Either your proposed patch for Libtool should be applied,
or Libtool's NEWS file should contain a note to the end that the value
of $(SHELL) is important in the Makefile now.

Thanks,
Ralf