[Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release

["baker at usgs dot gov" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630

--- Comment #13 from Larry Baker <baker at usgs dot gov> 2012-11-20 19:57:41 UTC ---
Jakub,

The root of the problem is because GCC required a C++ linker, but the logic in
gcc/Makefile forces the linker to be $(CC) when HOST_LIBS are specified:

# The name of the compiler to use.
COMPILER = $(CXX)
COMPILER_FLAGS = $(CXXFLAGS)
# If HOST_LIBS is set, then the user is controlling the libraries to
# link against.  In that case, link with $(CC) so that the -lstdc++
# library is not introduced.  If HOST_LIBS is not set, link with
# $(CXX) to pick up -lstdc++.
ifeq ($(HOST_LIBS),)
LINKER = $(CXX)
LINKER_FLAGS = $(CXXFLAGS)
else
LINKER = $(CC)
LINKER_FLAGS = $(CFLAGS)
endif

Since GCC from now on will be implemented in C++, we can expect there will be
C++-only features (local statics, as you say).  This, in turn, implies to me
that GCC should be linked with a C++ compiler, not a C compiler.  Maybe this
Makefile should just honor what the user specifies, instead of switching to
$(CC).  E.g., if the user requires gcc, then they can define CXX=gcc.  This
also means that HOST_LIBS can use g++ syntax when CXX=g++.  Thus,
HOST_LIBS='-static-libgcc -static-libstdc++' will work as expected.

I hope someone will look at the cause of this error and think about whether the
Makefile behavior really makes sense the way it is.  I think not.