Paul Eggert wrote:
Anyway, if you can strace it (or whatever the equivalent of that is,
on AIX), that will likely let us come up with a fix.
Well damn, after the reboot the problem seems to have disappeared,
configure runs cleanly start to finish. (A colleague of mine requested
the reboot,
Ralf Wildenhues [EMAIL PROTECTED] writes:
Likewise, I have been unable to reproduce any issues _without_ `sh -vx'.
I didn't quite follow everything in that thread, but as I understand
it the problem occurs only when one is using sh -vx configure on AIX.
Ralf Wildenhues [EMAIL PROTECTED]
Paul Eggert wrote:
Ralf Wildenhues [EMAIL PROTECTED] writes:
Likewise, I have been unable to reproduce any issues _without_ `sh -vx'.
I didn't quite follow everything in that thread, but as I understand
it the problem occurs only when one is using sh -vx configure on AIX.
The reason I was
Howard Chu [EMAIL PROTECTED] writes:
I was thinking that, or ((set -o posix) /dev/null 2*1); ... Will
give it a shot.
Another possibility, which I just thought of, is to redirect stdin as
well:
(set -o posix) /dev/null /dev/null 21
Another possibility is to try set +o posix instead of set -o
[ Cc:ing autoconf-patches; this is
http://thread.gmane.org/gmane.comp.gnu.libtool.general/7105 ]
Hi Howard,
Again several bugs for the price of one bug report.
* Howard Chu wrote on Fri, Jan 13, 2006 at 10:30:07AM CET:
login shell and $SHELL are /bin/sh. The significant failure follows.
Ralf Wildenhues wrote:
because, for example, OpenBSD uses a modified pdksh as /bin/sh, and one
of the modifications consists of not setting KSH_VERSION any more. :-/
I am at a loss as how to detect this cleanly, suggestions welcome.
if test X${RANDOM} != X${RANDOM} -a X${BASH_VERSION+set} =
