On Sat, 20 Sep 2003, Doug Barton wrote:

> On Sat, 20 Sep 2003, Daniel Eischen wrote:
> 
> > On Sat, 20 Sep 2003, M. Warner Losh wrote:
> >
> > > In message: <[EMAIL PROTECTED]>
> > >             Harald Schmalzbauer <[EMAIL PROTECTED]> writes:
> > > : Not only the -pthread removement broke countless ports (some of them are
> > >
> > > Maybe I missed the reason why FreeBSD needs to be unique wrt threading
> > > programs and not have -pthread...
> >
> > Because -pthread allows selection of one specific threadling library,
> > not multiple.  It is also unnecessary since the library is specified
> > as a link option, not a compiler option.  In the future, -pthread
> > will be a NOOP, but it suits us now to have it cause an error so
> > that ports that don't honor PTHREAD_LIBS can be found and fixed.
> 
> IF this is a good idea (and I'm not convinced it is), I still have two
> major objections to it. First, this action was taken with very little
> (any?) discussion. Second, the timing is truly horrible, occurring
> during a ports freeze.

This is the longest ports freeze that I can remember.  I wasn't
expecting it to last long.  Not to change the subject, I thought
it would just be long enough to lay the tag.  I don't think you
should label it as bad timing as much as asking why the freeze is
taking so long.

> If your goal is actually to find and fix broken ports, there are a LOT
> of other options, including enlisting volunteers, and using the package
> building cluster.
> 
> I'd really like to see this change backed out, at minimum until the
> ports freeze is over.

I'd like to see some barking up the other tree.  Why should fixes
to unbreak ports be held up by the freeze?

-- 
Dan Eischen

_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to