Hi Rainer, * Rainer Orth wrote on Mon, Mar 21, 2011 at 12:55:23PM CET: > 2011-03-20 Rainer Orth <r...@cebitec.uni-bielefeld.de> > > gcc: > * gthr-solaris.h: Remove. > * gthr.h (_SOLARIS_THREADS): Don't include gthr-solaris.h, remove. > * config/sol2.h (CPP_SUBTARGET_SPEC): Remove -threads support. > (LIB_SPEC): Likewise. > * config/sol2.opt (threads): Remove. > * config.gcc (i[34567]86-*-solaris2*): Remove solaris threads > support. > (sparc*-*-solaris2*): Likewise. > * configure.ac (enable_threads): Enable solaris support. > * configure: Regenerate. > * doc/invoke.texi (Option Summary, Solaris 2 Options): Remove > -threads. > * doc/install.texi (Configuration, --enable-threads=lib): Remove > solaris.
Can't gcc/gthr-tpf.h go, too? What about gcc/gthr-nks.h? Conversely, if they can't go yet, then that likely means they are used from elsewhere in the tree. libstdc++-v3 configure looks like it would access the gthr* from gcc/. So, if libstdc++-v3 is built as part of Stage 1 (say, due to --enable-build-with-cxx, or go enabled), can it happen that an installed still GCC uses these otherwise seemingly unused thread models (including solaris)? Otherwise, I can't really find anything objectionable from a build system POV. Thanks, Ralf
