Removing -pthread from gcc
eischen at vigrid.com
Fri Sep 5 16:47:04 PDT 2003
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
-pthread arose (in FreeBSD anyways) because you couldn't link
to both libc and libc_r in FreeBSD-. 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.
More information about the freebsd-threads