Paolo Bonzini <[email protected]> writes:
>> ** 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.
Given it's inconsistent definition across platforms and the fact that
it's an implementation artefact, I'd argue for removing it. I've just
did a google search and there aren't too many uses, many of them
misguided or using constructs like defined(_REENTRANT) ||
defined(_PTHREADS) which continue to work. Of course we should announce
this, together with the posix95 removal.
>> ** _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 could find no use outside of gthr.h/gthr-dce.h, and the platform is
old (I may say so, being the keeper of historical OSes myself :-).
>> 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.
Agreed.
>> 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...
Right: nobody in his right mind would look at this stuff otherwise :-)
>> 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.
I'm not convinced: when it was introduced (or used more extensively), I
was already bitten by the fact that the GTHREAD_USE_WEAK test uses a
hardcoded list, instead of really checking what it is meant to test:
support for weak definitions. Perhaps the autoconf-archive macro is
better in this respect.
>> 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?).
Certainly: this is far too risky with testing only on posix systems.
Thanks.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
