Top-level --enable-threads verses --enable-libgcj (was Re: PATCH [v4]: Support the FreeBSD 5.0 system thread library model)

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

[BTW, the subject line is somewhat misleading as it is really
 top-level --enable-threads verses all gcc language-specific libraries
 except libobjc and, hopefully, libstdc++-v3 before the 3.0 release.]

> I wonder if it wouldn't be better to add this special handling of
> libgcj and threads [for a FreeBSD target] to the top-level
> configure.in, so that we disable libgcj, instead of forbidding this
> perfectly valid configuration for all languages?

I agree that it may make more sense to put the test at top-level.  And
I will move it, if you feel strongly about it.  It would also be
reasonable to support en/disabling threading support on a per-library
basis.  It would be even better IMHO if all gcc language libraries
were to use, at least as an option, the gcc/gthr.h threading
abstraction layer instead of inventing their own novel mechanism of
supporting threading on platforms which support threads.  I am
currently studying this change for libstdc++-v3 and it should improve
--enable-threads support across various platforms (especially those
which support only non-POSIX threads).  After that, I want to
investigate making a similar change for libjava.

I would prefer to spend time working on fixing the underlying
threading configuration issues that require a fatal configuration
combination check for some platforms than moving the check around.  As
far as I am concerned, the main issue is to fail at early
configuration-time instead of the later library configuration-time.
(FYI, I only added the check for the one platform known to me to be
broken but I am sure this exact configuration combination is broken
for other platforms.)

However, I do feel strongly that if a user provides a non-default
configuration switch to enable libgcj and if there is a real
configuration combination conflict present, then the gcc configuration
process should not just silently disable libgcj.  My approach tells
the user of the port I maintain why the configuration is broken and
the valid solution space to get a working configuration.  I think that
this approach can work at top-level just as well which is why I will
move it, if you wish but I am less happy to just disable libgcj for
this platform in light of conflicting configuration options since
configure can't guess the true intention of the user.

Regards,
Loren