Re: Bug#447022: libtool shell feature checks run with wrong shell

2008-01-30 Thread Clint Adams
On Wed, Jan 30, 2008 at 08:48:10PM +0100, Kurt Roeckx wrote:
> Please note that 2.1a+cvs1.2525+20071016-1 is the latest version in
> experimental.

Thanks.  fakeroot 1.9.2 is generated with libtool
2.1a+cvs1.2525+20071016-1 and appears to suffer from the same problem.


___
Bug-libtool mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: Bug#447022: libtool shell feature checks run with wrong shell

2008-01-30 Thread Kurt Roeckx
On Wed, Jan 30, 2008 at 02:19:22PM -0500, Clint Adams wrote:
> On Wed, Jan 16, 2008 at 08:59:46PM +0100, Ralf Wildenhues wrote:
> > Let's find out what the differences in the setups are.  Which version
> > of dash?  Which m4 and autoconf versions were used to bootstrap the
> > package in question?  BTW, which package is this that this happened
> > with, libtool or some libtool-using one?
> > 
> > I tried with dash 0.5.3-7, Libtool CVS HEAD, M4 1.4.10a (CVS
> > branch-1_4).  I can try some Debian packages next, but which should I
> > use?
> 
> Sorry, I seem to have missed this message.  The package in question is
> fakeroot 1.9.1.
> 
> autoconf 2.61-5
> automake 1:1.10+nogfdl-1
> dash 0.5.4-6
> libtool 2.1a+cvs1.2460+20070510-1
> m4 1.4.10-1

Please note that 2.1a+cvs1.2525+20071016-1 is the latest version in
experimental.


Kurt



___
Bug-libtool mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-libtool


Re: Bug#447022: libtool shell feature checks run with wrong shell

2008-01-16 Thread Ralf Wildenhues
* Colin Watson wrote on Wed, Jan 16, 2008 at 07:44:30PM CET:
> On Wed, Jan 16, 2008 at 07:18:08PM +0100, Ralf Wildenhues wrote:
> > 
> > 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.

Hmm.  Can you rerun the test, with the 'set +x' removed that I asked you
to add?  Probably a good idea to gzip the output to not exceed
bug-libtool list size limits.

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

Normally to bash.  For doing the test, however, I did this:
Let /bin/sh point to dash.  Start zsh, export SHELL=/bin/zsh, unset
CONFIG_SHELL, run ../libtool/configure.

My trace output looks very much like yours, AFAICS.

Cheers,
Ralf


___
Bug-libtool mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-libtool