Date: Sun, 31 Aug 2003 21:38:30 -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: <3F52BF36.1060701@freebsd.org> In-Reply-To: <Pine.GSO.4.10.10308312303300.18633-100000@pcnet5.pcnet.com> References: <Pine.GSO.4.10.10308312303300.18633-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote: > On Sun, 31 Aug 2003, Scott Long wrote: > > >>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? > > > I'm (somewhat biased I guess) very much against making libpthread > be anything other than what is now libkse. libkse was always > suppose to be libpthread and offers real POSIX behavior (the > 'p' in libpthread) unlike libthr. Solaris has both libpthread > and libthread, neither of which are links. If you want one > or the other, you link to the one you want. I don't see a > reason why we should be any different. If you don't think > about ports, then it should be more clear that that is how > it should be. > We may come to 5.2/5.3/5-STABLE/whatever and find that KSE doesn't work on one or more platforms where THR does (disregarding the POSIX correctness issue). What do we do then? Forcing a rename of libkse->libpthread on all platforms is a bad idea, IMO, as is the possible inconsistency of forcing a rename on some platforms but not others. Of course, once KSE is 100% solid on 100% of the platforms, then my argument goes away =-) Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F52BF36.1060701>