[build] Move gthr to toplevel libgcc

[Paolo Bonzini]

On 08/08/2011 03:47 PM, Rainer Orth wrote:
> This patch moves gthr*.h and related code to toplevel libgcc.  Unlike
> the other outstanding patches (libgcc1, libgcc2, crtstuff, shlib), it is
> pretty independent from the rest, so I'm posting it first.  It was
> developed last, so there may be conflicts (gcc/Makefile.in).  It also
> depends on the posix95 removal patch.
>
> Instead of cluttering the libgcc directory, all non-generic gthr-*.h
> files were moved to their respecitive positions in libgcc/config.  The
> patch simplifies gthr.h quite a bit:
>
> * It does away with the need for thread-specific defines:
>
> ** HAVE_GTHR_DEFAULT is removed, instead I always create gthr-default.h,
>     even if only as a link to gthr-single.h.  That simplifies the calling
>     runtime libs which don't need to re-determine that value.

That's a good cleanup.

> ** The use of _PTHREADS to select gthr-posix.h is quite inconsistent:
>     only a few targets define that macro (m32r/linux.h, mn10300/linux.h,
>     netbsd.h, sh/linux.h, sol2.h), and none of them support alternative
>     thread models.  Given that everything works fine for every other
>     Linux target suggests that this can go.

_PTHREADS is used in the wild, I'm not sure about removing it from the 
specs, especially for netbsd.h and sol2.h.

> ** _DCE_THREADS is used to select gthr-dce.h, but again dce is the
>     only/default model on hppa[12]*-*-hpux10* (pa-hpux10.h), so the
>     special-casing can be removed.

Agreed, but again I'm not sure about removing it from the spec.

> I noticed that config/t-vxworks installs gthr-vxworks.h, gthr-default.h
> via EXTRA_HEADERS, but the comment suggests this is only for the benefit
> of the runtime libs which know how to find them, so I've removed that.

Looks good, but should also be added to changes.html.

> The gthr*.h headers have GCC_GTHR_* guards right now.  With the move,
> one might want to change them to LIBGCC_GTHR_*.  If so, one needs to adapt
> libstdc++-v3/include/Makefile.am.  I haven't touched this yet.

No hurry.

>    A really ugly point in the gthr.h interface is that all users need to
>    define SUPPORTS_WEAK and GTHREAD_USE_WEAK themselves.  It would be far
>    better to substitute the result of such a test into gthr.h to avoid
>    this complication.

Yes, and they can also be unified.  The advantage of toplevel libgcc 
move is that the configury becomes self-contained and it is "easy" to 
spot these historical problems...

>    Currently, this is handled quite inconsistently: libobjc does nothing,
>    libstdc++-v3/acinclude.m4 (GLIBCXX_CHECK_GTHREADS) hardcodes
>    SUPPORTS_WEAK, GTHREAD_USE_WEAK for posix threads, and
>    libgfortran/acinclude.m4 (LIBGFOR_GTHREAD_WEAK) tries to determine a
>    sensible value.

I think libgfortran's approach is the nicest to be added in 
libgcc/configure.ac.

> As I said, I'd like to handle this aspect in a followup patch and keep
> the build part separate.

That's fine.

Let's wait for result of testing, especially Win32 (Kai?).

Paolo