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

From: Daniel Eischen (eischen_at_vigrid.com)
Date: 09/21/03

  • Next message: Will Andrews: "Re: Fixing -pthreads (Re: ports and -current)" 
    Date: Sun, 21 Sep 2003 03:17:28 -0400 (EDT)
To: Kris Kennaway <kris@obsecurity.org>

    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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
  • Next message: Will Andrews: "Re: Fixing -pthreads (Re: ports and -current)"

    Relevant Pages

    • Re: Windows mobile 5/activesync4/bluetooth over ethernet
      ... they should damn well fix the hole and ensure that standard ... ports on an enterprise client PC! ... We may only sync via WiFi at ... Could they fix it? ...
      (microsoft.public.pocketpc.activesync)
    • Re: local/rc.d/* executed twice
      ... scipts get exectued twice. ... does anyone have a fix for it? ... This had been discussed/mentioned on ports@ mailing list, ... A initial patch had been submitted to rc@ list by ...
      (freebsd-stable)
    • upgrading from 4.2 to 4.10
      ... cvsup to the old system 4.2 and it did not fix the problem. ... the FreeBSD book says I need to make sure all the ports are up to ... I had trouble installing Linux ...
      (freebsd-questions)
    • Various package/ports problems
      ... I inherited a FreeBSD 4.8 box that had a lot of out of date ports on it. ... ports system in a way i cant manage to fix. ... from Ruby. ...
      (freebsd-questions)
    • Re: wxgtk build error libpthred related
      ... On Wed, 2004-02-04 at 18:51, Alex Dupre wrote: ... libc_r and libpthread linked into it. ... all ports that depend on gtk12. ...
      (freebsd-current)