Re: GCC commandline option names for thread support

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

>         In December 1998, someone broached the topic of the lack of
> uniformity in GCC commandline options to request re-entrant, thread-safe
> libraries and headers when the target supports that option.  In the
> intervening years, things have not improved.

David, I think we should care about this as well.  In addition to the
namespace spillage issues you raised, how about a concrete proposal
for the table on some of the finer points?

If gcc is configured (by default or explicitly) for POSIX threads,
then -pthread is always honored to mean:

for compiler pass: add any defines to make system headers expose
                   re-entrant, thread-safe interface (e.g. some
		   need _REENTRANT, _POSIX_THREADS, _PTHREADS, etc.)

for linker pass:   add/replace any libraries needed to find the POSIX
		   thread functions and, if possible/needed, make the
		   rest of the normally linked libraries point to
		   re-entrant, thread-safe versions

Any other -[a-z]*thread[a-z]* options that currently exist remain
special to given ports (or are cleaned up as suggested).  As many have
observed, it is hard to completely standardize this area beyond ports
that support POSIX threads.  

I think this final point is quite important as well (and I know of no
existing ports that honor -pthread which work this way): If gcc is not
configured (by default or explicitly) for POSIX threads, then -pthread
should cause the compiler driver to give a *fatal* *error* when
present on the command line.  I have noticed many reports in the gcc
mailing list from people trying to use threads with a build of gcc
that wasn't configured with --enable-threads.  They give the -pthread
option, but end up losing.

Can parts of a spec file be built based on configuration options?

Regards,
Loren