Date: Sun, 31 Aug 2003 20:58:22 -0600 From: Scott Long <scottl@freebsd.org> To: deischen@freebsd.org Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/contrib/gcc/config freebsd-spec.h Message-ID: <3F52B5CE.8040905@freebsd.org> In-Reply-To: <Pine.GSO.4.10.10308312240001.15178-100000@pcnet5.pcnet.com> References: <Pine.GSO.4.10.10308312240001.15178-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote: > On Sun, 31 Aug 2003, Joe Marcus Clarke wrote: > > >>On Sun, 2003-08-31 at 22:05, Scott Long wrote: >> >>>Daniel Eischen wrote: >>> >>>>deischen 2003/08/31 15:38:52 PDT >>>> >>>> FreeBSD src repository >>>> >>>> Modified files: >>>> contrib/gcc/config freebsd-spec.h >>>> Log: >>>> Remove -pthread as a compiler option. It was deprecated 2.5 years >>>> ago, but not removed. >>>> >>>> No reply from: threads, kan, obrien >>>> >>>> Revision Changes Path >>>> 1.10 +2 -38 src/contrib/gcc/config/freebsd-spec.h >>>> >>> >>>What is the consequence of this on ports/? I'm very much in >>>favor of this change, but I'm wondering if more safety belts are >>>needed. Also, are there any consequences on the doc/ and www/ >>>areas? > > > I don't know, but it hasn't been -pthread in current in over > 2.5 years. Yes, -pthread was there as a bandaid, but it wasn't > _the_ way to build threaded applications under -current. So, > -pthread _was_ the safety belt. > > >>I have a feeling we will see an increase of port build errors on >>-CURRENT. This may not be a bad thing, though. It will show us which >>ports are not using ${PTHREAD_LIBS} correctly. > > > I agree. This is only the first step, though. Once ports > get through this, there may be another hurdle once libkse > becomes libpthread again. Autoconf may autodetect the presence > of a libpthread and link to it, in conjunction with linking > to ${PTHREAD_LIBS} being picked up somewhere else in the > port. Just try building XFree86-4 or kde with libpthread > (libkse installed as libpthread) and ${PTHREAD_LIBS} set > to libc_r. It links to both libraries. > This opens up very important questions. How do we smoothly make the transition? What is the appropriate threading library for each platform? Should 'libpthread' be a symlink, or should a library be renamed? How do we answer these last two questions in a consistent fashion? Where does libmap fit in? Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F52B5CE.8040905>