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]"
