Date: Sat, 6 Sep 2003 10:09:02 +1000 From: John Birrell <jb@cimlogic.com.au> To: deischen@FreeBSD.org Cc: freebsd-threads@FreeBSD.org Subject: Re: Removing -pthread from gcc Message-ID: <20030906000902.GA25237@freebsd1.cimlogic.com.au> In-Reply-To: <Pine.GSO.4.10.10309051914370.1042-100000@pcnet5.pcnet.com> References: <200309052235.h85MZoRF015386@latour.rsch.comm.mot.com> <Pine.GSO.4.10.10309051914370.1042-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030906000902.GA25237>