Date: Mon, 01 Sep 2003 00:24:22 -0600 From: Scott Long <scottl@freebsd.org> To: John Birrell <jb@cimlogic.com.au> Cc: David O'Brien <obrien@FreeBSD.org> Subject: Re: cvs commit: src/contrib/gcc/config freebsd-spec.h Message-ID: <3F52E616.3050201@freebsd.org> In-Reply-To: <20030901160120.A1311@freebsd1.cimlogic.com.au> References: <20030901045513.GA91654@dragon.nuxi.com> <Pine.GSO.4.10.10309010100490.5115-100000@pcnet5.pcnet.com> <20030901160120.A1311@freebsd1.cimlogic.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
John Birrell wrote:
> 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.
>
Rehat GCC 2.96 and 3.2 both support the -pthread option, though its
function is _quite_ vague:
`-pthread'
Adds support for multithreading with the "pthreads" library. This
option sets flags for both the preprocessor and linker.
I'm not in the mood to go digging though SRPM packages to look for the
real meaning of this, so YMMV.
That said, I'm really not against removing '-pthread'. It causes
endless confusion for people like me who don't quite pay enough
attention but still remember when it did magical things. I know that
it has been 'deprecated' for a number of years, but maybe it's time
to make gcc actually spit out warnings when it's used? Dunno.
Whatever moves us forward with the least amount of pain.
>
>>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.
>
I'm with you until this point. THR provides the competition to keep KSE
moving. As long at it has an active maintainer, I can't see it being
removed.
Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F52E616.3050201>