public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/53579] New: libstdc++ configure atomicity tests use CXXFLAGS instead of CXXFLAGS_FOR_TARGET
@ 2012-06-05 0:18 olegendo at gcc dot gnu.org
2012-08-07 20:53 ` [Bug libstdc++/53579] " bkoz at gcc dot gnu.org
2014-12-29 17:40 ` [Bug libstdc++/53579] libstdc++ configure " anatol.pomozov at gmail dot com
0 siblings, 2 replies; 3+ messages in thread
From: olegendo at gcc dot gnu.org @ 2012-06-05 0:18 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53579
Bug #: 53579
Summary: libstdc++ configure atomicity tests use CXXFLAGS
instead of CXXFLAGS_FOR_TARGET
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: olegendo@gcc.gnu.org
When trying to fix PR 29366 by removing config/cpu/sh/atomicity.h I've noticed
that libstdc++'s configure would refuse to pick up
config/cpu/generic/atomicity_builtins.
On the SH target atomicity builtins have to be enabled by either -msoft-atomic
or -mhard-atomic. For sh-linux -msoft-atomic is enabled by default. When
building a cross toolchain (top level make) CFLAGS_FOR_TARGET /
CXXFLAGS_FOR_TARGET can be used to enable the atomicity builtins. However,
libstdc++ configure uses CXXFLAGS when testing for atomicity builtins
availability, so it will default to using config/cpu/generic/atomicity_mutex.
I'm not quite sure where the fix should go, either in the top level
configure/makefile (which fails to set CXXFLAGS to CXXFLAGS_FOR_TARGET for
libstdc++ configure) or libstdc++ itself, because when libstdc++ is actually
compiled CXXFLAGS_FOR_TARGET is passed to xgcc as expected.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug libstdc++/53579] libstdc++ configure atomicity tests use CXXFLAGS instead of CXXFLAGS_FOR_TARGET
2012-06-05 0:18 [Bug libstdc++/53579] New: libstdc++ configure atomicity tests use CXXFLAGS instead of CXXFLAGS_FOR_TARGET olegendo at gcc dot gnu.org
@ 2012-08-07 20:53 ` bkoz at gcc dot gnu.org
2014-12-29 17:40 ` [Bug libstdc++/53579] libstdc++ configure " anatol.pomozov at gmail dot com
1 sibling, 0 replies; 3+ messages in thread
From: bkoz at gcc dot gnu.org @ 2012-08-07 20:53 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53579
Benjamin Kosnik <bkoz at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bkoz at gcc dot gnu.org
--- Comment #1 from Benjamin Kosnik <bkoz at gcc dot gnu.org> 2012-08-07 20:53:26 UTC ---
Some notes.
src/Makefile.am does not export CXXFLAGS_FOR_TARGET, only CFLAGS_FOR_TARGET.
The problem is that configure CXXFLAGS ends up being different than build
CXXFLAGS. And configure flags don't play with CXXFLAGS_FOR_TARGET (but build
flags do.)
gcc/Makefile.in has the pass down for target libs:
EXTRA_TARGET_FLAGS = \
'AR=$$(AR_FOR_TARGET)' \
'AS=$(COMPILER_AS_FOR_TARGET)' \
'CC=$$(CC_FOR_TARGET) $$(XGCC_FLAGS_FOR_TARGET) $$(TFLAGS)' \
'CFLAGS=$$(CFLAGS_FOR_TARGET)' \
'CXX=$$(CXX_FOR_TARGET) $$(XGCC_FLAGS_FOR_TARGET) $$(TFLAGS)' \
'CXXFLAGS=$$(CXXFLAGS_FOR_TARGET)' \
This is what is expected and needed for build, but for configure the situation
is not working in an equivalent manner.
config/mt-gnu:
CXXFLAGS_FOR_TARGET = $(CXXFLAGS) -D_GNU_SOURCE
configure.ac:
if test "x$CXXFLAGS_FOR_TARGET" = x; then
CXXFLAGS_FOR_TARGET=$CXXFLAGS
case " $CXXFLAGS " in
*" -O2 "*) ;;
*) CXXFLAGS_FOR_TARGET="-O2 $CXXFLAGS_FOR_TARGET" ;;
esac
case " $CXXFLAGS " in
*" -g "* | *" -g3 "*) ;;
*) CXXFLAGS_FOR_TARGET="-g $CXXFLAGS_FOR_TARGET" ;;
esac
fi
AC_SUBST(CXXFLAGS_FOR_TARGET)
ie, CXXFLAGS_FOR_TARGET is what should be used, not CXXFLAGS
There are a lot of C++ configure tests in libstdc++ (and other target libs!)
that use CXXFLAGS assuming it's the real thing used to build the library. Not
just atomicity. A consistent solution would be nice here.
Possible solutions:
1) Setup GLIBCXX_CONFIGURE to export GLIBCXX_CXXFLAGS, which is then used
consistently during configure only, and incorporates CXXFLAGS_FOR_TARGET.
(Makefiles still use CXXFLAGS).
2) use CFLAGS_FOR_TARGET in libstdc++ config
3) like one, but have something like CXXFLAGS_EXTRA_FOR_TARGET which (unlike
CXXFLAGS_FOR_TARGET) is not supposed to replace CXXFLAGS, but instead is always
added to CXXFLAGS, not substituted for it.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug libstdc++/53579] libstdc++ configure use CXXFLAGS instead of CXXFLAGS_FOR_TARGET
2012-06-05 0:18 [Bug libstdc++/53579] New: libstdc++ configure atomicity tests use CXXFLAGS instead of CXXFLAGS_FOR_TARGET olegendo at gcc dot gnu.org
2012-08-07 20:53 ` [Bug libstdc++/53579] " bkoz at gcc dot gnu.org
@ 2014-12-29 17:40 ` anatol.pomozov at gmail dot com
1 sibling, 0 replies; 3+ messages in thread
From: anatol.pomozov at gmail dot com @ 2014-12-29 17:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53579
--- Comment #3 from Anatol <anatol.pomozov at gmail dot com> ---
I just hit this issue when tried to build cross-tools for arm64.
CFLAGS_FOR_TARGET works as expected and I was assuming that CXXFLAGS_FOR_TARGET
is used instead of CXXFLAGS.
If CXXFLAGS_FOR_TARGET is not honored now, what is recommended workaround for
cross-compilers that need different CXXFLAGS for host and target?
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-12-29 17:40 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-06-05 0:18 [Bug libstdc++/53579] New: libstdc++ configure atomicity tests use CXXFLAGS instead of CXXFLAGS_FOR_TARGET olegendo at gcc dot gnu.org
2012-08-07 20:53 ` [Bug libstdc++/53579] " bkoz at gcc dot gnu.org
2014-12-29 17:40 ` [Bug libstdc++/53579] libstdc++ configure " anatol.pomozov at gmail dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).