1 Aug 2002 16:20
Re: Problem with symlinks and VPATH Builds
Paul Eggert <eggert <at> twinsun.com>
2002-08-01 14:20:33 GMT
2002-08-01 14:20:33 GMT
> From: "Mark D. Roth" <roth <at> feep.net> > Date: Thu, 25 Jul 2002 08:25:39 -0500 > > The -P option isn't listed in the ksh docs under Solaris or AIX. > Only OpenBSD seems to document this. It's also documented in Bash 2.05b. This feature was recently added to Bash (presumably in response to POSIX 1003.1-2001 requiring it), so newer versions of Bash will also have the problem. I was using an older Bash when I couldn't reproduce your original bug report. > > So it appears to me that the "proper" fix is to try "cd -P DIR" first, > > and to fall back on plain "cd DIR" if that doesn't work. > > Sounds good. Please see the attached patch. On second thought, I don't think this is wise. There is at least one other instance of "cd $foo && pwd" in Autoconf and the Autoconf manual talks about this idiom so that we can expect to see it in user code too. Even if we work around these two instances of the problem, other instances will remain. The underlying problem here is that $ac_top_srcdir is bogus, because "cd $ac_top_srcdir" and "ls $ac_top_srcdir" refer to different directories in POSIX 1003.1-2001 shells. How about if we merely detect this problem and ask the invoker of "configure" to fix it? We should also document the problem, of course. Here is a proposed patch along these lines. The doc fix also clears up some of the CDPATH confusion, and mentions the PWD problem.(Continue reading)
. An example is
% ./testsuite -v -d 3
## ----------------------------- ##
## GNU Autoconf 2.53 test suite. ##
## ----------------------------- ##
3. tools.at:122: testing autoconf --trace: user macros...
tools.at:167: autoconf -t TRACE1 -t TRACE2
tools.at:190: autoconf -t TRACE1:'
[$1], [$2], [$3].'
--- /dev/null Fri Aug 16 21:25:12 2002
+++ /vol/gcc/obj/autoconf-2.53-bug/tests/testsuite.dir/at-stderr Fri Aug 16 21:25:13 2002
<at> <at> -0,0 +1,2 <at> <at>
+autom4te: cannot do autom4te.cache/requests: No such file or directory
+ at /vol/gcc/obj/autoconf-2.53-bug/bin/autom4te line 1111
This happens although a system call trace with par clearly shows that
autom4te.cache/requests has been opened and read successfully.
I could finally trace this down to a bug in autom4te: Request::load tested
$! to determine if "do" couldn't open $file. As in C (testing errno
without a previous syscall failure return gives you the error code from the
last failed system call) this is wrong: as explained in perlfunc(1), the
correct idiom to test for "do" read failures is to test whether the "do"
return value is defined:
If "do" cannot read the file, it returns undef and
sets $! to the error.
In the unlikely case that someone still actually uses such a beast,
they'll almost certainly have HP's Fortran as well (called "f77"), and
since f77 preceded fc in the list we can safely omit the fc.
RSS Feed