Re: libtool shell feature checks run with wrong shell

[Ralf Wildenhues]

[ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=447022 aka.
  http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/5879/focus=342902 ]

Hello, and sorry for the long delay.

* Clint Adams wrote on Sat, Dec 15, 2007 at 02:39:36AM CET:
> On Fri, Dec 14, 2007 at 01:59:34AM +0000, Colin Watson wrote:
> > libtool used it. The _LT_CHECK_SHELL_FEATURES macro checks a number of
> > shell features and determines accurately that the currently-running
> > shell supports +=. Unfortunately, the currently-running shell is bash at
> > this point, not dash. The reason for this is that configure has
> > different logic for re-execing itself under a different shell from that
> > used by libtool. libtool seems to try to account for this using:
> > 
> >   : ${SHELL="${CONFIG_SHELL-/bin/sh}"}

Actually, the generated libtool script should just have
  #! /bin/bash

as its first line, and not re-exececute itself at all.

OK, let's go step by step here: at the end of the trace posted in this
bug report, CONFIG_SHELL is exported and contains /bin/bash, and
likewise for SHELL.  That means config.status should contain as its
first line
  #! /bin/bash

and a dozen lines further down
  SHELL=${CONFIG_SHELL-/bin/bash}

and so, when ./config.status is executed (and eventually gets around to
creating the libtool script), the code
|     cat <<_LT_EOF >> "$cfgfile"
| #! $SHELL

should just put "#! /bin/bash" into it.

And in fact that is just what I get on my Debian etch when I try to
reproduce your setup as closely as possibl (tested with Libtool CVS
HEAD).

So I'm wondering where in the chain is the error?

> > ... but at this point CONFIG_SHELL is not set, and so libtool ends up
> > running under a different shell than the one that configure
> > feature-tested.
[...]
> I suppose the easiest workaround is to explicitly set CONFIG_SHELL

Thanks,
Ralf