Rake tries to use gcc instead of g++

[djberg96]

OS X 10.4.9
Latest git repo

djberge:/Users/djberge/Repositories/rubinius [master]>./configure --cc=/usr/bin/g++
Configuring LLVM...
Checking for existing LLVM tree: found!

Checking sizeof(long): 4 bytes
Checking platform endianness: little endian
Checking tr1/hash definition: not found
Checking for function 'backtrace': not found.

Configured. Run 'rake' to build and run VM tests and rubyspecs
djberge:/Users/djberge/Repositories/rubinius [master]>rake
(in /Users/djberge/Repositories/rubinius)
LLVM inclusion enabled.
GEN vm/gen/instruction_names.cpp
GEN vm/gen/instruction_names.hpp
GEN vm/gen/instruction_sizes.hpp
GEN vm/gen/instruction_prototypes.hpp
GEN vm/gen/instruction_defines.hpp
GEN vm/gen/instruction_locations.hpp
GEN vm/gen/instruction_implementations.hpp
GEN vm/gen/instruction_visitors.hpp
GEN vm/gen/instruction_effects.hpp
/opt/test/bin/ruby vm/codegen/field_extract.rb vm/builtin/object.hpp vm/builtin/integer.hpp vm/builtin/fixnum.hpp vm/builtin/array.hpp vm/builtin/bignum.hpp vm/builtin/executable.hpp vm/builtin/access_variable.hpp vm/builtin/alias.hpp vm/builtin/block_environment.hpp vm/builtin/block_as_method.hpp vm/builtin/bytearray.hpp vm/builtin/io.hpp vm/builtin/channel.hpp vm/builtin/module.hpp vm/builtin/class.hpp vm/builtin/compiledmethod.hpp vm/builtin/data.hpp vm/builtin/dir.hpp vm/builtin/exception.hpp vm/builtin/float.hpp vm/builtin/immediates.hpp vm/builtin/iseq.hpp vm/builtin/list.hpp vm/builtin/lookuptable.hpp vm/builtin/ffi_pointer.hpp vm/builtin/methodtable.hpp vm/builtin/nativefunction.hpp vm/builtin/packed_object.hpp vm/builtin/randomizer.hpp vm/builtin/regexp.hpp vm/builtin/staticscope.hpp vm/builtin/string.hpp vm/builtin/symbol.hpp vm/builtin/thread.hpp vm/builtin/tuple.hpp vm/builtin/compactlookuptable.hpp vm/builtin/time.hpp vm/builtin/taskprobe.hpp vm/builtin/nativemethod.hpp vm/builtin/system.hpp vm/builtin/autoload.hpp vm/builtin/proc.hpp vm/builtin/variable_scope.hpp vm/builtin/location.hpp vm/builtin/capi_handle.hpp vm/builtin/global_cache_entry.hpp vm/builtin/weakref.hpp vm/builtin/fiber.hpp vm/builtin/thunk.hpp vm/builtin/call_unit.hpp vm/builtin/call_unit_adapter.hpp
Updating dependencies...
/usr/bin/cpp: line 1: /usr/bin/gcc: No such file or directory
cd vm/external_libs/libgdtoa; make
CC g__fmt.o
CC g_dfmt.o
ar cru libgdtoa.a dmisc.o dtoa.o g_Qfmt.o g__fmt.o g_ddfmt.o g_dfmt.o g_ffmt.o g_xLfmt.o g_xfmt.o gdtoa.o gethex.o gmisc.o hd_init.o hexnan.o misc.o smisc.o strtoIQ.o strtoId.o strtoIdd.o strtoIf.o strtoIg.o strtoIx.o strtoIxL.o strtod.o strtodI.o strtodg.o strtof.o strtopQ.o strtopd.o strtopdd.o strtopf.o strtopx.o strtopxL.o strtorQ.o strtord.o strtordd.o strtorf.o strtorx.o strtorxL.o sum.o ulp.o
ranlib libgdtoa.a
CC vm/agent.cpp
/opt/local/bin/gcc -Wall -Ivm/external_libs/llvm/include -I/Users/djberge/Repositories/rubinius/vm/external_libs/llvm/include -I/Users/djberge/Repositories/rubinius/vm/external_libs/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-common -Ivm/external_libs/libtommath -Ivm/external_libs/libgdtoa -Ivm/external_libs/onig -Ivm/external_libs/libffi/include -Ivm/test/cxxtest -Ivm -I. -I/usr/local/include -I/opt/local/include -Ivm/external_libs/udis86 -pipe -Wall -Wno-deprecated -DHAVE_STRLCAT -DHAVE_STRLCPY -mdynamic-no-pic -DENABLE_LLVM -ggdb3 -O2 -Werror -DRBX_PROFILER -c -o vm/agent.o vm/agent.cpp 2>&1
gcc: vm/agent.cpp: C++ compiler not installed on this system
rake aborted!
Command failed with status (1): [/opt/local/bin/gcc -Wall -Ivm/external_lib...]

(See full trace by running task with --trace)

[djberg96]

I worked around it by setting CC to /usr/bin/g++. Setting CXX did not work. However, I hit an issue on time. I'll post that separately, though.

[brixen]

Backport add --cxx to configure from multiverse (6596ed7). Closed by 1e73b42.

From original commit:

Most versions of GCC are smart enough to understand when we are compiling/linking
C++ code. However, the GCC 4.5 in MingW is apparently not one of the smart ones
so the tr1/hash detection code fails on Windows. On the other hand, C++ changed
the C prototype for ANYARGS functions, so e.g. BigDecimal C ext will not compile
properly with g++. So, we provide options for both in configure.