[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: portability bug (shell syntax)
From: |
Ralf Wildenhues |
Subject: |
Re: portability bug (shell syntax) |
Date: |
Fri, 6 Aug 2010 19:33:04 +0200 |
User-agent: |
Mutt/1.5.20 (2010-04-22) |
Hi Peter,
* Peter Selinger wrote on Fri, Aug 06, 2010 at 04:16:10PM CEST:
> I have to eat my words. I went to bed last night, got up, decided to
> investigate some more, and I cannot now reproduce the problem.
Don't worry.
> ./configure executes itself using /bin/bash, sets SHELL to /bin/bash,
> the XSI test succeeds, ./libtool is built with first line "#!
> /bin/bash", and the make succeeds.
As it should be: configure searches for a decent shell, re-executes with
it, and uses that shell for testing and for other scripts like libtool.
> The only way I can still reproduce last night's behavior is by
> invoking configure as "/bin/bash ./configure".
Yep; the INSTALL file documents that this isn't supported, however:
[...]
| ./configure CC=/usr/local2/bin/gcc
|
| causes the specified `gcc' to be used as the C compiler (unless it is
| overridden in the site shell script).
|
| Unfortunately, this technique does not work for `CONFIG_SHELL' due to
| an Autoconf bug. Until the bug is fixed you can use this workaround:
|
| CONFIG_SHELL=/bin/bash /bin/bash ./configure CONFIG_SHELL=/bin/bash
[...]
also see 'info Autoconf --index CONFIG_SHELL' for more details.
Another reason to run into these kinds of issues can be when the
configure.ac code changes $SHELL or $CONFIG_SHELL; this is best avoided.
Cheers,
Ralf