bug#8616: conflict between build-aux/compile script and coreutils Makefiles

[Green, Paul]

Gentle Coreutils Developers,

I am writing to notify you of an issue that I stumbled across while
building coreutils-8.12 on the Stratus OpenVOS platform.

On this platform, we have both gcc and a native cc compiler. While gcc
handles the combination of the -c and -o arguments, our native cc
compiler does not. Thus, the coreutils configure script sets
ac_cv_prog_gcc_cc_c_o=no. This leads to using the build-aux/compile
script, which in turn leads to the following "interesting" result
(edited for clarity):

  CC       version.o
  AR       libver.a
  CC       cp.o
  CC       copy.o  (point 1)
  CC       cp-hash.o
  CC       extent-scan.o
  CCLD     cp.pm
  CC       ginstall-install.o
  CC       ginstall-prog-fprintf.o
  CC       ginstall-copy.o  (point 2)
  CC       ginstall-cp-hash.o
  CC       ginstall-extent-scan.o
  CCLD     ginstall.pm
  CC       mv.o
  CC       remove.o
  CCLD     mv.pm
gcc: copy.o: No such file or directory.
gcc: cp-hash.o: No such file or directory.
gcc: extent-scan.o: No such file or directory.
make[3]: *** [mv.pm] Error 1

The root cause of this failure is as follows. The same issue affects
copy.o, cp-hash.o and extent-scan.o, but I'll just focus on copy.o.

At point 1, the build-aux/compile runs gcc (w/o -o) to produce copy.o.
At point 2, the script produces copy.o again, then renames it to
ginstall-copy.o, thereby deleting copy.o.

The src/Makefile does not list copy.o as a dependency of mv.pm (Oops),
so Make does not rebuild copy.o prior to running the link command.
Hence, the linker (gcc) complains that it cannot find the file.  

On a platform where both cc and $CC handle the combination of -c and -o
correctly, this issue cannot arise.

The solution is either to make the compile script smarter, or to have
the dependencies of mv.pm properly listed, or to have mv.pm depend upon
a renamed copy of copy.o, much as is done for ginstall, or to set the
environment variable ac_cv_prog_cc_gcc_c_o=yes before running configure.
This last technique presumes that the faulty "cc" compiler is never
actually used, which seems to be the case here.

Speaking as someone who is fairly familiar with bash, make, and
autoconf, this was still took a lot longer to figure out that I'd like
to admit.  I believe that I have correctly explained the issue, but I
apologize if there are errors in the above description.

I suspect that you can reproduce this issue by forcing
ac_cv_prog_cc_gcc_c_o=no and then running configure.

At least now this issue will get into the mail archives, and be fodder
for some future web search. :-)

Thanks 
PG 
-- 
Paul Green, Senior Technical Consultant, Stratus Technologies. 
Voice: +1 978-461-7557; FAX: +1 978-461-3610; Mobile: +1 (978) 235-2451;
AIM: PaulGreen
Follow me on Twitter: stratuspaulg