Removing -pthread from gcc
eischen at vigrid.com
Fri Sep 5 17:18:25 PDT 2003
On Sat, 6 Sep 2003, John Birrell wrote:
> 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-. 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.
If you link an application, then it will. But if you are linking
a library (OpenGL, libgthread, etc), I don't think you will get
> So a NOOP is best. Change gcc in the FSF sources when appropriate, but let
> -current have the change now.
More information about the freebsd-threads