ports and -current

[Daniel Eischen]

On Sun, 21 Sep 2003, John Birrell wrote:

> 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.
> 
> > 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.
> 
> 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.
> 
> 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.

I couldn't agree more :-)  There should be no reason not to commit
fixes to unbreak a port.  5.2-RELEASE has to happen relatively soon also.

-- 
Dan Eischen