Date: Fri, 5 Sep 2003 20:18:08 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: John Birrell <jb@cimlogic.com.au> Cc: freebsd-threads@FreeBSD.org Subject: Re: Removing -pthread from gcc Message-ID: <Pine.GSO.4.10.10309052012540.9168-100000@pcnet5.pcnet.com> In-Reply-To: <20030906000902.GA25237@freebsd1.cimlogic.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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-[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. 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 the error. > So a NOOP is best. Change gcc in the FSF sources when appropriate, but let > -current have the change now. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10309052012540.9168-100000>