Re: ports and -current

In message: <20030921015927.GA28195_at_freebsd1.cimlogic.com.au>
            John Birrell <jb_at_cimlogic.com.au> writes:
: On Sat, Sep 20, 2003 at 07:05:33PM -0600, M. Warner Losh wrote:
: > Why does -pthread necessarily force selection of one specific
: > threading library?  All it means is that it is that the program uses
: > posix threads, at least traditionally.  How FreeBSD causes that to
: > happen is an interesting implementation detail for some, but irrelvant
: > for most ports.  Couldn't -pthread be made to give the user the
: > default threading package, and for those that matter a more specific
: > one can be specified?
: 
: This subject *has* been discussed both within FreeBSD and with the GCC
: maintainers. I think that the consensus from those who chose to participate
: in that discussion was that -pthread would be a noop on FreeBSD.

But it was completely removed.  That sounds like the consensus wasn't
followed.  Why was it then removed?

: > It is insane to have FreeBSD be different than all other systems for
: > this trivial reason.  Why fix everthing in the world when allowing
: > -pthread to be a noop would solve the problem?  Seems like we're being
: > overly picky for no real gain.  I guess I just don't understand.
: 
: Having -pthread as a noop doesn't fix the ports breakage. For years ports
: have worked on the basis that libc_r was linked to get user-space threads
: *instead* of libc. This was the result of certain people in the FreeBSD
: developer community not wanting thread stubs in libc. Since libc was
: linked by default (unless -nostdlib was specified), it was necessary to
: have gcc know to use libc_r instead. That is why the -pthread argument
: was added. FWIW, Linux and the other BSDs didn't have a -pthread argument
: back then.

So we change -pthread to mean "link in the default threading package,
with whatever magic is necessary for that package" rather than "link
in libc_r instead of libc".

: Now that libc has thread stubs in libc (in current), there is no longer
: any need to have gcc know about any of the thread libraries. That's a
: good thing IMO. The FSF wants GCC to have a -pthread argument on all
: platforms and they are happy to have it as a noop.

Then why was it completely removed?

: I doubt that there would ever be a good time to make this change. The fact
: that 4.9 has been delayed is making the problem seem worse because people
: can't commit fixes to the tree. While 4.9 is delayed (due to the PAE
: instability which never should have been allowed), the ports tree should
: be unlocked. The fixes are simple. Make them and move on.

At the very least, we should put it back as a noop.  The timing on
this really sucks because it breaks the ports tree for an extended
period of time.  While the fixes are simple, they haven't been made
yet.  The fact that the tree is frozen makes it seem like a really bad
time to make the change.

Warner