* [Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
2012-09-19 21:15 [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
@ 2012-09-20 11:37 ` rguenth at gcc dot gnu.org
2012-09-20 20:28 ` baker at usgs dot gov
` (17 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-09-20 11:37 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
2012-09-19 21:15 [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
2012-09-20 11:37 ` [Bug middle-end/54630] [4.8 Regression] " rguenth at gcc dot gnu.org
@ 2012-09-20 20:28 ` baker at usgs dot gov
2012-09-20 20:30 ` baker at usgs dot gov
` (16 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: baker at usgs dot gov @ 2012-09-20 20:28 UTC (permalink / raw)
To: gcc-bugs
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++'
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
2012-09-19 21:15 [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
2012-09-20 11:37 ` [Bug middle-end/54630] [4.8 Regression] " rguenth at gcc dot gnu.org
2012-09-20 20:28 ` baker at usgs dot gov
@ 2012-09-20 20:30 ` baker at usgs dot gov
2012-09-21 18:58 ` baker at usgs dot gov
` (15 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: baker at usgs dot gov @ 2012-09-20 20:30 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
2012-09-19 21:15 [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
` (2 preceding siblings ...)
2012-09-20 20:30 ` baker at usgs dot gov
@ 2012-09-21 18:58 ` baker at usgs dot gov
2012-09-21 19:17 ` baker at usgs dot gov
` (14 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: baker at usgs dot gov @ 2012-09-21 18:58 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
2012-09-19 21:15 [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
` (3 preceding siblings ...)
2012-09-21 18:58 ` baker at usgs dot gov
@ 2012-09-21 19:17 ` baker at usgs dot gov
2012-09-21 20:35 ` baker at usgs dot gov
` (13 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: baker at usgs dot gov @ 2012-09-21 19:17 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
2012-09-19 21:15 [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
` (4 preceding siblings ...)
2012-09-21 19:17 ` baker at usgs dot gov
@ 2012-09-21 20:35 ` baker at usgs dot gov
2012-09-22 1:14 ` baker at usgs dot gov
` (12 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: baker at usgs dot gov @ 2012-09-21 20:35 UTC (permalink / raw)
To: gcc-bugs
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.)
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
2012-09-19 21:15 [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
` (5 preceding siblings ...)
2012-09-21 20:35 ` baker at usgs dot gov
@ 2012-09-22 1:14 ` baker at usgs dot gov
2012-09-22 1:45 ` baker at usgs dot gov
` (11 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: baker at usgs dot gov @ 2012-09-22 1:14 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
2012-09-19 21:15 [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
` (6 preceding siblings ...)
2012-09-22 1:14 ` baker at usgs dot gov
@ 2012-09-22 1:45 ` baker at usgs dot gov
2012-09-25 1:53 ` baker at usgs dot gov
` (10 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: baker at usgs dot gov @ 2012-09-22 1:45 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
2012-09-19 21:15 [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
` (7 preceding siblings ...)
2012-09-22 1:45 ` baker at usgs dot gov
@ 2012-09-25 1:53 ` baker at usgs dot gov
2012-11-19 3:02 ` jason at gcc dot gnu.org
` (9 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: baker at usgs dot gov @ 2012-09-25 1:53 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
2012-09-19 21:15 [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
` (8 preceding siblings ...)
2012-09-25 1:53 ` baker at usgs dot gov
@ 2012-11-19 3:02 ` jason at gcc dot gnu.org
2012-11-19 13:44 ` jakub at gcc dot gnu.org
` (8 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: jason at gcc dot gnu.org @ 2012-11-19 3:02 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
2012-09-19 21:15 [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
` (9 preceding siblings ...)
2012-11-19 3:02 ` jason at gcc dot gnu.org
@ 2012-11-19 13:44 ` jakub at gcc dot gnu.org
2012-11-20 9:24 ` jakub at gcc dot gnu.org
` (7 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: jakub at gcc dot gnu.org @ 2012-11-19 13:44 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
2012-09-19 21:15 [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
` (10 preceding siblings ...)
2012-11-19 13:44 ` jakub at gcc dot gnu.org
@ 2012-11-20 9:24 ` jakub at gcc dot gnu.org
2012-11-20 19:58 ` baker at usgs dot gov
` (6 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: jakub at gcc dot gnu.org @ 2012-11-20 9:24 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
2012-09-19 21:15 [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
` (11 preceding siblings ...)
2012-11-20 9:24 ` jakub at gcc dot gnu.org
@ 2012-11-20 19:58 ` baker at usgs dot gov
2012-11-20 20:20 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: baker at usgs dot gov @ 2012-11-20 19:58 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
2012-09-19 21:15 [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
` (12 preceding siblings ...)
2012-11-20 19:58 ` baker at usgs dot gov
@ 2012-11-20 20:20 ` jakub at gcc dot gnu.org
2012-11-20 22:25 ` baker at usgs dot gov
` (4 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: jakub at gcc dot gnu.org @ 2012-11-20 20:20 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
2012-09-19 21:15 [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
` (13 preceding siblings ...)
2012-11-20 20:20 ` jakub at gcc dot gnu.org
@ 2012-11-20 22:25 ` baker at usgs dot gov
2012-11-21 11:20 ` redi at gcc dot gnu.org
` (3 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: baker at usgs dot gov @ 2012-11-20 22:25 UTC (permalink / raw)
To: gcc-bugs
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++.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
2012-09-19 21:15 [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
` (14 preceding siblings ...)
2012-11-20 22:25 ` baker at usgs dot gov
@ 2012-11-21 11:20 ` redi at gcc dot gnu.org
2012-11-21 21:38 ` baker at usgs dot gov
` (2 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: redi at gcc dot gnu.org @ 2012-11-21 11:20 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
2012-09-19 21:15 [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
` (15 preceding siblings ...)
2012-11-21 11:20 ` redi at gcc dot gnu.org
@ 2012-11-21 21:38 ` baker at usgs dot gov
2012-11-22 0:51 ` ian at airs dot com
2012-11-26 19:44 ` baker at usgs dot gov
18 siblings, 0 replies; 20+ messages in thread
From: baker at usgs dot gov @ 2012-11-21 21:38 UTC (permalink / raw)
To: gcc-bugs
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++.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
2012-09-19 21:15 [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
` (16 preceding siblings ...)
2012-11-21 21:38 ` baker at usgs dot gov
@ 2012-11-22 0:51 ` ian at airs dot com
2012-11-26 19:44 ` baker at usgs dot gov
18 siblings, 0 replies; 20+ messages in thread
From: ian at airs dot com @ 2012-11-22 0:51 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread* [Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
2012-09-19 21:15 [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
` (17 preceding siblings ...)
2012-11-22 0:51 ` ian at airs dot com
@ 2012-11-26 19:44 ` baker at usgs dot gov
18 siblings, 0 replies; 20+ messages in thread
From: baker at usgs dot gov @ 2012-11-26 19:44 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 20+ messages in thread