I still don't see anything wrong with the patch. Tested by boostrapping gcc.
The difference between the original patch (that got reverted without any comment) and the one that was later applied to trunk is that the original patch did AC_SUBST(glibcxx_thread_h) and the new one (that is currently in trunk) does m4_include([../config/gthr.m4]) GCC_AC_THREAD_HEADER([$target_thread_file]) Again, this new code seems to work perfectly in 4_7 branch. My guess is committer just was not interested in 4_7 by the time of re-commit. On Tue, May 14, 2013 at 5:32 PM, Evgeniy Stepanov <euge...@google.com> wrote: > This is the original thread: > http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00525.html > > This exact patch was never reverted. It seems to be a second attempt, > that was only applied to trunk that time. I'm cc-ing the original > author. > > Smaller patch attached. > > * config/gthr.m4: New. Define GCC_AC_THREAD_HEADER. > * libgcc/configure: Regenerate. > * libgcc/configure.ac: Replace code with GCC_AC_THREAD_HEADER use. > * libstdc++-v3/Makefile.in: Regenerate. > * libstdc++-v3/acinclude.m4: Replace code with > GCC_AC_THREAD_HEADER use. > * libstdc++-v3/configure: Regenerate. > * libstdc++-v3/doc/Makefile.in: Regenerate. > * libstdc++-v3/include/Makefile.am: Regenerate. > * libstdc++-v3/include/Makefile.in: Rename variable. > * libstdc++-v3/libsupc++/Makefile.in: Regenerate. > * libstdc++-v3/po/Makefile.in: Regenerate. > * libstdc++-v3/python/Makefile.in: Regenerate. > * libstdc++-v3/src/Makefile.in: Regenerate. > * libstdc++-v3/src/c++11/Makefile.in: Regenerate. > * libstdc++-v3/src/c++98/Makefile.in: Regenerate. > * libstdc++-v3/testsuite/Makefile.in: Regenerate. > > > On Tue, May 14, 2013 at 5:24 PM, Jonathan Wakely <jwakely....@gmail.com> > wrote: >> On 14 May 2013 14:14, Evgeniy Stepanov wrote: >>> Hi, >>> >>> this patch merges r192458 into gcc-4_7 to fix separate configure/build >>> of libstdc++. >>> >>> A bit of history: a similar patch was committed to trunk & 4.7 back in >>> Oct'12, then reverted from both, than this patch was committed to >>> trunk only. I wonder if it was simply lost for some reason? >>> >>> Is it OK for backporting to 4.7? >> >> I'd like to know what problem it solves and why it was reverted before >> making that change on a stable release branch.
gthr.patch
Description: Binary data
