Date: Sun, 21 Sep 2003 03:17:28 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Kris Kennaway <kris@obsecurity.org> Cc: h@schmalzbauer.de Subject: Re: Fixing -pthreads (Re: ports and -current) Message-ID: <Pine.GSO.4.10.10309210238590.26520-100000@pcnet5.pcnet.com> In-Reply-To: <20030921063540.GA41190@rot13.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@ 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10309210238590.26520-100000>