Re: libtool shell feature checks run with wrong shell
On Tue, Feb 05, 2008 at 11:52:28PM +0100, Ralf Wildenhues wrote: > That should've been _AS_DETECT_REQUIRED instead of _AS_DETECT_SUGGESTED, > sorry. Thank you. ___ Bug-libtool mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: libtool shell feature checks run with wrong shell
That should've been _AS_DETECT_REQUIRED instead of _AS_DETECT_SUGGESTED, sorry. 2008-02-05 Ralf Wildenhues <[EMAIL PROTECTED]> * configure.ac: Do not override $SHELL late in configure.ac. Use undocumented Autoconf interface _AS_DETECT_REQUIRED to require $(...) command replacement. --- configure.ac.orig 2008-02-05 23:30:12.0 +0100 +++ configure.ac2008-02-05 23:49:50.0 +0100 @@ -482,21 +482,9 @@ dnl kludge end dnl check for b0rked Solaris (and other shells) and find one that works -AC_MSG_CHECKING(for a working shell...) -for i in /usr/xpg6/bin/sh /usr/xpg4/bin/sh /usr/ccs/bin/sh /bin/sh /usr/bin/sh /bin/ksh /bin/bash /usr/local/bin/bash ; do -$i -c 'if ! false ; then echo $(echo ok) ; fi' >config.$$ 2>/dev/null -j=`cat config.$$` -rm -f config.$$ -if test "x$j" = "xok" ; then -SHELL=$i -AC_SUBST(SHELL) -break -fi -done -AC_MSG_RESULT($SHELL) -if test "x$SHELL" = "x" ; then -AC_MSG_ERROR(no SUS compliant shell found - on Solaris, install SUNWxcu4) -fi +_AS_DETECT_REQUIRED([echo $(echo ok) > config.$$ 2>/dev/null + j=`cat config.$$` + test "x$j" = "xok"]) case "$target_cpu:$target_os" in (alpha*:linux*) ___ Bug-libtool mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: libtool shell feature checks run with wrong shell
* Clint Adams wrote on Wed, Jan 30, 2008 at 08:19:22PM CET: > 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? [...] > 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 Confirmed. Thanks for the information. This is a bug in fakeroot rather than in libtool. Well, probably it's under-documentation in Autoconf. Point is, both the current Libtool and Autoconf code assume that the configure.ac author does not mess with $SHELL, and certainly should not mess with it late in the script. Unfortunately, however, Autoconf also does not provide a public interface to give additional requirements on the shell. The patch below uses an undocumented interface, but this may easily break with a different Autoconf version than the one I tried it with. Actually, I think the safer approach would be to just delete the test completely, and let the user sort it out on Solaris manually by CONFIG_SHELL=/bin/bash; export CONFIG_SHELL $CONFIG_SHELL ./configure ... Hope that helps. Cheers, Ralf 2008-02-05 Ralf Wildenhues <[EMAIL PROTECTED]> * configure.ac: Do not override $SHELL late in configure.ac. Use undocumented Autoconf interface _AS_DETECT_SUGGESTED to require $(...) command replacement. --- configure.ac.orig 2008-02-05 23:30:12.0 +0100 +++ configure.ac2008-02-05 23:39:34.0 +0100 @@ -482,21 +482,9 @@ dnl kludge end dnl check for b0rked Solaris (and other shells) and find one that works -AC_MSG_CHECKING(for a working shell...) -for i in /usr/xpg6/bin/sh /usr/xpg4/bin/sh /usr/ccs/bin/sh /bin/sh /usr/bin/sh /bin/ksh /bin/bash /usr/local/bin/bash ; do -$i -c 'if ! false ; then echo $(echo ok) ; fi' >config.$$ 2>/dev/null -j=`cat config.$$` -rm -f config.$$ -if test "x$j" = "xok" ; then -SHELL=$i -AC_SUBST(SHELL) -break -fi -done -AC_MSG_RESULT($SHELL) -if test "x$SHELL" = "x" ; then -AC_MSG_ERROR(no SUS compliant shell found - on Solaris, install SUNWxcu4) -fi +_AS_DETECT_SUGGESTED([echo $(echo ok) > config.$$ 2>/dev/null + j=`cat config.$$`; rm -f config.$$ + test "x$j" = "xok"]) case "$target_cpu:$target_os" in (alpha*:linux*) ___ Bug-libtool mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: libtool shell feature checks run with wrong shell
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 ___ Bug-libtool mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: libtool shell feature checks run with wrong shell
* Ralf Wildenhues wrote on Wed, Jan 16, 2008 at 08:59:46PM CET: > * Clint Adams wrote on Wed, Jan 16, 2008 at 08:43:22PM CET: > > On Wed, Jan 16, 2008 at 06:44:30PM +, Colin Watson wrote: > > > In my failing test case, I have /bin/sh in both these places, not > > > /bin/bash. > > > > Same here. > > 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? Ping? Cheers, Ralf ___ Bug-libtool mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: libtool shell feature checks run with wrong shell
* Clint Adams wrote on Wed, Jan 16, 2008 at 08:43:22PM CET: > On Wed, Jan 16, 2008 at 06:44:30PM +, Colin Watson wrote: > > In my failing test case, I have /bin/sh in both these places, not > > /bin/bash. > > Same here. 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? > I will note that a ./config.status --recheck seems to "fix" things. Yes, that's what I would expect. Thanks, Ralf ___ Bug-libtool mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: libtool shell feature checks run with wrong shell
On Wed, Jan 16, 2008 at 06:44:30PM +, Colin Watson wrote: > In my failing test case, I have /bin/sh in both these places, not > /bin/bash. Same here. I will note that a ./config.status --recheck seems to "fix" things. ___ Bug-libtool mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: libtool shell feature checks run with wrong shell
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 +, 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
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: libtool shell feature checks run with wrong shell
[ 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 +, 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
Re: libtool shell feature checks run with wrong shell
On Fri, Dec 14, 2007 at 01:59:34AM +, 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}"}
>
> ... 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've had this mail postponed for several days in the hope of finding
> time to dig into this further, but I haven't found such time and I think
> it's better to send an incomplete report than none at all. Please let me
> know if there's anything you'd like me to investigate further.
It looks as though I filed
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=447022
and then completely forgot about it.
I suppose the easiest workaround is to explicitly set CONFIG_SHELL
since I don't particularly want to regress to libtool 1.5.
___
Bug-libtool mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-libtool
