Removing -pthread from gcc

[Daniel Eischen]

John Birrell CC'd to help explain the history of -pthread.

On Fri, 5 Sep 2003, Loren James Rittle wrote:
> Hi Daniel,
> 
> (Sorry, I read -current, -stable, -hackers to try to track changes to
> the system compiler.  A private request came to me to make a change to
> the FSF tree to mirror this change.)
> 
> Could you please explain this line a bit more:
> 
> > If [-pthread] left in and we try to link with
> > libpthread,libkse,libthr, etc, we will end up with ports that link
> > to one of those libraries _and_ libc_r.  Just try copying libkse or
> > libthr to libpthread _without_ changing PTHREAD_LIBS (so you still
> > use libc_r) and rebuilding X or KDE.
> 
> You have raised a red herring.  It may be true, but there has to be a
> better fix than breaking a 5+ year convention.  If a user adds -lkse
> to CCFLAGS and sets the ports threads package to -lc_r, then the same
> problem ensues.  Are you sure that this root problem is actually
> caused by a compiler supporting -pthread (perhaps the ports system
> should just stop using -pthread since was a pure alias for -lc_r
> before your patch)?  Other systems support -pthread in gcc and have an
> -lpthread yet do not display the issue you describe.  Why is FreeBSD
> special in having that problem?  Perhaps -pthread should be mapped to
> -lpthread instead of -lc_r (upon a flag day, etc.), if that could help
> the situation.

The problem is that -pthread maps to one threads library,
and we have multiple threads libraries from which to choose.
We have libc_r, libkse (M:N mode), libkse (1:1 mode), and
libthr.

-pthread arose (in FreeBSD anyways) because you couldn't link
to both libc and libc_r in FreeBSD-[34].  In FreeBSD-5+,
we don't need -pthread.  In other words, -pthread was replaced
by -lthr, -lkse11, -lkseMN, or -lc_r.  The one dimensional
-pthread doesn't serve us any longer.

I would have less of an objection if -pthread were kept in
but made a NOOP.

> Please do not use a current shortcoming in ports(5) to kill a
> portability feature of gcc.  A claim has been floated that -pthread is
> not standard.  I tell you that is not the intention of the FSF gcc
> team, even if it is poorly documented.  Since gcc 3.0 (some have been
> added post 3.0 release over time):
> 
> -pthread is supported on Linux (I believe actually copied from FreeBSD
> even though they never had the switch -lc to <replacement library> issue).

> "Everyone" in the BSD world claims to hate autoconf, libtool; yet
> removal of this -pthread feature leads away from emerging
> standardization in gcc not towards it.  Such balkanization will
> actually require more special cases for FreeBSD in such tools not less.

Most of the autoconfs I have seen check for -lpthread, and
-lthread, even -lc_r.  Once FreeBSD renames libkse(M:N) to
libpthread, autoconf should be unbroken, probably libtool also.
We could have thrown the switch from libkse to libpthread
at the same time as -pthread was removed from our repo, but
(mostly) I didn't do it so that "shortcoming in ports" could
be easily found and fixed.

> I will fix the FSF documentation for gcc, if you were led astray by
> the explicit references to AIX but none other.
> 
> If you are unmoved by my line of argument, then I hereby promise to
> commit the change such that it hits the FSF gcc 3.4 release.  Upon
> review, I can't honor any request to make it hit the FSF gcc 3.3.2
> release since we don't revoke features in point releases in that tree.
> 
> Thank you for considering these words.  BTW, wouldn't it be cooler
> if (example only):
> 
> -pthread (whatever the system default)
> -pthread=1 (1 process, aka -lc_r)
> -pthread=1:1 (1 process per thread, aka -lthr)
> -pthread=M:N (M threads in N processes, aka -lkse)
> -pthread=late/weak (perhaps not good ELF form, link against a stub to
> which all POSIX thread libraries on FreeBSD must conform, do not
> record the dependency ala FreeBSD4 default for -lc; or that does it in
> a weak manner en mass such that binding is deferred to the final
> selection made at a final link time)

That's a lot better :-)  The only problem is that we have 2
different libraries that offer 1:1...

I would not object to this approach, but I would like to
temporarily make -pthread (without args) either a NOOP or
an error in our tree to help correct "shortcoming in ports".

> I suspect that late/weak could be quite useful for building ports and
> allowing the final application link to select the thread
> implementation via the final specification.  BTW, I'm the libstdc++-v3
> maintainer that did a lot of the threading improvements in the FSF
> tree (basically made threaded-C++ work as well or better than Linux
> IMHO ;-) so I hope I'm a stakeholder here.  When built in the FSF tree
> (and I suspect the FreeBSD system tree), libstdc++-v3 is setup to do
> late binding as I'm proposing as a generic feature above.
> 
> On FreeBSD 4-STABLE, 5-CURRENT similar:
> 
> ; ldd /usr/local/beta-gcc/lib/libstdc++.so.6:
>         libm.so.2 => /usr/lib/libm.so.2 (0x28177000)
>         libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 (0x28193000)
> 
> ; nm /usr/local/beta-gcc/lib/libstdc++.so.6 |grep pthread
> 00058bc4 T _ZNSt12__basic_fileIcEC1EPP13pthread_mutex
> 00058bb0 T _ZNSt12__basic_fileIcEC2EPP13pthread_mutex
>          w pthread_create
>          w pthread_getspecific
>          w pthread_key_create
>          w pthread_mutex_lock
>          w pthread_mutex_unlock
>          w pthread_once
>          w pthread_setspecific
> 
> It is possible that there are unknown snags with this approach.
> E.g. The weakness property was applied at the source level of the
> library.  It may not be possible to make a library that claims to
> export various symbols yet are really weak placeholders.  I am not an
> ELF expert; I only know enough to be dangerous... ;-)

I suppose kan might have something to say about this.

-- 
Dan Eischen