Bug#177076: gcc-3.2: building the pkg from a shell with non-null $CDPATH fails

[Matthew Swift <swift@alum.mit.edu>]

Package: gcc-3.2
Version: 1:3.2.1-0pre3
Severity: normal

Now that I think about it, I see no good reason to export $CDPATH from a shell,
as I was doing.  But if for whatever reason one does export a non-null value of
$CDPATH while building gcc-3.2, say, with "debuild", the build is going to
fail.  The gcc-3.2 makefiles could be more robust, to prevent this failure,
which will occur in such situations whenever $CDPATH is exported and non-null.

To explain, let me first review how Bash handles the "cd" command.

Fact 1: Quoting from bash-2.05b/builtins/cd.def:

	      /* POSIX.2 says that if a nonempty directory from CDPATH
		 is used to find the directory to change to, the new
		 directory name is echoed to stdout, whether or not
		 the shell is interactive. */

Fact 2: Bash considers strings starting with "./" and "../" to be
absolute.  (There is no mention in the source (general.c) whether this is a
POSIX spec.)

Consequently, the following:

Suppose it is possible to cd to a subdirectory "MySubdir" of the
current directory.
When bash is in POSIX mode and either interactive or not,

        cd ./MySubdir

never echoes the new directory, and

        cd MySubdir

always echoes it, when the command is successful.  The command is successful
when $CDPATH is null or unset, or is set and contains ".".


Now consider the following rule from gcc-3.2-3.2.2ds4/build/gcc/Makefile:


    pascal.real-install-doc: pascal.install-dir $(srcdir)/p/README \
     $(srcdir)/p/NEWS $(srcdir)/p/FAQ $(srcdir)/p/AUTHORS \
     $(srcdir)/p/COPYING $(srcdir)/p/COPYING.LIB $(srcdir)/p/COPYING.FDL $(srcdir)/p/test/README pascal.docdemos
            for f in README NEWS INSTALL FAQ AUTHORS COPYING COPYING.LIB COPYING.FDL; do \
              rm -f "$(p_inst_docdir)/$$f"; \
              $(INSTALL_DATA) "$(srcdir)/p/$$f" "$(p_inst_docdir)/$$f" || exit 1; \
              chmod a-x "$(p_inst_docdir)/$$f"; \
            done
            rm -f "$(p_inst_docdir)/BUGS"
            $(INSTALL_DATA) "$(srcdir)/p/test/README" "$(p_inst_docdir)/BUGS"
            for f in `cd "$(srcdir)/p/demos" && echo *`; do \
              if [ "$$f" != CVS ]; then \
                rm -f "$(p_inst_demodir)/$$f"; \
                $(INSTALL_DATA) "$(srcdir)/p/demos/$$f" "$(p_inst_demodir)/$$f" || exit 1; \
              fi \
            done
            chmod a-x "$(p_inst_docdir)/BUGS" "$(p_inst_demodir)"/*
            if [ "`cd p/docdemos && echo a*`" != "a*" ]; then \
              (cd "$(p_inst_docdemodir)"; for f in *; do rm -f "$$f"; done) && \
              for f in `cd p/docdemos && echo *`; do \
                rm -f "$(p_inst_docdemodir)/$$f"; \
                $(INSTALL_DATA) "p/docdemos/$$f" "$(p_inst_docdemodir)/$$f" && \
                chmod a-x "$(p_inst_docdemodir)/$$f" || exit 1; \
              done; \
            fi



In particular, observe the construction

    for f in `cd p/docdemos && echo *`; do

which is used twice in this rule ($(srcdir) happens to be absolute) -- and
probably elsewhere.

The makefile will behave in one of three ways:

    1) If $CDPATH is set and contains "." then the absolute pathname of the
       subdirectory itself will be the first value of $f in the loop, and
       the "install" command will fail.

    2) If $CDPATH is set but does not contain ".", the subdirectory will not be
       found by the "cd" command.

    3) If $CDPATH is null or unset, the Makefile will succeed as intended.


Conclusion:

The makefile would be more robust if it replaced constructions like

    for f in `cd p/docdemos && echo *`; do

with

    for f in `cd ./p/docdemos && echo *`; do

that is, add a "./" before "p/docdemos".

Moral:

Export as few envariables as you can get away with!



-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux beth 2.4.20 #1 Wed Jan 15 16:59:59 EST 2003 i686
Locale: LANG=C, LC_CTYPE=C

Versions of packages gcc-3.2 depends on:
ii  binutils                  2.13.90.0.10-1 The GNU assembler, linker and bina
ii  cpp-3.2                   1:3.2.1-0pre3  The GNU C preprocessor.
ii  gcc-3.2-base              1:3.2.1-0pre3  The GNU Compiler Collection (base 
ii  libc6                     2.2.5-14.3     GNU C Library: Shared libraries an
ii  libgcc1                   1:3.2.1-0pre3  GCC support library.

-- no debconf information


-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux beth 2.4.20 #1 Wed Jan 15 16:59:59 EST 2003 i686
Locale: LANG=C, LC_CTYPE=C

Versions of packages gcc-3.2 depends on:
ii  binutils                  2.13.90.0.10-1 The GNU assembler, linker and bina
ii  cpp-3.2                   1:3.2.1-0pre3  The GNU C preprocessor.
ii  gcc-3.2-base              1:3.2.1-0pre3  The GNU Compiler Collection (base 
ii  libc6                     2.2.5-14.3     GNU C Library: Shared libraries an
ii  libgcc1                   1:3.2.1-0pre3  GCC support library.

-- no debconf information