[ 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
_______________________________________________
Bug-libtool mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-libtool
