Re: ports and -current

On Sat, 20 Sep 2003, M. Warner Losh wrote:

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

Consensus occured after further conversation with our FSF GCC
maintainer.  It doesn't matter now whether it is removed or
NOOP'd; ports still break, but not as obviously.

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

There is no default threading package.  That's what PTHREAD_LIBS
is suppose to do.  If we assigned -pthread to one particular
threading package, there would be no way to have a different
one selected, except perhaps globally with /etc/libmap.conf.
PTHREAD_LIBS allows the port builder to override (via /etc/make.conf)
the default threading library with whatever they want.  You
can't do that with -pthread.

> : 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?

It doesn't matter; NOOP == 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.

Again, whether it is a NOOP or removed, the same ports still break.
It is possible that even more ports could break if it is NOOP'd;
autoconf/configure can detect that -pthread is a valid switch if it
doesn't emit an error.

-- 
Dan Eischen