[Bug libstdc++/54630] New: GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release

[Bug libstdc++/54630] New: GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release

[baker at usgs dot gov]

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

             Bug #: 54630
           Summary: GCC 4.8 --enable-languages=c build fails: Undefined
                    symbols: ___cxa_guard_acquire and ___cxa_guard_release
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: blocker
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: baker@usgs.gov


Created attachment 28222
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28222
Download, configure, and build gcc 4.8 for ColdFire uClinux

Build of 4.8 20120909 snapshot
(http://fossies.org/unix/misc/gcc-4.8-20120909.tar.gz) fails for
--enable-languages=c:

g++ -c  -DIN_GCC_FRONTEND -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE 
-fno-exceptions -fno-rtti -W -Wall -Wwrite-strings -Wcast-qual
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I.
-I/tmp/freescale-coldfile-xgcc/cross-gcc-4.8-20120909/../gcc-4.8-20120909/gcc
-I/tmp/freescale-coldfile-xgcc/cross-gcc-4.8-20120909/../gcc-4.8-20120909/gcc/.
-I/tmp/freescale-coldfile-xgcc/cross-gcc-4.8-20120909/../gcc-4.8-20120909/gcc/../include
-I/tmp/freescale-coldfile-xgcc/cross-gcc-4.8-20120909/../gcc-4.8-20120909/gcc/../libcpp/include

-I/tmp/freescale-coldfile-xgcc/cross-gcc-4.8-20120909/../gcc-4.8-20120909/gcc/../libdecnumber
-I/tmp/freescale-coldfile-xgcc/cross-gcc-4.8-20120909/../gcc-4.8-20120909/gcc/../libdecnumber/dpd
-I../libdecnumber    cc1-checksum.c -o cc1-checksum.o
gcc   -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions -fno-rtti -W
-Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common 
-DHAVE_CONFIG_H  -o cc1 c/c-lang.o c-family/stub-objc.o attribs.o c/c-errors.o
c/c-decl.o c/c-typeck.o c/c-convert.o c/c-aux-info.o c/c-objc-common.o
c/c-parser.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o
c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o
c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o
c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o
tree-mudflap.o default-c.o \
      cc1-checksum.o libbackend.a main.o tree-browser.o libcommon-target.a
libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a  -liconv ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a -static-libgcc -static-libstdc++ -lm  -lmpc
-lmpfr -lgmp  -static-libgcc -static-libstdc++ -lm -L../zlib -lz
Undefined symbols:
  "___cxa_guard_acquire", referenced from:
      coalesce_ssa_name()     in libbackend.a(tree-ssa-coalesce.o)
  "___cxa_guard_release", referenced from:
      coalesce_ssa_name()     in libbackend.a(tree-ssa-coalesce.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[2]: *** [cc1] Error 1
make[1]: *** [all-gcc] Error 2
make: *** [all] Error 2

It looks to me like: now that GCC is implemented in C++, certain libstdc++
functions are needed, but are not compiled when --enable-languages=c.

Attached are instructions to replicate my build.

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

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-09-20
          Component|libstdc++                   |middle-end
                 CC|                            |crowl at gcc dot gnu.org,
                   |                            |dnovillo at gcc dot
                   |                            |gnu.org, rguenth at gcc dot
                   |                            |gnu.org
     Ever Confirmed|0                           |1
            Summary|GCC 4.8                     |[4.8 Regression] GCC 4.8
                   |--enable-languages=c build  |--enable-languages=c build
                   |fails: Undefined symbols:   |fails: Undefined symbols:
                   |___cxa_guard_acquire and    |___cxa_guard_acquire and
                   |___cxa_guard_release        |___cxa_guard_release
   Target Milestone|---                         |4.8.0

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-09-20 11:37:04 UTC ---
Ick.  Now

  static hash_table <ssa_name_var_hash> ssa_name_hash;

appearantly has a guarded init!?

  D.38548 = __cxa_guard_acquire (&_ZGVZ17coalesce_ssa_namevE13ssa_name_hash);
  retval.1 = D.38548 != 0;
  if (retval.1 != 0) goto <D.38549>; else goto <D.38550>;
  <D.38549>:
  D.38265 = 0;
  try
    {
      hash_table<ssa_name_var_hash>::hash_table (&ssa_name_hash);
      D.38265 = 1;
      __cxa_guard_release (&_ZGVZ17coalesce_ssa_namevE13ssa_name_hash);
    }
  catch
    {
      if (D.38265 != 0) goto <D.38551>; else goto <D.38552>;
      <D.38551>:
      goto <D.38553>;
      <D.38552>:
      __cxa_guard_abort (&_ZGVZ17coalesce_ssa_namevE13ssa_name_hash);
      <D.38553>:
    }

I suppose easiest is to remove the 'static' keyword here.

Larry, can you test that?

[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]

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

--- Comment #2 from Larry Baker <baker at usgs dot gov> 2012-09-20 20:28:08 UTC ---
This bug also occurs when --enable-languages=c,c++.  I am building a cross
compiler for ColdFire uClinux, TARGET=m68k-uclinux.  On Mac OS X
HOST=BUILD=x86_64-apple-darwin10.8.0, there are no errors.  On Linux i386
HOST=BUILD=i686-pc-linux-gnu, I get the undefined references to
__cxa_guard_acquire and __cxa_guard_release.

The bug is due to the link step for cc1, lto1 (maybe more) using gcc; it should
be using g++ (see below).  I don't know which Makefile(s) to fix.  It also
looks like the command emitted depends on the HOST or BUILD platform.

CentOS Linux has such an old gcc, it does not recognize -static-libstdc++

# cat /etc/redhat-release
CentOS release 6.3 (Final)

# gcc -v
Using built-in specs.
Target: i686-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch=i686
--build=i686-redhat-linux
Thread model: posix
gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) 

>From the build directory

# pwd
/tmp/freescale-coldfile-xgcc/cross-gcc-4.8.0-experimental/gcc

This is the (first) make command that fails (I did a make -j4, so the link of
lto1 also failed)

# gcc   -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions -fno-rtti
-W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common 
-DHAVE_CONFIG_H  -o cc1 c/c-lang.o c-family/stub-objc.o attribs.o c/c-errors.o
c/c-decl.o c/c-typeck.o c/c-convert.o c/c-aux-info.o c/c-objc-common.o
c/c-parser.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o
c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o
c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o
c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o
tree-mudflap.o default-c.o \
>   cc1-checksum.o libbackend.a main.o tree-browser.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a   ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -static-libgcc -static-libstdc++ -lm  -lmpc -lmpfr -lgmp -rdynamic -ldl -static-libgcc -static-libstdc++ -lm -L../zlib -lz
gcc: unrecognized option '-static-libstdc++'
gcc: unrecognized option '-static-libstdc++'
libbackend.a(tree-ssa-coalesce.o): In function `coalesce_ssa_name()':
/tmp/freescale-coldfile-xgcc/cross-gcc-4.8.0-experimental/../gcc-4.8.0-experimental/gcc/tree-ssa-coalesce.c:1294:
undefined reference to `__cxa_guard_acquire'
/tmp/freescale-coldfile-xgcc/cross-gcc-4.8.0-experimental/../gcc-4.8.0-experimental/gcc/tree-ssa-coalesce.c:1294:
undefined reference to `__cxa_guard_release'
collect2: ld returned 1 exit status

Using g++ instead of gcc cures the problem

# g++   -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions -fno-rtti
-W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common 
-DHAVE_CONFIG_H  -o cc1 c/c-lang.o c-family/stub-objc.o attribs.o c/c-errors.o
c/c-decl.o c/c-typeck.o c/c-convert.o c/c-aux-info.o c/c-objc-common.o
c/c-parser.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o
c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o
c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o
c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o
tree-mudflap.o default-c.o   cc1-checksum.o libbackend.a main.o tree-browser.o
libcommon-target.a libcommon.a ../libcpp/libcpp.a
../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a  
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -static-libgcc
-static-libstdc++ -lm  -lmpc -lmpfr -lgmp -rdynamic -ldl -static-libgcc
-static-libstdc++ -lm -L../zlib -lz
g++: unrecognized option '-static-libstdc++'
g++: unrecognized option '-static-libstdc++'

[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]

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

--- Comment #3 from Larry Baker <baker at usgs dot gov> 2012-09-20 20:30:29 UTC ---
Richard,

Wrong track ... I found the problem (which also occurs when
--enable-languages=c,c++).  See my posting.

Larry Baker
US Geological Survey
650-329-5608
baker@usgs.gov



On 20 Sep 2012, at 4:37 AM, rguenth at gcc dot gnu.org wrote:

> build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
> 
> Date: Thu, 20 Sep 2012 11:37:04 +0000
> 
> X-Bugzilla-Reason: Reporter
> 
> X-Bugzilla-Type: changed
> 
> X-Bugzilla-Watch-Reason: None
> 
> X-Bugzilla-Product: gcc
> 
> X-Bugzilla-Component: middle-end
> 
> X-Bugzilla-Keywords: 
> 
> X-Bugzilla-Severity: blocker
> 
> X-Bugzilla-Who: rguenth at gcc dot gnu.org
> 
> X-Bugzilla-Status: NEW
> 
> X-Bugzilla-Priority: P3
> 
> X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
> 
> X-Bugzilla-Target-Milestone: 4.8.0
> 
> X-Bugzilla-Changed-Fields: Status Last reconfirmed Component CC Ever
> 
> Confirmed Summary Target Milestone
> 
> Message-ID: <bug-54630-22003-vRIYWVWXGt@http.gcc.gnu.org/bugzilla/>
> 
> In-Reply-To: <bug-54630-22003@http.gcc.gnu.org/bugzilla/>
> 
> References: <bug-54630-22003@http.gcc.gnu.org/bugzilla/>
> 
> X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
> 
> Auto-Submitted: auto-generated
> 
> Content-Type: text/plain; charset="UTF-8"
> 
> MIME-Version: 1.0
> 
> 
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630
> 
> 
> 
> Richard Guenther <rguenth at gcc dot gnu.org> changed:
> 
> 
> 
>           What    |Removed                     |Added
> 
> ----------------------------------------------------------------------------
> 
>             Status|UNCONFIRMED                 |NEW
> 
>   Last reconfirmed|                            |2012-09-20
> 
>          Component|libstdc++                   |middle-end
> 
>                 CC|                            |crowl at gcc dot gnu.org,
> 
>                   |                            |dnovillo at gcc dot
> 
>                   |                            |gnu.org, rguenth at gcc dot
> 
>                   |                            |gnu.org
> 
>     Ever Confirmed|0                           |1
> 
>            Summary|GCC 4.8                     |[4.8 Regression] GCC 4.8
> 
>                   |--enable-languages=c build  |--enable-languages=c build
> 
>                   |fails: Undefined symbols:   |fails: Undefined symbols:
> 
>                   |___cxa_guard_acquire and    |___cxa_guard_acquire and
> 
>                   |___cxa_guard_release        |___cxa_guard_release
> 
>   Target Milestone|---                         |4.8.0
> 
> 
> 
> --- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-09-20 11:37:04 UTC ---
> 
> Ick.  Now
> 
> 
> 
>  static hash_table <ssa_name_var_hash> ssa_name_hash;
> 
> 
> 
> appearantly has a guarded init!?
> 
> 
> 
>  D.38548 = __cxa_guard_acquire (&_ZGVZ17coalesce_ssa_namevE13ssa_name_hash);
> 
>  retval.1 = D.38548 != 0;
> 
>  if (retval.1 != 0) goto <D.38549>; else goto <D.38550>;
> 
>  <D.38549>:
> 
>  D.38265 = 0;
> 
>  try
> 
>    {
> 
>      hash_table<ssa_name_var_hash>::hash_table (&ssa_name_hash);
> 
>      D.38265 = 1;
> 
>      __cxa_guard_release (&_ZGVZ17coalesce_ssa_namevE13ssa_name_hash);
> 
>    }
> 
>  catch
> 
>    {
> 
>      if (D.38265 != 0) goto <D.38551>; else goto <D.38552>;
> 
>      <D.38551>:
> 
>      goto <D.38553>;
> 
>      <D.38552>:
> 
>      __cxa_guard_abort (&_ZGVZ17coalesce_ssa_namevE13ssa_name_hash);
> 
>      <D.38553>:
> 
>    }
> 
> 
> 
> I suppose easiest is to remove the 'static' keyword here.
> 
> 
> 
> Larry, can you test that?
> 
> 
> 
> -- 
> 
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> 
> ------- You are receiving this mail because: -------
> 
> You reported the bug.

[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]

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

--- Comment #4 from Larry Baker <baker at usgs dot gov> 2012-09-21 18:56:20 UTC ---
Richard,

On both Mac OS X and Linux, the link step uses gcc.

On Mac OS X, the link succeed; on Linux, the link fails.

The LINKER is selected by the following logic in the gcc/Makefile:

# 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

The reason LINKER is set to gcc on both systems is I use the configure
--with-host-libstdcxx option:

Mac OS X: --with-host-libstdcxx='-lstdc++ -lm'
Linux: --with-host-libstdcxx='-static-libgcc -static-libstdc++ -lm'

(I don't know why the -lm is there; I copied that from Sourcery's ColdFire
uClinux SDK build script.)

which defines HOST_LIBS in gcc/Makefile:

# Libraries to use on the host.
Mac OS X: HOST_LIBS = -lstdc++ -lm
Linux: HOST_LIBS = -static-libgcc -static-libstdc++ -lm

The original --with-host-libstdcxx from Sourcery (Mentor Graphics) ColdFire
uClinux SDK build scripts was:

--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'

I guess Sourcery used '-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' so
that the cross compilers would not have system library dependencies, and could
be delivered in a tarball that would work on many Linux systems without
introducing a shared-llibrary dependency.

I altered that to use the more recent gcc option -static-libstdc++ in place of
-Wl,-Bstatic,-lstdc++,-Bdynamic.

I'm thinking a couple things are happening:

• On Mac OS X, the link works because I do not use static libraries (Mac OS X
does not support them), and -lstdc++ brings in the O/S version of guard.cc.
• On CentOS Linux 6.3, gcc is too old to recognize -static-libstdc++.  (I'm
assuming a more recent gcc driver recognizes it; it may be that it is only
recognized by the g++ driver.)  I'll try to make a more recent HOST gcc that
supports -static-libstdc++.  (Anyone know which release added it?)

However, I do not understand the logic of selecting gcc in the first place.

--with-host-libstdcxx is described at
http://gcc.gnu.org/install/configure.html:

--with-host-libstdcxx=linker-args
If you are linking with a static copy of PPL, you can use this option to
specify how the linker should find the standard C++ library used internally by
PPL. Typical values of linker-args might be `-lstdc++' or
`-Wl,-Bstatic,-lstdc++,-Bdynamic -lm'. If you are linking with a shared copy of
PPL, you probably do not need this option; shared library dependencies will
cause the linker to search for the standard C++ library automatically. 

This implies two things to me:

1) This is the only way to pass linker args (that I could find)
2) This is for c++ (...-libstdcxx means c++, right?)

The "linker-args" get turned into HOST_LIBS in gcc/Makefile, used to define
LIBS and BACKENDLIBS:

# How to link with both our special library facilities
# and the system's installed libraries.
LIBS =  libcommon.a $(CPPLIB) $(LIBINTL) $(LIBICONV) $(LIBIBERTY) \
    $(LIBDECNUMBER) $(HOST_LIBS)
BACKENDLIBS = $(CLOOGLIBS) $(GMPLIBS) $(PLUGINLIBS) $(HOST_LIBS) \
    $(ZLIB)

which, to me, means something different than "linker-args".

It seems to me that a main program compiled by g++ should be linked by g++. 
Linker args are a separate matter.

In any case, the web page should probably be updated to warn that
--with-host-libstdcxx causes ALL linking (at least for the compilers) to use
gcc instead of g++.  This matters now because GCC's implementation language
changes from C to C++ with release 4.8.

[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]

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

--- Comment #5 from Larry Baker <baker at usgs dot gov> 2012-09-21 19:16:50 UTC ---
>From what I can tell from the GCC Link Options web page
(http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#index-static_002dlibgcc-1032),
-static-libstdc++ is only a g++ driver option:

-static-libstdc++
When the g++ program is used to link a C++ program, it normally automatically
links against libstdc++. If libstdc++ is available as a shared library, and the
-static option is not used, then this links against the shared version of
libstdc++. That is normally fine. However, it is sometimes useful to freeze the
version of libstdc++ used by the program without going all the way to a fully
static link. The -static-libstdc++ option directs the g++ driver to link
libstdc++ statically, without necessarily linking other libraries statically. 

There appears to be no way to pass -static-libstdc++ to the g++ driver for
linking.  --with-host-libstdcxx=-static-libstdc++ will cause gcc/Makefile to
use gcc for the LINKER, instead of just passing the -static-libstdc++ option to
the g++ driver.

[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]

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

--- Comment #6 from Larry Baker <baker at usgs dot gov> 2012-09-21 20:34:41 UTC ---
I'm looking at CFLAGS_FOR_BUILD and CXXFLAGS_FOR_BUILD as a way to pass
-static-libgcc and -static-libstdc++ to the linker, respectively.  In the
top-level generated Makefile, I noticed that CXXFLAGS_FOR_BUILD is not included
in the list of variables in BASE_FLAGS_TO_PASS:

# Flags to pass down to all sub-makes.
BASE_FLAGS_TO_PASS = \
:

Whereas, CC_FOR_BUILD, CFLAGS_FOR_BUILD, and CXX_FOR_BUILD are included.

Is this an oversight?

And, the description of EXTRA_BUILD_FLAGS makes it sound like it should also
include the CXX variants:

# These variables must be set on the make command line for directories
# built for the build system to override those in BASE_FLAGS_TO_PASSS.
EXTRA_BUILD_FLAGS = \
    CFLAGS="$(CFLAGS_FOR_BUILD)" \
    LDFLAGS="$(LDFLAGS_FOR_BUILD)"

(P.S. BASE_FLAGS_TO_PASSS is misspelled.)

[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]

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

--- Comment #7 from Larry Baker <baker at usgs dot gov> 2012-09-22 01:13:54 UTC ---
I'm kind of stumped at the moment to find an alternative method to pass down
linker flags without using --with-host-libstdcxx.  I tried setting

CFLAGS_FOR_BUILD="-x c -x none" \
CXXFLAGS_FOR_BUILD="-x c++ -x none" \
LDFLAGS_FOR_BUILD="-x none" \

in the configure step.  I also hacked Makefile.in to pass CXXFLAGS_FOR_BUILD in
BASE_FLAGS_TO_PASS.

The CFLAGS_FOR_BUILD="-x c -x none" show up in the gcc compile commands (the
"make gcc" screen output), but I'm not sure it is used in every gcc command. 
The CXXFLAGS_FOR_BUILD="-x c++ -x none" and LDFLAGS_FOR_BUILD="-x none" never
show up.

I don't really care that much about static linking myself.  But, I can
understand why a vendor or package developer might want to have the capability.

[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]

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

--- Comment #8 from Larry Baker <baker at usgs dot gov> 2012-09-22 01:45:31 UTC ---
After changing --with-host-libstdcxx back to

--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'

the build succeeds for Linux i386.  I am sure LINKER was set to gcc in this
case.

I am rebuilding without --with-host-libstdcxx to verify that the cross compiler
can be built when LINKER is set to g++ for Linux i386.

After that, I'll try to use a newer GCC on CentoS Linux i386 and try again with
--with-host-libstdcxx='-static-libgcc -static-libstdc++ -lm'.  This seems to be
the more modern equivalent on more recent gcc/g++ compilers.  I found 4.6 and
4.7 compilers include both -static-libgcc and -static-libstdc++ (strings
host-gcc/g++-compiler | grep [-]static[-]).

You can probably reclassify this case from a bug to a feature request.

[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]

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

--- Comment #9 from Larry Baker <baker at usgs dot gov> 2012-09-25 01:53:01 UTC ---
The build on Linux i386 works fine without --with-host-libstdcxx.  I believe
g++ is used for linking.

I tried using a native Linux i386 GCC 4.7.1 to build a cross GCC 4.8.0, with
--with-host-libstdcxx='-static-libgcc -static-libstdc++'.  That fails with the
same error I encountered before: undefined references to __cxa_guard_acquire
and __cxa_guard_release in the link step.  I am sure this is because gcc was
used and libstdc++ was not searched because I did not include -lstdc++ in
--with-host-libstdcxx.

Lastly, I hacked gcc/Makefile.in to always use g++ for the linker:

# Libraries to use on the host.
HOST_LIBS = @HOST_LIBS@

# 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

# ( cd cross-gcc-4.8.0-experimental ;
PATH=/usr/local/gcc-4.7.1/bin:${PWD}/../freescale-coldfire-2011.09/bin:${PATH/.:/}
CC_FOR_BUILD=gcc CC=gcc CXX=g++ AR=ar RANLIB=ranlib
AS_FOR_TARGET=m68k-uclinux-as LD_FOR_TARGET=m68k-uclinux-ld
AR_FOR_TARGET=m68k-uclinux-ar RANLIB_FOR_TARGET=m68k-uclinux-ranlib
NM_FOR_TARGET=m68k-uclinux-nm OBJDUMP_FOR_TARGET=m68k-uclinux-objdump
STRIP_FOR_TARGET=m68k-uclinux-strip ${PWD}/../gcc-4.8.0-experimental/configure
--disable-decimal-float --disable-fixed-point --disable-libffi
--disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp
--disable-libstdcxx-pch --disable-nls --disable-shared --enable-languages=c,c++
--enable-lto --enable-poison-system-directories --enable-threads
--prefix=/usr/local/gcc-4.8.0 --program-prefix=m68k-uclinux-
--target=m68k-uclinux --with-arch=cf --with-gnu-as --with-gnu-ld
--with-build-time-tools=${PWD}/../freescale-coldfire-2011.09/m68k-uclinux/bin
--with-host-libstdcxx='-static-libgcc -static-libstdc++'
--with-sysroot=${PWD}/../freescale-coldfire-2011.09/m68k-uclinux/libc )

# ( cd cross-gcc-4.8.0-experimental ;
PATH=/usr/local/gcc-4.7.1/bin:${PWD}/../freescale-coldfire-2011.09/bin:${PATH/.:/}
make -j4 )

# ( cd cross-gcc-4.8.0-experimental ;
PATH=/usr/local/gcc-4.7.1/bin:${PWD}/../freescale-coldfire-2011.09/bin:${PATH/.:/}
make install )

This works fine.  This is as close as I could get to supplying
LDFLAGS_FOR_BUILD='-static-libgcc -static-libstdc++' to the link step without
causing LINKER=gcc.

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

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org

--- Comment #10 from Jason Merrill <jason at gcc dot gnu.org> 2012-11-19 03:01:55 UTC ---
We could build GCC with -fno-threadsafe-statics, though in general it seems
reasonable for to depend on the C++ language support library.

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

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-11-19 13:44:21 UTC ---
Author: jakub
Date: Mon Nov 19 13:44:15 2012
New Revision: 193620

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193620
Log:
    PR middle-end/54630
    * tree-ssa-coalesce.c (coalesce_ssa_name): Remove static
    keyword from ssa_name_hash var.

    * class.c (fixed_type_or_null_ref_ht): New variable.
    (fixed_type_or_null): Use it instead of local static ht.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/class.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-ssa-coalesce.c

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |jakub at gcc dot gnu.org
         Resolution|                            |INVALID

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-11-20 09:23:33 UTC ---
Closing as user error, although the usage of local statics has been changed,
but future local statics might appear.

[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]

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.

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

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-11-20 20:19:58 UTC ---
It is intentionally that way, so that one can fine tune the C++ libraries
linked into the binary with --with-host-libstdcxx, but you are responsible for
specifying there all the needed libraries.  Don't use this configure option if
you don't need it.

[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]

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

--- Comment #15 from Larry Baker <baker at usgs dot gov> 2012-11-20 22:24:46 UTC ---
Jakub,

I undertand the reason for the --with-host-libstdcxx option.  The documentation
for --with-host-libstdcxx doesn't say anything about the side effect of
changing the LINKER from $(CXX) to $(CC).  It is that effect that I believe is
undesirable, especially given the change of GCC's implementation language from
C to C++.

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|blocker                     |normal

--- Comment #16 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-11-21 11:19:54 UTC ---
When LINKER=$(CXX) you do not "link with a C++ compiler" you still link with
the linker, ld, but the g++ driver passes it additional libs including
-lstdc++. That means you can't fine-tune which libstdc++ is used, defeating the
purpose of --with-host-libstdcxx. To allow fine-tuning the libs, you need the
additional libs to not be used, which implies not linking with g++.

If you use --with-host-libstdcxx then you need to get the argument right.

(In reply to comment #8)
> After that, I'll try to use a newer GCC on CentoS Linux i386 and try again with
> --with-host-libstdcxx='-static-libgcc -static-libstdc++ -lm'.  This seems to be
> the more modern equivalent on more recent gcc/g++ compilers. 

No, it's not equivalent, -static-libstdcxx does not imply -lstdc++, which is
why you get missing symbols.

Why not just use the Sourcery configuration that works?

[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]

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

--- Comment #17 from Larry Baker <baker at usgs dot gov> 2012-11-21 21:37:26 UTC ---
Jonathan,

Yes, I should have said "link with a C++ driver" instead of "link with a C++
compiler".

>No, it's not equivalent, -static-libstdcxx does not imply -lstdc++,
> which is why you get missing symbols.

-static-libstdcxx has nothing to do with why I get the missing symbols.  I get
the missing symbols because the LINKER changed from $(CC) to $(CXX).

>Why not just use the Sourcery configuration that works?

Why change the LINKER for a C++ program from $(CXX) to $(CC)?  That is what
causes the link to fail.  The g++ driver may have any number of built-in ld
options that differ from the gcc driver.  Why should I care?  The point of
using the g++ driver for a C++ program is that it takes care of all that for
me.

If I get everything working for my cross compiler without using
--with-host-libstdcxx, then the LINKER is $(CXX), which implies -lstdc++.  Now,
suppose I want to eliminate the dependencies of my cross compiler on the libc
and llibc++ shared libraries that happen to be on my Linux system, so that my
cross compiler will run on many Linux systems with possibly different libc's
and libc++'s.  In that case, I do not want to select different library (e.g., a
debug variant), I want to select the .a variant in place of the .so variant. 
If I were writing my own link command, I would use g++ to do the linking with
the options "-static-libgcc -static-libstdc++".  So, how to do the same when
building a GCC cross compiler?

The GCC installation notes, http://gcc.gnu.org/install/configure.html, offer
only one method to add linker options to build GCC: --with-host-libstdcxx.  The
example given there is `-Wl,-Bstatic,-lstdc++,-Bdynamic -lm', which is
equivalent to g++ -static-libstdc++ (plus -lm, which I have no idea why it is
there).  (As far as I can tell, Sourcery copied this example verbatim,
including the unnecessary -lm.)  This example was likely written before the g++
-static-libstdc++ options existed, and certainly was written before the GCC
implementation language was changed from C to C++.  What is not mentioned is
the side effect that the LINKER will change from $(CXX) to ($CC).

>To allow fine-tuning the libs, you need the
>additional libs to not be used, which implies not linking with g++.

Then they should specify CXX=gcc (since there is no way to specify the LINKER
directly).

All this will be moot, I think, when others start bumping into GCC builds that
fail as more of GCC is implemented in C++.

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

[ian at airs dot com]

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

Ian Lance Taylor <ian at airs dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ian at airs dot com

--- Comment #18 from Ian Lance Taylor <ian at airs dot com> 2012-11-22 00:50:46 UTC ---
You can also add linker options via the configure options --with-stage1-ldflags
and --with-boot-ldflags, q.v.

Although it is not documented specifically for GCC, you can also set LDFLAGS
when running make, as you can for all GNU programs.

[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]

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

--- Comment #19 from Larry Baker <baker at usgs dot gov> 2012-11-26 19:44:21 UTC ---
(In reply to comment #18)

Ian,

> You can also add linker options via the configure options --with-stage1-ldflags
> and --with-boot-ldflags, q.v.

So, I read what the GCC configure notes had to say about
--with-boot-ldflags=flags, and it sounds like exactly what Sourceery was trying
to do with --with-host-libstdcxx='-static-libgcc
-Wl,-Bstatic,-lstdc++,-Bdynamic -lm'.  That is, the default is to statically
link the C and C++ run-time libraries.

--with-boot-ldflags=flags
This option may be used to set linker flags to be used when linking stage 2 and
later when bootstrapping GCC. If neither –with-boot-libs nor
–with-host-libstdcxx is set to a value, then the default is `-static-libstdc++
-static-libgcc'. 

> Although it is not documented specifically for GCC, you can also set LDFLAGS
> when running make, as you can for all GNU programs.

I might have already tried this and it fails.  (I can't remember exactly.) 
Take a look at my Comment 6 from 2012-09-21 20:34:41.  You'll see that the GCC
build machinery overrides CFLAGS and LDFLAGS with CFLAGS_FOR_BUILD and
LDFLAGS_FOR_BUILD, respectively.

I think your first suggestion is definitely the best solution.  The next time I
work on this, I'll check the results of the link of the cross gcc to see if the
default stage 2 build really does eliminate the dependencies on the shared C
and C++ run-time libraries.

Thanks.