Date: Fri, 5 Sep 2003 17:35:50 -0500 (CDT) From: Loren James Rittle <rittle@latour.rsch.comm.mot.com> To: eischen@vigrid.com Cc: freebsd-threads@FreeBSD.org Subject: Re: Removing -pthread from gcc Message-ID: <200309052235.h85MZoRF015386@latour.rsch.comm.mot.com>
next in thread | raw e-mail | index | archive | help
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.
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).
-pthread is supported on HPUX (both PA and ia64).
-pthreads (note misspelt but same feature) is supported on Solaris.
-pthread supported on OpenBSD and NetBSD.
-pthread is supported on OSF/alpha.
-pthread is supported on SysV/i386 and /PPC.
-pthread is supported on AIX.
Typically, -mthread[s] (don't ask) is supported if the port supports
threads but not POSIX threads. Even ports that merely add a library
instead of replace a library support the switch.
"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.
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)
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... ;-)
Regards,
Loren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200309052235.h85MZoRF015386>