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

[Daniel Eischen]

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.

To confuse matters even more, once we change libkse back to libpthread,
we will also be installing the 1:1 version of libkse as libthread
(or some other name, but for now that's what we've chosen).  We
are ready to do this now, but will wait a bit to see how ports
settle out with the removal of -pthread.

BTW, I would also be against linking libpthread to the 1:1
version of libkse.

-- 
Dan Eischen