Description of Problem:
When CDPATH is set in the users environment cd returns the new
path to stdout. As a result, the line in Makefile (generated from
automake) that contains:
top_distdir=`cd $(distdir) && pwd`; \
produces a problem because the value contains pwd twice, on two lines.
User's CDPATH is set by default on rawhide, but not on 7.2. I couldn't find
where this is being set.
Version-Release number of selected component (if applicable):
100% on rawhide
Steps to Reproduce:
1. unpack attached demo package on a rawhide system
2. cd autogenbug-0.1
ellson@amber:automakebug-0.1> env | grep CDPATH
ellson@amber:automakebug-0.1> make dist
rm -rf automakebug-0.1
chmod 777 automakebug-0.1
here=`cd . && pwd`; \
top_distdir=`cd automakebug-0.1 && pwd`; \
distdir=`cd automakebug-0.1 && pwd`; \
cd . \
&& automake --include-deps --build-dir=$here --srcdir-name=.
--output-dir=$top_distdir --gnu Makefile
`/home/ellson/build/automakebug-0.1/automakebug-0.1.am' does not exist
make: *** [distdir] Error 1
Created attachment 48924 [details]
trvial package illustrating problem with "make dist" target
CDPATH is being set in: /etc/profile.d/bashopts.sh
This is new in Rawhide.
This bug can be reproduced with automake-1.4p5-2 on 7.2 by
Hmm, reproduced, but I claim that "." should not be included in CDPATH.
Bero, can't it be taken out?
I agree that the Rawhide default CDPATH looks strange, but changing it
isn't a fix for this problem. CDPATH can be set by the user, so automake
needs to be made tolerant of any CDPATH setting. Perhaps automake should
simply unset it for the duration of the script?
I think the problem with automake only really occurs if "." is in CDPATH.
When it isn't, CDPATH being set doesn't cause any trouble for automake, right?
Also newer releases of automake (1.5 and 1.6) doesn't seem to be affected CDPATH.
The user can set, and is intended to set, CDPATH to anything they want.
This bug is with automake 1.4 which needs to tolerate arbitrary CDPATH settings.
automake 1.5/1.6 are irrelevant since they don't work many existing packages
(e.g. added depcomps file)
After further testing I realised that bash handles CDPATH differently from zsh.
Bash actually needs a "." at the beginning of CDPATH for it to give
expected behaviour wrt to cd'ing to a subdir, whereas zsh always
tries cwd before searching cdpath. (I guess one can argue about
which is the right behaviour, though currently zsh's CDPATH behaviour
seems to give less surprise to me.)
Further this problem seems to be well-known and also probably affects
at least older autoconf and libtool scripts
FYI: Automake 1.6 should correctly ignore the user's CDPATH setting.
In fact I believe this constraint is automatically checked by
the "maintainer-check" target, to ensure we don't accidentally introduce
regressions in this area.
Unfortunately this wasn't fixed in the 1.4 series, and we don't plan to
make any additional 1.4 releases.
Confirmed that this is fixed with automake-1.6.2.