Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 1 Sep 2003 16:01:20 +1000
From:      John Birrell <jb@cimlogic.com.au>
To:        deischen@FreeBSD.org
Cc:        David O'Brien <obrien@FreeBSD.org>
Subject:   Re: cvs commit: src/contrib/gcc/config freebsd-spec.h
Message-ID:  <20030901160120.A1311@freebsd1.cimlogic.com.au>
In-Reply-To: <Pine.GSO.4.10.10309010100490.5115-100000@pcnet5.pcnet.com>; from eischen@vigrid.com on Mon, Sep 01, 2003 at 01:22:47AM -0400
References:  <20030901045513.GA91654@dragon.nuxi.com> <Pine.GSO.4.10.10309010100490.5115-100000@pcnet5.pcnet.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Sep 01, 2003 at 01:22:47AM -0400, Daniel Eischen wrote:
> > {Net,Open}BSD and Linux all accept the "-pthread" option.  By removing
> > support for it we are the odd man out on accepted GCC options.  You also
> 
> {Net,Open}BSD have it because they had the same problem with
> libc_r (it couldn't be linked with libc).  Since when did Linux
> get this hack and why?

When the -pthread argument was added to FreeBSD's gcc, it was because
the initial thread work wasn't allowed to 'touch' libc. That was
off-limits. Times have changed and it's time we moved on from that
position. Once libc was 'allowed' to have stubs in it for thread-specific
data, mutexes, condition variables, etc, there was no need to have
a separate library.

I don't remember any of the operating systems mentioned having -pthread
back then. Perhaps my memory is vague. That fact that they have it now is
nothing more than a curiosity IMO.

> Are we talking about buildworld or ports?  I know we are
> breaking 3rd party makefiles, but we need to do that
> and knew over 2 years ago.

If we're talking about things in 5.X that affect third party developers,
let me say that a compiler option is the least of the problems they
will encounter. I'm going through that 'little' exercise now. And what
fun it is. Not.

FWIW (probably not much), I support Dan's position on this. I'd like to
see kse become the default as a true libpthread as has been assumed in
all the work that those guys have done.

I'll go one step further and say that I don't think libthr should be in
the tree. And libc_r should be shot just as soon as kse is functional on
the tier-1 platforms.

-- 
John Birrell



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030901160120.A1311>