[ 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 Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool