Date: Sun, 9 Mar 2008 19:40:50 -0400 From: Mike Meyer <mwm-keyword-freebsdhackers2.e313df@mired.org> To: freebsd-hackers@freebsd.org Subject: Re: Why doesn't autoconf like our /bin/sh? Message-ID: <20080309194050.39bab925@bhuda.mired.org> In-Reply-To: <47D46127.2030802@chuckr.org> References: <20080309152712.42752293@bhuda.mired.org> <47D46127.2030802@chuckr.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 09 Mar 2008 18:13:59 -0400 Chuck Robey <chuckr@chuckr.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Mike Meyer wrote:
> > I've stumbled on to an obscure problem with autoconf 2.61, and I'm not
> > sure quite what to do with it. I've already sent mail to the autoconf
> > folks, but I'd like to understand what's going on.
> >
> > The problem is that, on a FreeBSD system with only /bin/sh and the
> > ports zsh as installed shells, if you have SHELL set to zsh when
> > invoking the autoconf-generated configure script, the script produces
> > a broken Makefile. It doesn't generate an error, it just complains
> > that:
> >
> > as_func_failure succeeded.
> > as_func_failure succeeded.
> > No shell found that supports shell functions.
> > Please tell autoconf@gnu.org about your system,
> > including any error possibly output before this
> > message
> > then runs to completion, with no other indication of an error, and
> > non in the config.log file either. This has happened on multiple
> > different FreeBSD systems (including both 6-STABLE and 7-RELEASE), on
> > multiple autoconf scripts (possibly from multiple versions of
> > autoconf).
> >
> > Installing bash (or presumably any of the other shells that the
> > configure script looks for) changes this, and it works fine. Setting
> > SHELL to /bin/sh, or unsetting it, also solves this.
> >
> > And of course, if you build from ports, SHELL gets set to /bin/sh, so
> > there isn't a problem at all (which probably has a lot to do with why
> > I never noticed it before - the ports systems pretty much covers most
> > of my needs).
> >
> > From poking at things it seems that autoconf isn't happy with /bin/sh
> > for some reason, even though it works. With SHELL set to zsh, it then
> > tries that - and again isn't happy. However, it's not so unhappy that
> > it fails completely, so it tries to run with whatever shell it tried
> > last.
> >
> > My question is, why doesn't the configure script just accept /bin/sh?
> > After all, it's going to work. Is there an autoconf person who knows
> > this one?
> >
>
> The top of the configure script I just inspected (the one from
> print/libxslt) called out, on the top line:
>
> #!/bin/sh
>
> and so, as long as you do have a real shell there (which you have to have)
> should really work, BUT I know, from past experience, that many, many
> Linuxers, when told that their script doesn't work with any shell but Bash,
> will just tell you "but why don't you run Bash?" as if no one should ever
> run any other shell. I went to far, back when I ran Gentoo, to try to fix
> some broken scripts wrt non-bash usage, but no one really cared to fix that
> kind of thing. It's not going to be a proboem with configure, but it's
> possible that soome script called by configure is setting it's own shell.
> Configure probably needs, way up at the top, something like "export
> SHELL=/bin/sh" but don't hold your breath, and if Linuxers gave it a try,
> they'd probably want to peg it to bash, and that'd cause worse problems,
> because Linux and FreeBSD store bash in a different places.
I don't really think this is a bash vs. sh issue, as the point of the
code that's failing is all about trying to figure out which of the
available shell-like things will do the job it needs to do. If the
autoconf folks were going to say "just use bash", they'd skip all this
magic, and just make the script a bash script (which would mean that
bash couldn't use autoconf).
Worse yet, said job verges on the impossible, so I can understand why
the code is a bit fuzzy about what "acceptable" is. Shells apparently
wind up in three classes:
1) Not usable - none of the shells discussed are put here.
2) Maybe usable - both sh and zsh are put here.
3) Definitely usable - bash gets put here.
If a definitely usable shell is found, the search stops, and configure
just uses it. If none of the shells are maybe usable, then configure
stops and complains. Otherwise, we try the last shell that was "maybe
usable", and $SHELL is always the last one tried.
So there are at *least* three things that could be considered broken,
in that changing them would fix the problem I encountered.
1) Our /bin/sh isn't classified as Definitely usable.
2) zsh is Not usable.
3) zsh is classified as Maybe usable.
#1 could be fixed on our side, if we understood why it wasn't
usable. It could also be fixed by the autoconf folks. #2 has to be
fixed by the zsh folks. #3 has to be fixed by the autoconf folks.
> But if you're considering some holy war to try to convince Linux folks to
> correct this, DING DING, let me off at the next stop, please.
No, I'm not considering a holy war about this - I'm just curious as to
what's going on. After that, we can call the jihad :-).
<mike
--
Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080309194050.39bab925>