[RFC] Change dependency-generating compiler from $(CC) to $(CXX) in gcc/

[Jan-Benedict Glaw]

Hi!

I'm trying to build GCC on an AIX ppc system (gcc111.fsffrance.org),
where IBM's XL C compiler is installed, but not XL C++. So my
configury uses CC=/usr/bin/xlC, and a default value (g++) for CXX.

  Because $CC is used for dependency checking (gcc/configure.ac::977
or gcc/configure:8765), `depcomp' detects "aix" style dependency
generation, but that'll fail because g++ is actually used for
compilation. (This will result in all the .o files containing
dependency information.)

  Since we're using $(CXX) instead of $(CC) these days, I suggest
using CXX instead of CC. A quick check (without regenerating all
configure and Makefile files just changing CC to CXX in gcc/configure)
makes it build properly. (If done properly, some variables will change
their name s/CC/CXX/, so that must be changed in some more files if
done properly.)

  There are, however, some more directories (other than gcc/) that
might be equally affected: Searching for CCDEPMODE also reveals:

	* boehm-gc
	* libatomic
	* libcpp
	* libffi
	* libgfortran
	* libgo
	* libgomp
	* libitm
	* libjava
	* libmudflap
	* libquadmath
	* libsanitizer
	* libssp
	* libvtv
	* lto-plugin
	* zlib

I haven't checked these (if they're build with CC or CXX), but those
which use CXX (if there are any) should probably also be changed.

  My basic question though is: Shall I cook up a patch to do the
proper transition from CC to CXX for dependency generation? Or better
keep it as is (which I consider broken, but probably few people will
ever experience that problem)?

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
Signature of:         Alles wird gut! ...und heute wirds schon ein bißchen besser.
the second  :
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20131001/ed42ae11/attachment.sig>