Removing -pthread from gcc

[John Birrell]

On Fri, Sep 05, 2003 at 07:47:01PM -0400, Daniel Eischen wrote:
> -pthread arose (in FreeBSD anyways) because you couldn't link
> to both libc and libc_r in FreeBSD-[34].  In FreeBSD-5+,
> we don't need -pthread.  In other words, -pthread was replaced
> by -lthr, -lkse11, -lkseMN, or -lc_r.  The one dimensional
> -pthread doesn't serve us any longer.
> 
> I would have less of an objection if -pthread were kept in
> but made a NOOP.
> 
> > Please do not use a current shortcoming in ports(5) to kill a
> > portability feature of gcc.  A claim has been floated that -pthread is
> > not standard.  I tell you that is not the intention of the FSF gcc
> > team, even if it is poorly documented.  Since gcc 3.0 (some have been
> > added post 3.0 release over time):
> > 
> > -pthread is supported on Linux (I believe actually copied from FreeBSD
> > even though they never had the switch -lc to <replacement library> issue).

If -pthread is intended as a standard FSF gcc option, then it should be mapped
to a NOOP for FreeBSD IMO.

Back at the time when -pthread was added to FreeBSD's gcc (prior to being
adopted by the FSF) the FreeBSD libc maintainers didn't want pthread stubs
in libc, so an alternative library had to be built. The name came from OSF1.

Since gcc 'knew' about libc, the only viable alternative was to also teach
gcc about libc_r, hence the -pthread argument.

I've just been through the exercise removing -pthread from my local application
sources using the -current gcc which spits if -pthread is still used. From what
I can see, this needn't be an error (or even a warning), because if the
application uses one or more of the pthread functions (other than the ones
which are stubbed), all you get is a link error. I think this still makes it
obvious to ports people what is going on.

So a NOOP is best. Change gcc in the FSF sources when appropriate, but let
-current have the change now.

-- 
John Birrell