This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Default to --enable-threads=posix on Linux (was Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils)


At 12:20 06.08.2002, Jakub Jelinek wrote:
On Tue, Aug 06, 2002 at 11:54:26AM +0200, Franz Sirl wrote:
> At 11:31 06.08.2002, Jakub Jelinek wrote:
> >On Mon, Aug 05, 2002 at 02:58:40PM -0700, Mark Mitchell wrote:
> > > Do it quickly, send me a patch, and we can obviate the debate by having
> > > the change in. I just can't see holding up the release for that.
> >
> >Here is the proposed minimum patch to default to --enable-threads=posix
> >unless either some other --enable-threads option or --disable-threads
> >is given on Linux. I don't see why somebody might want not to build thread
> >aware gcc/libstdc++ by default.
> >
> >I've verified that configure with --disable-threads gives the configuration
> >which used to be, ie. no thread support and that no --*threads option given
> >to configure causes posix threads to be used.
> >
> >Ok to commit to mainline/3.2 branch?
>
> Uhm, wouldn't it be easier to put one test under *-*-linux* instead of
> duplicating it all over?

Well, *-*-linux* covers all the unwanted variants like
*-*-linux*ecoff*
*-*-linux*libc1*
*-*-linux*oldld*
*-*-linux*aout*
These can exit early in a global test by listing them first.

That can be of course solved by one case ... esac. What I'm not sure
is whether ports like xtensa-*-linux* want threading by
default, I don't see any support for them in glibc.
Hmm, but xtensa-*-linux* supports the enable-threads switch..., I guess the port hasn't been contributed to glibc yet.

The questionable ones matching are:

hppa*64*-*-linux* | parisc*64*-*-linux*): doesn't handle --enable-threads, possibly a bug since 32bit hppa supports it

pj*-linux*): isn't this one already gone in the mainline?

powerpc64-*-linux*): wow, no --enable-threads support here? sounds very much like a bug too

We could force thread_file='single' for these if enable_threads is unset, this would still result in less code duplication.

But maybe this can wait for the mainline/3.2.1 and we go with your patch for 3.2.

Franz.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]