cvs commit: src/contrib/gcc/config freebsd-spec.h

[Scott Long]

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