This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Standardization of compiling and linking multi-threaded applications
- To: gcc@gcc.gnu.org
- Subject: Standardization of compiling and linking multi-threaded applications
- From: Loren James Rittle <rittle@latour.rsch.comm.mot.com>
- Date: Mon, 16 Aug 1999 20:46:14 -0500 (CDT)
- Reply-to: rittle@rsch.comm.mot.com
Open message to gcc port maintainers (and port users if you compile
and link multi-threaded applications):
If a gcc port has been configured with --enable-threads=posix (or
--enable-threads=pthreads, or if the port naturally configures such
support in), then is there any common agreement on the command line
switch that users should provide to compile and link a multi-threaded
application?
Should there be standardization across platforms in this area?
If a gcc port has been configured with --enable-threads (assume for
the moment that the system default is not posix threads), then is
there any common agreement on the command line switch that users
should provide to compile and link a multi-threaded application?
Should there be standardization across platforms when the underlying
threading package might be different?
My study reveals that some ports use -pthread while others use
-pthreads, -mthreads or -threads. Thus, it appears that there is
little standardization between gcc ports when it comes to exact name
of the command-line switch to hint to the compiler that the user is
compiling and linking a multi-threaded application. This appears to
be true even when the platforms are all using POSIX threads.
At least one port (FreeBSD) uses -pthread to refer to user-level POSIX
threads and -kthread to refer to kernel-level POSIX threads.
Another port (Solaris) uses -threads when Solaris threads were
configured and -pthreads when POSIX threads; but the written spec file
doesn't catch a mismatch (and granted in most/all versions of Solaris,
this might not be a problem).
It would be great if we could all agree on a particular mapping with
additional mappings, if the target supported additional threading
libraries or modes completely compatible with the way it was
configured. Thus, a port might always support -threads, if it was
configured with --enable-threads. It could support any of the
existing switch names or additional switch names as required to offer
the additional mappings.
It would also be nice if the standardized switches produced an error
whenever they were provided but gcc was not configured and built with
multi-threading support. As it stands now, some language users can
provide the switch even when gcc was built with --enable-threads=no
and will be quite surprised by an unstable system at run-time.
If you are a port user or port maintainer with a position on this
issue, please send me e-mail. Feel free to CC the list if I missed a
very important point, but I will summerize to the list. I am
particularly interested in whether users want the existing switch
names to be maintained; or wouldn't mind converting to a new scheme
that was standardized across all platforms.
Assuming that a strong majority is in favor of such standardized, it
would be my intention to provide patches for all system configurations
that currently support threads and documentation on how to use the
feature as a user (since only -mthreads appears to be documented
in the info files).
Regards,
Loren