On Wed, Jan 16, 2008 at 07:18:08PM +0100, Ralf Wildenhues wrote: > [ 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}
In my failing test case, I have /bin/sh in both these places, not /bin/bash. > 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). What does your /bin/sh symlink point to? -- Colin Watson [EMAIL PROTECTED] _______________________________________________ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
