Re: ports and -current

From: Daniel Eischen <>
Date: Sun, 21 Sep 2003 00:46:30 -0400 (EDT)
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: <>
> > >             Harald Schmalzbauer <> 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
Received on Sat Sep 20 2003 - 19:46:35 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:23 UTC