Re: Fixing -pthreads (Re: ports and -current)

On Sat, 20 Sep 2003, Kris Kennaway wrote:

> On Sun, Sep 21, 2003 at 02:12:55AM -0400, Daniel Eischen wrote:
> > On Sat, 20 Sep 2003, Kris Kennaway wrote:
> > 
> > > On Sun, Sep 21, 2003 at 01:44:35AM -0400, Daniel Eischen wrote:
> > > > > What, precisely, do you object to in the above proposal?
> > > > 
> > > > 1, 2, and 3.  I don't think backing out -pthread change helps
> > > > much in fixing ports...
> > > 
> > > Again, why?  Please explain instead of asserting, because that's
> > > getting us nowhere towards resolving this.
> > 
> > Because when things break, people fix them.  There is no
> > motivation (as seen in the last 2+ years) to fix something
> > that isn't broken.
> 
> What's the real issue here?  It seems like you're suggesting that it's
> not your responsibility to help fix the broken ports, and that other
> people should do the work instead.

Well, sorta yes.  I don't have the time to fix broken ports
but I can help guide others.  I have other things on my plate.
I do have one of my own ports to fix though.

> >   http://docs.freebsd.org/cgi/getmsg.cgi?fetch=321307+0+archive/2003/freebsd-ports/20030601.freebsd-ports
> > 
> > my posting to ports_at_ in May of this year.
> 
> That change doesn't seem to have happened, or to be the same thing
> we're discussing here.  Anyway, if you'd been interested in
> pre-empting problems with the -pthread change you could have asked me
> to do a package build with the change in place to test the waters, and
> then worked with me and others to minimize the impact at the time when
> the commit went in.  I routinely do this with other committers
> (including the gcc imports), and I'm happy to continue doing so.

Well, actually it is directly related.  Part of the plan to
transition to libpthread is making ports PTHREAD_LIBS compliant.
As stated in that thread, if a libpthread exists on the system,
autoconf/configure will pick it up and the port will also end up
using -pthread and/or PTHREAD_LIBS.  If PTHREAD_LIBS is set
to libthr or libc_r (something other than libpthread), then
the port ends up linking to both libraries.  This doesn't work
but you don't know it until your run the application and very
weird things happen.  Causing a clean breakage is better because
you know at compile-time that something is wrong.  So ports need to
first be PTHREAD_LIBS compliant before we make the switch.  Soon
after ports are fixed, we can rename it.

I think doing a build of all the ports is a good idea.
I guess you've already done that if I recall an earlier
email correctly.  I also think most of the problems are
already known, and if you give it a few days after the
freeze things should look a lot better.

Actually, to look ahead a bit... After ports are fixed, it
still might be a good idea to do another package build, but
this time with libkse installed as libpthread and PTHREAD_LIBS
set to libc_r (or something that is not libpthread).  Is there
an easy way to do an 'ldd' of the resulting binaries to
make sure libpthread isn't referenced?  Feel free to take
this offline if you want...

> However, the strategy of just dumping a change into the tree and then
> leaving it to others to clean up the mess is not a good one - it's
> disruptive to the development cycle, it causes developers to get
> bogged down in arguments like we find ourselves having now, and the
> bottom line is that it's just not very polite to the people that your
> change affects.

As Will mentioned, I think the changes are mostly done.  I
don't think I just 'dumped' the changes into the tree.  It
has been over 2 years since, yada yada yada, and the ports
system should have been using PTHREAD_LIBS since then.  I don't
want to argue with you; I respect you and everyone else here
and God knows you guys contribute an awful lot.

> > When the GCC-3.3 import broke a lot of ports, did you ask for it to
> > be backed out so that ports could first be fixed?
> 
> No, kan and I worked together before the change went in to evaluate
> the impact on packages, then I coordinated a group of volunteers to
> help fix the resulting fallout.  I'm trying to do the same thing now.
> Are you willing to be part of the solution to this problem?

>From what I've recently read, the freeze should be lifting
this week.  Can we hold off till then?  Is a few more days
going to matter?  If the freeze continues longer than expected,
I'll back the change out until it's over.

-- 
Dan Eischen